Hi Trevor and all,
please see below
best regards
Konrad Lanz
Trevor Perrin wrote:
This is in reference to your comment
here:
http://lists.oasis-open.org/archives/dss/200504/msg00012.html
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"/>.
