XML Signature WG
XML Signature WG
For encoding issues, why not just use Base64 for SignatureValue and DigestValue. Solo: one day, the resulting might be XML CDATA, but till then, the algorithms that we use need to be encoded and Base64 makes sense. Call agrees to define encoding for those two values as Bas64.
We shouldn't appropriate the control of other institutuional namespaces, we should move back for dsig:foo for the short term until we resolve the issue satisfactorily.
Eastlake adds: "Result was elimination of Encoding attribute in DigestValue and SignatureValue, statement to be added to spec that encoding is base64 for all digest and signature algorithms defined in the spec and up to the algorithm writing for other digest and signature algorithms."
List proposal to allow the location to exist outside of SignedInfo. Call wants to keep location in the signature, it is a URI (not necessarily a URL) and the call prefers the employment of redirection/indirection through URIs not this syntax.
Move to <ObjectReference Location="http://www.ietf.org">.
Define null-location as <ObjectReference Location=""> as referring to this document, must be supported. Do we extend it to mean "#ID". No: Location is URI (including null) or IDREF.
(Can anyone remember the reason why we just don't use FragmentIDs?)
Eastlake adds: That was because Fragment IDs require dispatching on the MIME type as determined at run time, something a few people thought was valuable but most thought was unnecessarily complex. It also tends to lead to a facility for the Transform pipeline too pass this type along.
Placing more volatile fields first might make it harder for bruteforce attacks. Are things like c14n expansion, field ordering really important to the security given our hash algorithms? Do we add a nonce? Call: take to list. (Bartel doesn't want nonce just for static text. Eastlake: some algorithms are weak and might need a nonce, but those are not the best algorithms.) Fox will talk with Jim and crypto guys as to whether we need about how sensitive we need to be about small bits of text, field ordering, and redudancy.
No one on the call is opposed to "parameterizing" transform, but Boyer had voiced opposition in the past. (No decision, continue discussion with Boyer present or on list.)
Call agrees to list Quoted-Printable as an optional encoding, part of the same MIME reference as the Base64.
Fox completed her action item; Eastlake acknowledges.
Eastlake adds: "Actually, on the second item, the call the previous week wanted the spec to prohibit such recipient identificaiton information from being in KeyInfo and say it should be elsewhere if needed.
Couple of additions, KeyInfo should be defined as ANY and should also have an ID attribute associated with it.
Solo: "signature properties" everyone agrees.
KeyInfo is also a type of property of an Object. There's discussion as to if you want to have the signature include the KeyInfo, whether you place a KeyInfo in an Object, or just point to the KeyInfo (under Signature) from an ObjectReference. Eastlake: ObjectReference could just point to KeyInfo ID instead of sticking it inside an Object. Call seems favorable but need to think about it more.
Put signed-properties as a sub-element of an open content model Object. This allows us to say the stuff in the signed-property bucket can include external XML elements, but that they should/must only carry semantics about the signature generation (like device, or time.)
If we define signing time, should be part of a non-normative chapter or seperate document (Reagle would like t to have its own namespace for purposes of demonstration.)
...
We use the "Properties" to designate that this is an open content bucket for semantics about the signature itself, of course, other people can put other semantics in an object if they want.
Reagle aside: one thing we need to address in our defininitions are things like attribute, property, and such given there are so many collisions.
Ed Simon said he would attempt a Schema.
Reagle: restate what I though the consensus was
Solo restatement: SignedInfo: the absense of the c14nMethod then there is no c14n, this is also consistent with Transform. Continue discussion on list.
Eastlake adds: "Actually what happened was that Dave suggested that we needed to re-introduce the explicit Null canonicalization due to the controversy over canonicalization of SignedInfo. I suggested that it wasn't necessary becasue we could change CanonicalzaitonMethod back to having a "?" after it and declare its absence to mean null canonicalization. This makes it more parallel with Transforms. There was general agreement with this among those on the call."