Re: [office] Digital Signatures

[robert_weir@us.ibm.com]

I should have said it before, but welcome aboard!

 Do you go by David or Dave?  (We already have one David, but we can 
manage either way).

I know it is early for those in the west coast, especially for a Monday 
morning, but I hope you can join us for our weekly TC meeting, which is at 
1330-14130 UTC.  You can see the meeting schedule here:  
http://www.oasis-open.org/apps/org/workgroup/office/event.php?event_id=26793&day=1273485600

Note that meetings for the last two Monday's in May are canceled.  I think 
you can get the events in iCalendar format by clicking the "download" on 
the above page.

I've put a few other bits of possibly useful information in this wiki 
page, which you might want to look at:  
http://wiki.oasis-open.org/office/New_Member_Orientation

Regards,

-Rob
Co-Chair, OASIS ODF TC

David LeBlanc <dleblanc@exchange.microsoft.com> wrote on 05/04/2010 
08:48:51 PM:

> 
> [office] Digital Signatures
> 
> I'd like to start off by asking a few questions - my primary 
> interest is achieving a specification that gives me as an 
> implementer enough information that I can sign ODF documents and 
> interoperate with other implementers. I'm also the author for the 
> MS-OFFCRYPTO document where we specify our handling of encryption 
> and digital signatures, as well as being the developer who deals 
> with the core digital signature code for Office.
> 
> Just saying that you can sign a document with xmlDSig and optionally
> include XAdES information provides (IMHO) an overly loose 
> specification. An implementer than has to worry about having a 
> completely arbitrary xmlDSig and XAdES parser, and that can 
> certainly lead to complications. Given that I do not currently have 
> an implementation for ODF, I don't have a lot of energy on the 
> choices you make, but I would like to be able to sign ODF documents 
> with Office.
> 
> To get into the details, a Signature element is composed of:
> 
> - SignedInfo
> - SignatureValue
> - KeyInfo (0 or 1)
> - Object (0 or more)
> 
> The SignedInfo contains the Reference elements to be signed, among 
> other things. Some implementations have Reference URIs that resolve 
> to XML external to the Signature, others may have a requirement that
> these top-level Reference elements may only resolve to XML within 
> the Signature, typically an Object element, a Manifest element 
> contained within an Object, or in the case of XAdES, 
> SignedProperties. If the top-level References must have URIs that 
> resolve internal to the Signature, then a Manifest would be 
> required. Using a Manifest is of some benefit, because resolving the
> References contained within an Object is defined as app-specific, 
> which makes you free to have a Transform that may be something 
> defined outside of xmlDSig. I don't know if such a Transform would 
> be needed for this application. The reason I ask about this is that 
> a Transform could potentially cause problems - for example, an XLST 
> transform could lead to a violation of "What you see is what you 
> sign". It may be beneficial to make a requirement that a top-level 
> Reference may only have a canonicalization transform.
> 
> SignatureValue is non-controversial - it is just base64 encoding of 
> the actual signature bits.
> 
> KeyInfo is listed as optional, but I'm not sure how a practical 
> signature (especially for a document) could exist without one. The 
> catch with this element is that it has quite a lot of flexibility 
> (see [xmldsig] section 4.4). 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. It would be helpful if the standard specified which of these 
> choices were required, allowed and disallowed.
> 
> An Object is used to contain a Manifest for app-specific References,
> and an Object is also used as a container for the single XAdES element.
> 
> There are a similar series of decisions to be made when implementing
> a XAdES element - for an example of the decisions we made, you can 
> look in section 2.5.2.6 of MS-OFFCRYPTO. I am not saying that these 
> decisions are globally the right thing for other document types, but
> that we need to consider branches in the implementation and what 
> choices to define.
> 
> A complex issue is exactly what within a document must or should be 
> signed, and how partial signatures might be treated. This can be 
> left up to implementers to provide flexibility, but the trade-offs 
> are that if you don't sign enough, then you have a loose signature 
> that might not be valid from a security standpoint, and if you sign 
> too much, then you might have signatures that get broken just by 
> updating metadata.
> 
> A final point is that there are already some implementers making 
> signatures today, and it would be a good thing to have their 
> existing signatures meet the specification, assuming they're not 
> doing anything incorrect. I don't know which implementers are making
> signatures now - it would be helpful to me to know that and see what
> I might end up parsing.
> 
> There are other issues, such as encrypt then sign, or sign then 
> encrypt, but I don't want to deal with too much all at once.
> 
> Thanks for allowing me to join this group, and I hope I can be of help.
> 
> 
> 
> ---------------------------------------------------------------------
> 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 
>