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


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

Subject: Digital Signatures

I'd like to start off by asking a few questions - my primary interest is achieving a specification that gives me as an implementer enough information that I can sign ODF documents and interoperate with other implementers. I'm also the author for the MS-OFFCRYPTO document where we specify our handling of encryption and digital signatures, as well as being the developer who deals with the core digital signature code for Office.

Just saying that you can sign a document with xmlDSig and optionally include XAdES information provides (IMHO) an overly loose specification. An implementer than has to worry about having a completely arbitrary xmlDSig and XAdES parser, and that can certainly lead to complications. Given that I do not currently have an implementation for ODF, I don't have a lot of energy on the choices you make, but I would like to be able to sign ODF documents with Office.

To get into the details, a Signature element is composed of:

- SignedInfo
- SignatureValue
- KeyInfo (0 or 1)
- Object (0 or more)

The SignedInfo contains the Reference elements to be signed, among other things. Some implementations have Reference URIs that resolve to XML external to the Signature, others may have a requirement that these top-level Reference elements may only resolve to XML within the Signature, typically an Object element, a Manifest element contained within an Object, or in the case of XAdES, SignedProperties. If the top-level References must have URIs that resolve internal to the Signature, then a Manifest would be required. Using a Manifest is of some benefit, because resolving the References contained within an Object is defined as app-specific, which makes you free to have a Transform that may be something defined outside of xmlDSig. I don't know if such a Transform would be needed for this application. The reason I ask about this is that a Transform could potentially cause problems - for example, an XLST transform could lead to a violation of "What you see is what you sign". It may be beneficial to make a requirement that a top-level Reference may only have a canonicalization transform.

SignatureValue is non-controversial - it is just base64 encoding of the actual signature bits.

KeyInfo is listed as optional, but I'm not sure how a practical signature (especially for a document) could exist without one. The catch with this element is that it has quite a lot of flexibility (see [xmldsig] section 4.4). We use a X509Data element in our signatures, but that element is also quite flexible. In our case, we only ever place the top-level certificate as a X509Certificate element into the X509Data, but there are other valid choices to be made. It would be helpful if the standard specified which of these choices were required, allowed and disallowed.

An Object is used to contain a Manifest for app-specific References, and an Object is also used as a container for the single XAdES element.

There are a similar series of decisions to be made when implementing a XAdES element - for an example of the decisions we made, you can look in section of MS-OFFCRYPTO. I am not saying that these decisions are globally the right thing for other document types, but that we need to consider branches in the implementation and what choices to define.

A complex issue is exactly what within a document must or should be signed, and how partial signatures might be treated. This can be left up to implementers to provide flexibility, but the trade-offs are that if you don't sign enough, then you have a loose signature that might not be valid from a security standpoint, and if you sign too much, then you might have signatures that get broken just by updating metadata.

A final point is that there are already some implementers making signatures today, and it would be a good thing to have their existing signatures meet the specification, assuming they're not doing anything incorrect. I don't know which implementers are making signatures now - it would be helpful to me to know that and see what I might end up parsing.

There are other issues, such as encrypt then sign, or sign then encrypt, but I don't want to deal with too much all at once.

Thanks for allowing me to join this group, and I hope I can be of help.

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