RE: [office] What to do about digital signatures

[David LeBlanc <dleblanc@exchange.microsoft.com>]

I have been attempting to avoid making specific proposals, because I do not feel like it is truly my place to define the standard. However, given that I'm the one person here who has actually written the code to create and verify xmlDSig and XAdES signatures, perhaps it would be good to put a proposal on the table, and then we can get the other implementers to comment and provide direction. I do not yet know the precise language for the document format, so please forgive me if I use incorrect terminology. For example, I see files in a zip archive. We refer to these as 'parts' in OOXML - I'll call them files below until I'm corrected, ditto with folders.

1) An ODF document signature shall be created using a signature as specified in [xmldsig]. An implementer is encouraged to support extensions as defined in [xades].

2) A document signature shall be created by signing the files contained within the archive based upon the unencrypted content of each file. A document signature may sign all or a portion of the document. If all of the document is to be signed, all files within the archive, excepting files contained within the META-INF folder, shall be contained within the signature by creating a Reference element for each as defined in [xmldsig].

3) A document signature shall be placed within the document-signatures element in the META-INF\documentsignature.xml file. A non-document signature may be created and placed in META-INF in a file to be defined by the implementer.

4) A KeyInfo element, as specified in [xmldsig], section 4.4 shall be present. The KeyInfo element shall contain an X509Data element containing at least an X509IssuerSerial element specifying the issuer and serial number of the signing certificate, and an X509Certificate element specifying the full signing certificate. Additional X509Certificate elements may be placed in the X509Data, or may be placed in the CertificateValues element of the XAdES Object, as defined in [xades] section 7.6.1. The additional certificates should represent the entire primary certificate chain used at signing time. [NOTE: This codifies what OOo is doing now.]

5) The Reference elements specifying the hash of each signed file within the archive shall contain a Type attribute specifying the type of data which is signed. [ NOTE - this needs refinement] Files contained within the archive shall have paths with a root established at the root of the archive, and shall have a Type of [ something specific to ODF here]. Reference elements with other Type attributes shall be considered to have a URI as defined in [xpath]. A Reference to an Object element within the Signature should have a Type attribute of "http://www.w3.org/2000/09/xmldsig#Object";, and the Reference element specifying the hash of the XAdES SignedProperties element (if present) shall be as specified in [xades] section 6.3.1. [NOTE: This is a proper solution to the path resolution problem.]

5a) [TO BE DISCUSSED] Alternately, Reference elements specifying the hash of archive files may be placed in a Manifest element contained within an Object element, and it is implied that the paths shall refer to files contained within the archive, and the URI path shall be resolved from the root of the archive. [TBD - need to create a way to uniquely identify this Object]

6) The only permitted Transform elements which apply to files contained within the archive shall be canonicalization transforms, as specified in [xmldsig], section 6.5. [Note - mayhem can ensue if you allow an XLST transform, and you can end up signing odd things and throwing parsers into infinite loops - this is an important restriction.] A canonicalization Transform MUST be specified for all XML files.

7) The signing time shall be specified in the [Object you already create - #include <existing_spec>], or may be specified using the SigningTime element as specified in [xades] section 7.2.1.

[ Note - I am taking the following sections from MS-OFFCRYPTO for my own convenience. I believe we have made good choices, but I am asking for a critical analysis from other implementers. I will make notes about why I have made each choice. I've also removed cases where I feel like I over-specified, and also removed conflicts with placing the rest of the cert chain into KeyInfo.]

8) The Object element containing the [XAdES] information has a number of optional elements, and many of the elements have more than one method specified. A document compliant with this specification, which uses the [xades] extensions uses the following options:

   a) The SignedSignatureProperties element MUST contain a SigningCertificate property as specified in [XAdES] section 7.2.2. [NOTE - XAdES schema says this is optional, but is required to meet XAdES-BES or higher. XAdES-BES is the lowest level.]
  b) A SigningTime element MUST be present as specified in [XAdES] section 7.2.1. [NOTE: same as (a)]
  c) If the [XAdES] information contains a time stamp as specified by the requirements for XAdES-T, the time stamp information MUST be specified as an EncapsulatedTimeStamp element containing DER encoded ASN.1. data. [NOTE: There is not a standard way to express a time stamp yet, so you have to specify something. This is the only standard way to do it now.]
  d) If the [XAdES] information contains time stamps on references to validation data, the SigAndRefsTimestamp element as specified in [XAdES] sections 7.5.1 and 7.5.1.1 MUST be used. The SigAndRefsTimestamp element MUST specify the time stamp information as an EncapsulatedTimeStamp element containing DER encoded ASN.1. data. [NOTE: Same problem as in (c)]
  e) There MUST be a Reference element specifying the digest of the SignedProperties element, as specified in [XAdES], section 6.2.1. As specified in [XMLDSig], a Reference element is placed in one of two parent elements:
    - The SignedInfo element of the top-level Signature XML.
    - A Manifest element contained within an Object element.
A document compliant with this specification should place the Reference element specifying the digest of the SignedProperties element within the SignedInfo element. 
[NOTE: There is an ambiguity in the XAdES spec with respect to where the Reference element should be placed, this resolves it to what we believe (and have mail from Juan Carlos Cruellas) to the be the intent of the spec.]

So here's a reasonably specific proposal - I'd like to get this resolved and into the 1.2 standard. What you wrote about how we create standards earlier today was insightful, but in this case we have an advantage that only one of the implementers has an xmldsig implementation at all, and it is only the first version. None of us have a ODF signature with XAdES, so it would be great if we could all come to an agreement and have good interoperability from the very start.

I'm looking forward to getting feedback, analysis, and commentary. Perhaps this proposal can help us meet Robert's valid concerns about timeliness.

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
Sent: Friday, May 07, 2010 11:51 AM
To: office@lists.oasis-open.org
Subject: [office] What to do about digital signatures

We've been discussing this on the list for a few days now.  I think we're getting a better feel for the scope of what needs to be done, thanks to David's recent notes. . But I haven't seen a specific proposal yet.  I'm having some IBM colleagues look at this issue as well, since it is outside of my expertise.  But I will comment quickly on what our options are at this point:

1) Continue discussing and delay ODF 1.2 until we have a resolution.

2) Continue discussing, send ODF 1.2 out for public review knowing that this issue is open, and commit to resolving it when the public review ends.  But know that changes made after the public review would trigger another 15-day public review of those changes.

3) Remove the feature from ODF 1.2.

4) Do nothing in ODF 1.2, but address this area in a future revision.

5) Convince ourselves that there is not a problem ;-)

Are there any other options I've missed?

I think if we have the right people looking at this area, we should be able to resolve it in ODF 1.2.  So to me that sounds like option #1 or #2. 
 

Since the digital signature feature is not broadly entangled in the other 
features of ODF 1.2, I think it can be reviewed and revised without 
invalidating the review performed on other parts of specification.  So I'm 
inclined to recommend that we pick option #2. 

I reminded of the saying, 'Never code standing up', meaning if you are in 
a rush to leave the office, and you already have your hat on, and you are 
making one last change to the code while standing up to put on your coat, 
then you are asking for trouble.  I think we want to also avoid specifying 
security-related ODF features standing up.  Let's take a couple of months, 
during the public review of ODF 1.2, to figure out exactly what needs to 
be done here.  This will allow us to continue discussions at a deliberate, 
but unrushed pace.  We could continue discussions on the main TC list.  Or 
if we wanted to have a separate list and maybe a series of meetings on the 
subject (yes, more meetings) we could choose to form a "ODF Security 
Subcommittee".

Any thoughts on the process side of this, before we get back to discussing 
the details of XAdES?  In particular, any objections to #2?

-Rob

---------------------------------------------------------------------
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