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: certificate chain and XAdes, was Re: [office] RE: Digital Signatures


David, Bart,

while I don't doubt that it in practice may be reasonable to store a 
certificate chain, I am wondering whether this and other details really 
belong in the ODF specification.

ODF's digital signatures are W3C XML Digital Signatures. It is my (maybe 
wrong) understanding that XAdes is based on XML Digital Signatures. That 
is, an ODF producer may store a XAdes signature instead of a plain W3C 
DSig signature, and the ODF document still would be conforming. So, 
unless we mandate the use of XAdes signatures, the ODF specification is 
fine in this regard.

XAdes allows to store the certificate chain. So, unless we want to 
mandate that the certificate chain is stored, the ODF specification is 
also fine in this regard.

My understanding is that the requirements regarding digital signatures 
vary from country to country, and organization to organization. We will 
not only have difficulties to collect all of them, but they may also 
conflict. At least, what is required in one country may not be required 
by another country and may cause unnecessary implementation efforts.

If my understanding is correct, wouldn't it then not be reasonable to 
have only a minimum set of requirements in the ODF specification, so 
that individual countries or organization can amend them with their 
country specific rules? I don't know what the exact requirements in 
Belgium are, but if it is a requirement in Belgium that the digital 
signatures are XAdes signatures and contain the certificate chain, then 
Belgium would not only mandate conformance with the ODF specification, 
but additionally also with the XAdes specification, and would mandate 
that the certificate chain is included.

BTW: Maybe it is an option to collect such "signature profiles" in the 
OIC TC?

Best regards

Michael



On 05/05/10 19:02, David LeBlanc wrote:
> 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.
> ---------------------------------------------------------------------
> 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
> 


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Jürgen Kunz


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