Re: Editorial Convention Rules #2

From:  "Joseph M. Reagle Jr." <reagle@w3.org>
Resent-Date:  Tue, 19 Oct 1999 18:39:36 -0400 (EDT)
Resent-Message-Id:  <199910192239.SAA16026@www19.w3.org>
Message-Id:  <3.0.5.32.19991019183929.00a54490@localhost>
Date:  Tue, 19 Oct 1999 18:39:29 -0400
To:  "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>

>One thing I realized that was causing me difficulties is our reliance upon
>the terms "algorithm" and "value" that appear in the actual element names --
>other times they are nested elements, or other times attributes (sometimes
>called type, sometimes call name)! The reason this first happened was
>because the "algorithm" and "value" information was moved from the signature
>element and placed in sign_info for processing purposes. I think this is
>ugly, and would've preferred something else (with a perhaps slightly more
>complex set of processing rules) but acknowledging what we have now, there's
>another proposal below. A bit different than my first.

I think things have been so inconsistent because you are comparing
different proposals in the absence of any rule providing consistency.

>http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999OctDec/0073.html
>I really don't like either and wish we could remove "algorithm" and "value"
>from the actual element name, but then SignatureAlgorithm and SignatureValue
>would still present an inconsistency.  I hope better minds than my own can
>come up with a good proposal...
>
>Reagle's Second Proposal
>
>    1. If you use the term "Value" or "Algorithm" in the element name,
>       then the content of that element must be a literal value or
>       algorithm designation. (Consequently) If you need to nest other 
>       content in an element, it must not contain the term Value or
>Algorithm 
>       in its name.

That means you can't have any Parameters for an algorithm in that
case...

I understand that to be pleasantly readable, we need to avoid things
like <SignatureAlgorithm Algorithm="..."/> but there are ways to do
that without being inconsistent about handling URIs.  Since attributes
are more compact (no close tag) and easy to default and since URIs
don't ever need visible XML element structure, I think we should put
URIs, like algorithm specifiers, in attributes.  (If you allow
framents and have a hairy fragment specifier it might have element
structure in it but that should be escaped with &lt; etc. and not be
visible to the initial parse.)

Values generally aren't URIs, generally don't have default values, and
perhpas could, although I admit its pretty far fetched, have element
structure, so I would not make them attributes in any case.

I don't think it is worth obsessing too much on the parallelism
between Signature and Digest and Transfomration.

>    2. Otherwise, all URIs should be listed as an attribute value.
>       
>   <Signature xmlns="http://www.w3.org/1999/10/signature-core">
>     <SignedInfo>
>       <CanonicalizationAlgorithm>null</CanonicalizationAlgorithm>
>       <SignatureAlgorithm>urn:ietf:dsaWithSHA-1</SignatureAlgorithm>

How about
        <SignatureMethod Algorithm="urn:ietf:dsaWithSHA-1" />

that way we could settle on 'Algorithm="URI"' for all out algorithm
specifications and it would allow <Parameter>s if needed by some
signature algorithm.

>       <ObjectReference HREF="http://www.iet.org"/>
>         <Type>text/html; charset="us-ascii"</Type>

see comment below...

>         <DigestValue Algorithm="urn:ietf:sha-1"
>            Encoding="urn:ietf:base64">ab3234c34</DigestValue>

Maybe
          <Digest Algorithm="urn:ietf:sha-1" Encoding="urn:ietf:base64>
             <Value>ab3234c34</Value></Digest>
in case some future digest algorithm has Parameters, like how many bits
to output...  (and probably the Algorithm and Encoding used in the
example above are defaults so it could actually be
          <Digest><Value>ab3234c34</Value></Digest>

>       </ObjectReference>
>     </SignedInfo>
>     <SignatureValue
>   Encoding="urn:ietf:base64">ab3234c34</SignatureValue>
>     <KeyInfo>
>       <keyname>Solo</keyname>
>     </keyinfo>
>   </Signature>
>   
>Type is still weird since it might be a MIME/Type or URN ....

Yes, I can't think of any simple solution for that.  You could
make Type an attribute by escaping any troublesome characters
when it's a MIME Content-Type.

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

Note that if we make URIs attributes, then Location would be an
attribute.

Thanks,
Donald
===================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668   dee3@torque.pothole.com
 65 Shindegan Hill Rd, RR#1  +1 914-784-7913(w)     dee3@us.ibm.com
 Carmel, NY 10512 USA

Received on Wednesday, 20 October 1999 13:43:01 UTC