[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: certificate chain and XAdes,was Re: [office] RE: Digital Signatures
Hi Bart, David, On 05/07/10 09:32, Hanssens Bart wrote: > Hi, > > well, I wouldn't mind creating an ODF 1.2 Signature Profile within the OIC like Michael suggested. 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. > > I do agree with David that leaving all options open will lead to interoperability issues (and make it > harder to implement / test) I do agree that too many options may lead to interoperability issues, but do we really have that many options in ODF? ODF signatures are XML DSig signatures. We may have to state this explicitly, but I would assume and suggest that all constrains that XML DSig defines regarding signatures, signature generation and signature validation also apply to ODF. 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? If not, that is, if XML DSig is considered to be interoperable, why should we then add additional constrains to ODF? Wouldn't it then not be the best to use XML DSig as is in ODF? So, I have no objections to restrict options where this is reasonable. But in this case, we are using an existing standard, and my (maybe wrong) assumption is that this is a standard which is accepted and implementable, so that we don't need any further restrictions in ODF. Best regards Michael > > Best regards > > Bart > > ________________________________________ > From: David LeBlanc [dleblanc@exchange.microsoft.com] > Sent: Thursday, May 06, 2010 5:59 PM > To: Michael Brauer - Sun Germany - ham02 - Hamburg > Cc: Hanssens Bart; 'ODF TC List' > Subject: RE: certificate chain and XAdes, was Re: [office] RE: Digital Signatures > > 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 > 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 -- 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]