[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]