Microsoft supports EU Signature standard in Office 2010
Microsoft has decided to support the EU digital signature format XAdES in Office 2010.
Read more about this at: http://blogs.technet.com/office2010/archive/2009/12/08/digital-signitures-in-office-2010.aspx
This format builds on the XML Digital signature standard from W3C which is the globally accepted standard for XML signatures.
XAdES adds a number of mandatory signed elements, which at least adds the signer’s certificate as a signed element.
In addition to this, the XAdES standard also defines how to bundle the signature with extended verification data such as time-stamps and revocation information. This supports verification over a longer period of time when that verification data is hard to obtain from public resources.
The long term signature validation data bundling has always been the advantage with XAdES, but the added signer certificate as a signed property has been the reason why this standard has taken so long to accept and implement.
The problem was that for a long time, you could not add the long term validation data according to this standard unless the original signature was a XAdES signature with added signed elements. This made the standard useless for all implementations of XML signatures following the global W3C standard, which still is the vast majority of XML signatures.
Adding the signer’s certificate as a mandatory signed element provides no real security advantage in the PKI trust model. All this does is that it prevents someone from suggesting the verifier to use another certificate for verification than the singer intended. However, in the PKI model it is the verifier’s right to pick whatever certificate the verifier trust to identify the signer. In these typical uses of the PKI trust model, this added security feature have no value and the only real threat it address (attempting to prevent trust in a Malicious CA) is not anywhere closely mitigated by this feature.
This has divided implementations of digital signatures in a way that harms deployment and interoperability. However, once implemented, the added signed elements does not cause any harm for a verifier.
It is therefore a good thing that Office now have decided to embrace this standard.
Read more about this at: http://blogs.technet.com/office2010/archive/2009/12/08/digital-signitures-in-office-2010.aspx
This format builds on the XML Digital signature standard from W3C which is the globally accepted standard for XML signatures.
XAdES adds a number of mandatory signed elements, which at least adds the signer’s certificate as a signed element.
In addition to this, the XAdES standard also defines how to bundle the signature with extended verification data such as time-stamps and revocation information. This supports verification over a longer period of time when that verification data is hard to obtain from public resources.
The long term signature validation data bundling has always been the advantage with XAdES, but the added signer certificate as a signed property has been the reason why this standard has taken so long to accept and implement.
The problem was that for a long time, you could not add the long term validation data according to this standard unless the original signature was a XAdES signature with added signed elements. This made the standard useless for all implementations of XML signatures following the global W3C standard, which still is the vast majority of XML signatures.
Adding the signer’s certificate as a mandatory signed element provides no real security advantage in the PKI trust model. All this does is that it prevents someone from suggesting the verifier to use another certificate for verification than the singer intended. However, in the PKI model it is the verifier’s right to pick whatever certificate the verifier trust to identify the signer. In these typical uses of the PKI trust model, this added security feature have no value and the only real threat it address (attempting to prevent trust in a Malicious CA) is not anywhere closely mitigated by this feature.
This has divided implementations of digital signatures in a way that harms deployment and interoperability. However, once implemented, the added signed elements does not cause any harm for a verifier.
It is therefore a good thing that Office now have decided to embrace this standard.