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

The key point is that there are many options within xmlDSig, and XAdES, which extends xmlDSig. If all options are open without even a SHOULD to guide the implementer, then we will all have to implement completely arbitrary parsers. I think this will tend to make implementations less interoperable, and from a practical standpoint, lead to bugs.

For example, I can store the certificate in an X509Certificate element, or I can provide a link to where to find it externally, and there are other options. I don't feel like it is appropriate for the standard to turn every minute decision into a MUST, but the standard ought to narrow the scope just a bit.

What I'd suggest is that the standard define a subset that an implementer MUST accept, perhaps some items that SHOULD be accepted, and prohibit nothing that is not already constrained by the two standards we're including. 

For example, the xmlDSig standard requires that an implementer MUST support the C14N canonicalization algorithm, but may also use other algorithms. Thus if you want to ensure interoperability, you can write to the portion of the standard that is required, but if you need to do something specialized, that's available.

The requirements which vary are all around the cryptography employed, and this standard should avoid specifying the algorithms for a digital signature. Countries and organizations don't get into the business of deciding how I should store the certificate in the KeyInfo element. I meet these requirements in the implementation that Microsoft Office uses, and I also documented the choices made so that we would not impede interoperability.

From: Michael.Brauer@Sun.COM [Michael.Brauer@Sun.COM]
Sent: Thursday, May 06, 2010 5:51 AM
To: David LeBlanc
Cc: Hanssens Bart; 'ODF TC List'
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

Best regards


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
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

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]