RE: Digital Signatures

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

Inline - 

________________________________________
From: Hanssens Bart [Bart.Hanssens@fedict.be]
Sent: Wednesday, May 05, 2010 2:56 AM
To: David LeBlanc; 'ODF TC List'
Subject: RE: Digital Signatures

David,


thanks for the comments, one remark / question though:

>> 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.

> So that would be the certificate used to sign a document (not the whole certificate chain).
IIRC OpenOffice 3.2 also does this, but I think it is more convenient to include the whole
chain, especially when dealing with very large deployments.

You can do that, but if you are supporting XAdES, there is a designated set of elements to put the certificate chain (along with hashes to prevent exchanging a cert with another that has the same key pair). If you put all of the certs in the KeyInfo, then the parser has to do extra work to figure out which of the certs is the signing cert.

This isn't insurmountable, but it is a nuisance. If you are using XAdES, a somewhat nicer approach is to put the signing certificate into the KeyInfo, and then you place the chain into the CertificateValues element of the XAdES section. Note that XAdES does specifically accomodate certs placed in the KeyInfo ([xades] 7.6.1), and notes that any certs already present in KeyInfo do not have to be duplicated into the CertificateValues.

>In .be, our ID cards have a signing certificate signed by a "Citizen CA" certificate, and
"Citizen CA"  is signed by the "Belgian Root CA". The cards are valid for 5 years.

>Now, to distribute the load of 9 million eID cards (and counting), there are like 100
"Citizen CA's" in use, and a new one is created each month.

>So if a signed document only contains the signing certificate and one wants to verify the
chain, one has to have the "correct" Citizen CA certificate installed.

You don't normally have to install intermediate CAs. A cert should contain the information needed to get the next cert in the chain - we need to contact the intermediate CA(s) to get revocation information in any case.

> If the document would contain the whole certificate chain, one only has to install the
Belgian Root CA (replaced every 5 years or so)

It does potentially save some network traffic, and it is handy to have the chain, but shouldn't be required to be able to evaluate a chain. With that many intermediate CAs, I think you don't want to install them as trust anchors - there's too much chance that one of them might end up compromised.

BTW, it doesn't always give you all the information. If there is a bridge CA and there are multiple chains in play, the chain I use to validate a cert may not be the chain you use to validate a cert. It is impractical and undesirable to attempt to place all possible chains into the signature, so you'd normally go with the shortest available chain at signing time.

I agree it is a good thing to have the whole chain, and we have even had one or two customers ask for Office signatures to do the same. The question would be whether to place them in the KeyInfo or in the XAdES CertificateValues. Given that current implementations that do not include XAdES do place the chain in KeyInfo, that should certainly be allowed, but the question would be whether it is a MUST or a MAY to place them there.

A second question is whether it would be desirable to ask an implementer to place an Id attribute on the signing cert, though a concern that always comes up with Id attributes is that they need to be unique within an XML document, and given that you have an XML element which could contain multiple signatures, there would need to be some way to ensure uniqueness. This also comes into play when adding the XAdES capability to include CounterSignature elements, which will have nested Signature elements.