[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] Digital Signatures
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]