Re: draft updates

Since Don said he was going to reply to this, I didn't mean to have
"technical" discussion off list, and if any thread develops, it should be on
the list.

Forwarded Text ----
 Date: Wed, 13 Oct 1999 12:21:52 -0400
 To: david.solo@citicorp.com
 From: "Joseph M. Reagle Jr." <reagle@w3.org>
 Subject: Re: draft updates
 Cc: bfox@microsoft.com, dee3@torque.pothole.com, mbartel@jetform.com, "John
Boyer" <jboyer@uwi.com>
 In-Reply-To: <H0000cc404736fc1@MHS>
 
 At 09:49 99/10/12 -0400, david.solo@citicorp.com wrote:
  >Here's where I'm at as of this morning.  I've tried to incorporate much
of the 
  >material from the last few days on the list.  I've inserted Don's
material with 
 
 Since we need to move quickly on getting this published, we should stop any
additional text inclusion, cut if necessary and focus on making sure that
what we have (even if not happy with it) is at least internally consistent.
So for instance, based on Bartel's text, we aren't using "urn:dsig:base64"
any more, but "urn:(ietf | w3c):..."
 
 A bigger issue I'd like to see addressed, and perhaps something we won't
have done for the first draft is a restatement of my syntax question. I
don't think I like the structure as proposed in [1], but if we go that way
should we do the same with the encoding? I tried to look at the
specification and discern some conventions, but given its draft state and
many edits, it's rather hard. For instance, in looking at digest, the digest
has a value that is a literal. It also has other properties with literal
values. To me, this is what we are saying:
 
 <Digest>
   <Algorithm>dsig:sha-1</Algorithm>
   <Encoding>dsig:base64</Endoding>
   <Value>ab3234c34</Value>
 </Digest>
 
 This sort of structure makes it very clear what is happening. Also, it can
be re-used elsewhere. 
 
 Here's a possible suggestion with 3 simple rules. I'm not sure if this is
the right or best solution, but I suspect if we had a couple
conventions/rules we'd have a much greater degree of consistency.
 
 1. Reserve use of quoted-attributes for identifiers, namespaces, and xlinks.
         <Signature Id="1" xmlsn="http://www.w3.org/1999/10/signature-core">
 2. Simple simple name/value pairs that describe something then use an
element with content
         <Digest>
           <Algorithm>dsig:sha-1</Algorithm>
           <Encoding>dsig:base64</Endoding>
           <Value>ab3234c34</Value>
         </Digest>
 3. If a name/value pair needs to be further qualified, or you want its
content model to be open, then do not use its content for a value.
           <Algorithm>
                 <Parameter>
                      <Type>blah</Type>
                      <Value>34</Value>
                 </Parameter>
                 <Value>urn:ietf:sha-1</Value>
           </Algorithm>
 
 The resulting syntax under these productions is (notice the ObjectReference
HREF):
 
 <Signature xmlns="http://www.w3.org/1999/10/signature-core"> 
   <SignedInfo> 
     <CanonicalizationAlgorithm>null</CanonicalizationAlgorithm>
     <SignatureAlgorithm>urn:ietf:dsaWithSHA-1</SignatureAlgorithm>
     <ObjectReference HREF="http://www.iet.org"/> 
       <Type>text/html; charset="us-ascii"</Type> 
        <Digest>
          <Algorithm>urn:ietf:sha-1</Algorithm>
          <Encoding>urn:ietf:base64</Endoding>
          <Value>ab3234c34</Value>
        </Digest>
     </ObjectReference> 
   </SignedInfo> 
   <SignatureValue>
          <Encoding>urn:ietf:base64</Endoding>
          <Value>ab3234c34</Value>
   </SignatureValue>
   <KeyInfo> 
      <keyname>Solo</keyname> 
   </keyinfo> 
 </Signature> 
 
 It results in slightly more verbose syntax, that might be alleviated by an
exception to rule 1: "However, if you only have one value/name pair that you
wish to associate with an element, you may place it as a
quoted-attribute&value" but I was trying to be very clean above.
 
 This also clarified something for me. The SignatureValue structure could
look just like Digest, but you want the signature algorithm in the Signinfo
for the convenience/security of signing, but what about encoding? I guess
the specification states there is only one permissible encoding of the
signature value...? Also with <type>, does this information need to be
validated by the signature verifier? I assume not? If the type information
is actually text/ascii, but that is what the signature was generated over,
the signature will still pass. So in a sense we are permitting semantic
information in the signature that can be incorrect but will still result in
a valid signature? I've been trying to avoid this, that's why I pushed for
signedattributes to live elsewhere. Kind of like an unrealized requirement
of mine I guess:
 
 1. No semantic information that will not be able to affect the signature
validation should be permitted within the signature. 
 ___
 
 [1]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999OctDec/0054.html
End Forwarded Text ----

_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://w3.org/People/Reagle/

Received on Wednesday, 13 October 1999 14:52:50 UTC