RE: [office] Digital Signatures

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

I go by David, but I've been called far worse than Dave...

If I'm not mistaken, the meeting would be at 5:30 AM Pacific? I think I'd have to be specifically needed to be up at that hour. If signatures is the topic, then I can get up early.

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
Sent: Tuesday, May 04, 2010 7:01 PM
To: David LeBlanc
Cc: office@lists.oasis-open.org
Subject: Re: [office] Digital Signatures

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
>