Re: Comments on core-991001

Jim,

From:  "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com>
Resent-Date:  Wed, 6 Oct 1999 14:54:40 -0400 (EDT)
Resent-Message-Id:  <199910061854.OAA28379@www19.w3.org>
Message-ID:  <EAB5B8B61A04684198FF1D0C1B3ACD194A7038@DINO>
To:  "'Donald E. Eastlake 3rd'" <dee3@torque.pothole.com>,
            "W3c-Ietf-Xmldsig (E-mail)" <w3c-ietf-xmldsig@w3.org>
Date:  Wed, 6 Oct 1999 11:54:21 -0700 

>> From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com]
>> Sent: Tuesday, October 05, 1999 9:38 PM
>> To: W3c-Ietf-Xmldsig (E-mail)
>> Subject: Re: Comments on core-991001 
>> 
>> Thanks for the comments, see a few responses below...
>> 
>> From:  "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com>
>
>> >6.  Based on input from mailing list -- please change 
>> c14nAlg as an element
>> >to fully spelled out.
>> 
>> People wanted Signature spelled out and a few other things but I'm not
>> sure about alg.  Given that it is immediately followed by an
>> "Alogrithm" attribute, it seem awefully redundant to spell it out.
>
>My worry is less about Alg than c14n.

I though the responses on expanding xNNy in the body of the draft
text was somewhat mixed and I'm not sure there were many comments
on expanding it in the formal XML...

>> >7.  Section 4.3.1 - I know that we were one of the people 
>> who wanted to make
>> >the location optional.  What we had in mind was the 
>> following statement:
>> >"If the location is omitted, then the content being signed 
>> is the first
>> >Object in the immeadiate surrounding Signature."
>> 
>> Do you mean "... in the element immediately surrounding the
>> Signature."?
>
>No, I mean the immeadiate surrounding Signature
>
><Signature>
>  <SigInfo/>
>  <SignatureValue/>
>  <Object/>
><Signature/>
>
>The location in the SigInfo references the object in the Signature block.

Interesting.  I had assumed you wanted something more like

<SimpleProtocol>
	<SignedStuff/>
	<Possible unsigned stuff/>
	<Signature>
		<SigInfo/>
		<SignatureValue/>
	</Signature>
	<Possible more unsigned stuff/>
</SimplePrototocol>

>> >12.  Please remove references to AES algorithms.  There will 
>> be a block
>> >cipher finalist bext year and there is no hash yet. .
>> 
>> I think there should be a note saying we expect these things to come
>> along but not table entries for them.
>
>Why do we even make that statement?  We should just update the RFC when and
>if they come out.  I see no benifits in saying it will be coming, there are
>a large number of things that I see as coming that are not listed.  How does
>the fact they they are coming change this specification?

While I don't think there should be idle chatter about the future, it
is a matter of judgement how much motivational material there should
be.  Expecially if we drop MD5, saying we expect an AESH to come along
provides a concrete motivation for hash algorithm variability in the
protocol instead of just saying its always SHA1.  I know algorithm
independence is good in itself but some people would be more persuaded
by the anticipated emergence of new/better hashes in the forseeable
future.

>> >Jim Schaad and Barbara Fox
>> >Microsoft
>> >	-
>> 

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 Thursday, 7 October 1999 08:17:21 UTC