Re: draft updates

From:  "Joseph M. Reagle Jr." <reagle@w3.org>
Resent-Date:  Wed, 13 Oct 1999 14:52:55 -0400 (EDT)
Resent-Message-Id:  <199910131852.OAA05641@www19.w3.org>
Message-Id:  <3.0.5.32.19991013145251.00a25710@localhost>
Date:  Wed, 13 Oct 1999 14:52:51 -0400
To:  "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>

>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):..."

I agree that we need to try to get a reasonably consistent draft -00
out this week, but I think edited Security Considerations material is
sufficiently de-coupled that it can be inserted.

It would also be nice if the top level of the Table of Contents of
what we put out is pretty close to what it will be in final. This
makes the gaps and overall structure clearer.  No one has objected to
the ToC I posted a while ago.  While I'm not saying that should be
imposed, I do think that the sections where Siganture, SignatureValue,
SignedInfo, Object, and KeyInfo or the corresponding edited sections
and all their subsections should be pushed down one level into a Core
Syntax Details section or the like.

> 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. 

While this is a clear and more verbose format, for things that will
not need element internal strucutre, how much does it gain you?  We
could probably get along fine always using base64 and if you add
quoted-printable and maybe hex, what other encodings
(content-transfer-encodings, not charsets) will you need?  Do we need
a full element with content for something that will only ever have a
hand full of simple values?  Don't we lose the ability to default by
doing this?
	Sure, I can believe there is always some tiny probability that
a complex content-trasnfer-encoding with complex parameters becomes
important but for things of low enough probability, we can also assign
them to the mechanism of being provided for in XMLDSIGv2, designated
by a new namespace and usualy the "dsig2:" prefix.  :-)

> 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">

Why not generalize to URI's?  That way algorithm and encoding can go
there and be defaulted easily.

> 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>

Value at this level is more likely output from the Algorithm...

>           </Algorithm>

The possible need for both Parameters and Value seems to be a strong argument
for making them explicit elements.  This also provides a uniform way to
separate multiple Parameters.  Even if you want an opaque binary parameter,
you can encode that at the parameter level:

	<Algorithm>
		<Parameter encoding="urn:dsig:base64">
			ofijfjqr9tqu49r8hqenq9h==
		</Parameter>
	</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.

That seems like an odd exception. I would think it would depend on the
nature of the value/name pair, not how many of them there were,
whether you can make it a more susinct and easier to default but
limited "content" attribute rather than an element.

> 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. 

But, in general, you do need the Type.  At least for the case where
the Location is/has a fragment, you need the type to know how to
interpret it.  (And if you don't like fragments there, just assume a
Transformations the includes one.  And sine you need to be able to
pass Type along the Transformations chain and explicitly set it for
decodes, for example, it seems to me that it should be passed in as a
parameter to each Transformation.) ((You probably didn't need Type in
the example above because the HTTP GET will return a type, wont it? Or
maybe you wanted to override the type or charset...))

> ___
> 
> [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/

Thanks,
Donald

Received on Thursday, 14 October 1999 09:33:45 UTC