OASIS Open Document Format for Office Applications (OpenDocument) TC

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

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

Hi,

well, I wouldn't mind creating an ODF 1.2 Signature Profile within the OIC like Michael suggested.

I do agree with David that leaving all options open will lead to interoperability issues (and make it
harder to implement / test)

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

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

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 

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 

Michael,

I would say that everywhere there is a "SHOULD," "MAY,"
"implementation-defined," and especially "implementation-dependent"
(including when implicit in the omission of sufficient detail for it to be
anything but implementation-dependent) that is PERMISSION TO CONFORMING
PRODUCERS, we need to consider the unnatural acts and barriers that this
imposes on consumers.  

In particular, a consumer that is intended to be interoperable must either
provide for every permitted case or else do the obvious thing and find out
what particular alternatives significant producers actually implement,
supporting those specific cases.  And, for the sake of interoperability, the
sibling producer, if any, that is intended to be interoperable with
significant producers would adopt only those cases too.  Those who rely on a
primary producer's code base have a reliable way of doing that, including
perpetuation of what, in accordance with the ratified standards, is probably
a bug or an even worse defect.  But now a de facto defect.  So the danger is
that the only practical solution is a mono-culture of implementations that
are the only ones the user community can trust to provide some modicum of
interoperability.

If that is the best we do, it is not clear why we would bother to put all
this effort in the name of an interoperable, independently implementable
(sort-of) specification for an international standard.

Thanks for asking.


  - Dennis
  - - - - - - - - - - - - -
   Standards are arbitrary solutions to recurring problems (R. W. Bemer)
   Although not by becoming the recurring problem (orcmid).
  When you find yourself in a hole, stop digging.




                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
Sent: Friday, May 07, 2010 00:52
To: Hanssens Bart
Cc: David LeBlanc; 'ODF TC List'
Subject: [office] Re: certificate chain and XAdes, was Re: [office] RE:
Digital Signatures

[ ... ]

I do agree that too many options may lead to interoperability issues, 
but do we really have that many options in ODF?

[ ... ] 

"Dennis E. Hamilton" 

I'm willing to modify my statement to be

"Everywhere there is a "SHOULD," "MAY," "implementation-defined," and
especially "implementation-dependent" (including when implicit in the
omission of sufficient detail for it to be anything but
implementation-dependent) that is PERMISSION TO CONFORMING PRODUCERS, we
need to consider *any* unnatural acts and barriers that this imposes on
consumers."

To clarify further: I was not distinguishing natural and unnatural with
regard to the history of office productivity software.  That has nothing to
do with it.  I was using unnatural with regard to over-burdening conforming
implementation of interoperable consumers of any standard format by having
to support provisions that no conforming producer might ever emit and that
places consumers at the mercy of prominent producers (who one can expect to
consume what they emit and perhaps little else).

And with regard to Michael's question, "but do we really have that many
options in ODF?" I must say, "Afraid so."

 - Dennis

A HANDY ILLUSTRATIVE EXERCISE

Although I meant this concern for optionality quite broadly, I have a great
example before me in ODF 1.2 Part 3 cd03-rev04-editor-revision.odt.  I will
doubtless add JIRA issues about this and any similar cases that I find.  But
here it is as an example of what there is when one reviews specification
material with a concern over sufficient but not too many options and the
minimization of dependence on out-of-band agreements of any flavor.

1. This is all about 3.8.3 manifest:checksum-type.  This is new to ODF 1.2
and a big improvement, because before this, 3.8.2 manifest:checksum was
implementation-dependent and there was no clue what it was a checksum of.
On the other hand, it is now too complicated in the following respects:

2. Consumer More Constrained than Producers.  The last paragraph of 3.8.3
explicitly REQUIRES consumers to support SHA1/1K and SHA256/1K (by whatever
URI or fixed attribute value is used).  The last paragraph explicitly
RECOMMENDS that producers use an SHA256/1K algorithm and makes no additional
conformance provision on producers in that paragraph.  Note that, with
respect to [xmlenc-core] these are *ALL* "an alternative algorithm as
specified in §5.1 of [xmlenc-core]," so I suppose the last list item in
3.8.3 should really say "any other alternative algorithms as specified in
§5.1 of [xmlenc-core]" (see 4, below).

3. I note that both manifest:checksum-type and manifest:checksum are now
required attributes of the