OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dss] RE: Public comment, namespace inheritance


Hi Trevor and all,

please see below

best regards

Konrad Lanz

Trevor Perrin wrote:
This is in reference to your comment here:
 
I believe your following statement is correct, and is the way we should go:
"The specification must _at_least_ clearly define that the implementation has to apply appropriate messures to get rid of the namespace context for <XMLData> and <Signature> objects."
 
This is probably also true for certain optional inputs / outputs (e.g. KeySelector).  We'll need to review the spec in this light.
I agree and I think its worth the effort to make a clear distinction between what is payload and what belongs to dss.
Is it sufficient to simply add normative text saying the above, or are more extensive changes needed?
I agree and would use a formulation that clearly expresses that xml payload (i.e. well-formed like xml without prolog
but one or more elements that is to be transported inside a sign or verify request) has to be independend.

Hence it can be extracted free of any ancestry context and can be retrieved as it is. This implies not only that the
namespace context has to be removed on extraction, but also that entity references (and the like) have to be
resolved by the client already during compilation of a request.

So a first attempt to give a formulation for dss-xml-payload in using the syntax of grammar of the
XML specification could be as follows:

For XML 1.0:
XMLData    ::=    '<dss:XMLData xmlns="">' DssXmlPayload '</dss:XMLData>'
DssXmlPayload has to be extracted free of any ancestry context, as it is, without inheriting
any namespaces or allowing any entity references but amp, lt, gt, apos, quot.

For XML 1.1 one should additionally specify that any association of the prefix with a namespace
name has to be removed by empty values as indicated in namespaces for xml 1.1 section namespace scoping:
XMLData    ::=    '<dss:XMLData xmlns="" xmlns:dss="">' DssXmlPayload '</dss:XMLData>'

DssXmlPayload    ::=    Misc* element+ Misc*
Note: No prolog and hence no doctypedecl and also no DTD and entity declarations
can reside inside a DssXmlPayload if the whole request should be well formed xml.
Hence EntityRef has to have the additional restriction that a valid EntityRef is one
of amp, lt, gt, apos, quot only. If external entities should be allowed needs
some further thought, but it might be dangerous not to resolve them during compilation
of a request.

element    ::=    EmptyElemTag | STag content ETag

content    ::=    CharData? ((element | Reference | CDSect | PI | Comment) CharData?)*

Reference    ::=    EntityRef | CharRef

The reverse implies that as soon as these restrictions are not met the payload should be base64 encoded or
another kind of opaqueness has to be achieved by any means in both directions.
Your comment discusses the need for a <dss:XMLSignature>, but I'm afraid I didn't understand that?
First <dss:XMLSignature> is somewhat similar to <dss:XMLData>. However inside <dss:XMLSignature> only
a <ds:Signature> is allowed whereas inside <dss:XMLData> DssXmlPayload is allowed, which is a lot less restrictive.

However <ds:XMLSignature> is also a kind of payload that has to be treated free of ancestry context as in the
case of an Enveloping or Detached signature the modification of the Signature element would break the signature.

So if the ds:Signature inherits the xmlns:dss=".....xsd" declaration, it is broken.

Second it allows to solve the violation of the  "Unique Particle Attribution" constraint mentioned in one of
my last postings as now
<xs:any namespace="##other" processContents="lax"/> can be used instead of
<xs:any processContents="lax"/> as <dss:XMLSignature> does not match namespace="##other" any more.

In the original version either all elements
<ds:Signature>, <dss:XMLSignature>, <dss:Timestamp>,
<dss:Base64Signature>, <dss:SignaturePtr> would have matched namespace="##any"
when using <xs:any processContents="lax"/>.

Or <ds:Signature> would have matched namespace="##other"
when using <xs:any namespace="##other" processContents="lax"/>.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]