RE: XAdES support in ODF

[David LeBlanc <dleblanc@exchange.microsoft.com>]

Just reviewed the 1.4.1 spec, and all that is required is that the SignatureValue be signed. You could accomplish this by placing an Id on the SignatureValue element, but you can also do so with an XPath along these lines:

/document-signatures/Signature[@Id= xmldsig-4b344638-5f8e-4025-8689-73bf9b1ddcf5]/SignatureValue

When creating CounterSignature elements, then you have to do something to uniquely identify each of these, since you could theoretically have an infinitely complex tree of countersignatures and countersignatures on countersignatures. I do not wish to attempt to build a UI that would allow people to do that, but in a standard we have to accommodate this sort of thing. The XAdES standard doesn't really speak to it - it just says a CounterSignature element contains some number of Signature elements.

Given that the current design has one file containing a document-signatures element, which in turn contains multiple Signature elements, then we have to at least put an Id on each Signature. If you need to reference elements below that, then you can do so from the top, or you could use the approach like you took here.

So in terms of the standard, I think there are the following action items:

1) Double-check that my proposal covers adding an Id to at least the Signature element.
2) If we're going to have an approach of making Id attributes be 'tag'-GUID-'suffix', then we should discuss whether we want to write that up and make it part of the standard. I do like the overall approach, but note it isn't used completely consistently in the example signature. It might be nice to do say 'xmldsig-GUID-suffix', and use that same one uniformly across that Signature element unless you reach an enveloped Signature. I'm not sure it matters given a completely arbitrary parser, but if it were something we could depend on, then you could very easily get the Id for several sub-elements just by knowing the Id on the Signature element.

Next, timestamp certs being included in the timestamp itself. I don't truly know. It seems bad to have redundant information, but given that the timestamp is just a blob, and you can't see into it, it might be good to have them in a CertificateValues element. I think I'd come down on the side of not having redundant information. It is also possible the timestamp server just gave you its own cert, and not the whole chain, in which case we'd have to use the CertificateValues to hold it.

-----Original Message-----
From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] 
Sent: Saturday, September 25, 2010 4:48 AM
To: office@lists.oasis-open.org
Cc: Cornelis Frank
Subject: [office] FW: XAdES support in ODF

(Since Frank isn't member of the ODF TC, I'll answer the questions to this list)


"I don't think an Id attribute is needed on SignatureValue - we know what it is signing."

Apparently this is needed when one wants to add countersignatures.


"You don't have any CertValues in your TimestampValidationData elements - why?
(If the timestamp cert is self-signed, that would be one reason.)"

The certificate chain is already in the TSP token itself, so there is no real need to duplicate it. Would it be useful / best practice to add CertValues anyway ?



"Because Id attributes have to be unique in a document, you've nicely made the Id random and unique to each Signature.  I don't think I have creating these covered in my proposal.
It might be a good idea to specify how these should be created."

These are UUID's (ISO/IEC 11578 IIRC), with a prefix because the ID must not start with a number.


Best regards,

Bart

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php