Dear All,
dss:Document allows to pass XML input documents in several ways, InlineXML, Base64XML and EscapedXML.
This design allows clients of the DSS
service to build requests using the better suited alternative for them, as
there are several implementation concerns (present in many common web-service
tools) when using the InlineXML alternative
- In some toolkits is specially difficult to manually
“paste” inline documents
- Some others allow that, but don’t
preserve XML Infoset fidelity (the documents going
to the server are modified, ensuring that the crypto validation will be broken
from the beginning).
So it’s ok to have
different alternatives, to let the developers choose the more appropriate to
their needs / tools. I was not present in the discussions related to the dss:Document design, but probably you
had these issues (or other similar) into consideration.
Now, when dealing with the
other part, that is, XML signatures or XML timestamps (the binary (i.e. CMS) ones
are base64Binaries, no problem with that), we don’t have the same
facilities present in the dss:Document,
we only have an option: inline XML signatures/timestamps
(as we can only use dss:Base64Signature for binary (i.e. CMS) ones).
Apart from the design issue, this asymmetry adds practical
difficulties when generating signatures with data-binding tools
(common in the most common web-services toolkits (i.e. Axis, .NET, …). Obviously, I’m not against the inline
options, but there should be other options for pasting signatures inside the
request. IMO, we should have the same facilities present in the dss:Document element also for
signatures and timestamps. In other case, we’re almost forcing clients
not to use their common web-service toolkits, but to use low-level XML
manipulation toolkits (i.e. DOM level, cursor level or the like).
In that direction, when
thinking about practical (schema) solutions for that, I’ve also observed
the extreme design overhead incurred by the dss:Timestamp
element: maybe you were looking to make explicit the two use cases for dss:SignatureObject: signature inside or timestamp inside. In
fact, the contents of dss:SignatureObject
(obviously, except the dss:Timestamp itself) could be
the same that the contents of dss:Timestamp (by now
an inline XML signature and a Base64Signature). So, we’re almost
duplicating dss:SignatureObject
contents into dss:Timestamp.
Actually, the only difference
in their contents is that we don’t have SignaturePointers
for timestamps, but I don’t see any practical reason for not allowing enveloped
XML timestamps.
My proposal (if I’m not
forgetting about something important, this solves the two issues at once):
- Include a Type attribute
for dss:SignatureObject
that allows to differentiate between signatures and timestamps (in fact,
moving up the Type
attribute from the dss:Base64Signature element to the dss:SignatureObject
element).
- Remove the whole dss:Timestamp element.
- Create a dss:XMLSignature element as a choice including the
three options (ds:Signature(inline), Base64Signature,
EscapedSignature) and replace it for the actual ds:Signature.
- Change the name of the actual dss:Base64Signature for dss:BinarySignature,
in order to be more accurate (the big difference with the XML ones is not
that the signature is base64-encoded (XML Signatures can also be
base64-encoded), but that it’s a binary encoded (i.e. DER-encoded),
then base64-encoded signature (obvious, as we cannot have raw binaries
inside XML).
Opinions?
Best regards,
Carlos
Carlos Gonzalez-Cadenas
Chief Security Officer
Diagonal 188-198 Planta 2
08018 Barcelona
tel: 902 303 393
fax: 902 303 394
gonzalezcarlos@netfocus.es
www.netfocus.es