RE: certificate chain and XAdes, was Re: [office] RE: DigitalSignatures

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

I think this is the last in the thread for this morning.

To the best of my knowlege, the requirements that have to be met on a per-country basis can all be satisfied by supporting XAdES-X-L. We do not have a per-country profile for Microsoft Office, and all of the countries we've spoken to so far are quite happy with XAdES-X-L, which we fully support in Office 2010.

Where you can run into per-country requirements is in the area of algorithms, specifically, the hashing algorithm must be SHA-2 or better, and certain RSA minimum key lengths or specific elliptical curves are required. The algorithms are all expressed as URLs, and an implementer should be encouraged to support as many of the defined algorithm URLs as possible.

I wouldn't tend to characterize xmlDSig as non-interoperable, or hard to implement, but the implementations I'm aware of have started out with some primary implementation that has defined the choices on a de-facto basis. It is very flexible, and it would be a burden to have to accept any possible valid xmlDSig. The number of valid options within the KeyInfo alone add up to over a dozen (and this doesn't address combinations, which might be on the order of 12 factorial) - there are 5-6 ways to express the key, the KeyInfo could be left out (in which case, the implementer is just supposed to know where to find the cert - not sure how that would work practically), and then if you choose the X509Data element, there are another 5-6 choices within there. Happily, the approach that both OOo and Microsoft Office have taken in their respective signatures are the same (excepting that we put the remaining cert chain in different places, but both approaches are fine - we use XAdES to do that, OOo doesn't have XAdES yet).

What I'd suggest with respect to the KeyInfo element is that the standard specify that the signing certificate must be placed in an X509Certificate element contained in the X509Data element, which is what OOo does now. If the implementer wishes to write out the rest of the certificate chain, the remaining X509Certificate elements may be placed in either the X509Data element, or in the proper XAdES element (see earlier in the thread).

Note - I just reviewed the OOXML ISO standard yesterday in this area, and while it does specify many of the options, it is also lax in this specific area, and I will soon be updating MS-OFFCRYPTO so that it is clear which options the Office parser can handle. In the specification that I maintain, I feel it is very important to clearly state the requirements for interoperability. However, I do recognize that an ISO standard can (and should) change only very slowly, and so we want to take care not to over-specify.

Other outstanding signature issues (other than the encryption debate) are:

 - The issue where paths within Reference elements can mean 3 different things, and it is not defined how to manage that. I suggest using either a Manifest, where the rules for the Manifest can be defined precisely, or using the Type attribute to signal how to manage the URI.

 - The signing time is fine - as long as the element is defined somewhere. However, if you have XAdES, there is a proper place to put the time, with a well-defined format.

- And then there are 4-5 branches within XAdES that ought to be examined.


________________________________________
From: Hanssens Bart [Bart.Hanssens@fedict.be]
Sent: Friday, May 07, 2010 5:08 AM
To: Michael Brauer - Sun Germany - ham02 - Hamburg
Cc: David LeBlanc; 'ODF TC List'
Subject: RE: certificate chain and XAdes, was Re: [office] RE: Digital Signatures

Michael,

>I think what we need is not a single profile, but a set of profiles,
>where each profile is tailored to the requirements of a specific country.

Hopefully we won't need that much profiles :-)

> The question, to which I personally have no answer, is: Is XML DSig
> considered to have too many options? Is it known to have
> interoperability issues? Is it known to be hard to implement?

For instance, signature time in OOo is stored in a <dc:time> in a
<ds:SignatureProperty> inside a <ds:Object>. That's correct per spec,
but will other implementations be able to figure it out ?

(XAdES has SigningTime, for instance)

Will implementations be able to handle multiple signatures ?

(note I'm not ranting against OOo, AFAIK it is the only office suite code
base that signs ODF documents, but just thinking out loud what could
go wrong)


Best regards,

Bart