Re: Comments on core-991001

Thanks for the comments, see a few responses below...

From:  "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com>
Resent-Date:  Tue, 5 Oct 1999 17:34:47 -0400 (EDT)
Resent-Message-Id:  <199910052134.RAA28974@www19.w3.org>
Message-ID:  <EAB5B8B61A04684198FF1D0C1B3ACD194A702E@DINO>
To:  "W3c-Ietf-Xmldsig (E-mail)" <w3c-ietf-xmldsig@w3.org>
Date:  Tue, 5 Oct 1999 14:34:32 -0700 

>The following is a set of comments dealing with small changes that need to
>be made to the current draft.  Comments on actual content such as XML
>syntax, etc. will follow as appropriate.
>
>1.  All IETF drafts now require a patent statement a the top of the draft.
>Such as statement should be added to the document.

When/where was this requirement added?  None of my drafts have such a
statement.  Perhaps you mean copyright?  I think the IESG is very
close to requiring the ISOC copyright on all standards track drafts
but, as far as I know, they have not actually done so yet...

>2.  Example in section 2.0 should be a DSS example as this is the mandatory
>example.  I assume that at some point this will be come a verifiable example
>as well.
>
>3.  Section 3.0 -- In the ATTLIST SignatureValue is misspelled.
>
>4.  Section 3.0 -- SignatureValue is no longer an empty-tag element.
>
>5.  Section 3.0 - Insert reference to Base64.
>
>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.

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

>8.  Section 4.3.5 - This is no longer an empty-element tag.
>
>9.  Section 5.0 -- there are two DTD definitions for Object here.
>
>10.  Section 6.0 -- The DTD appears incorrect.  ANY can only occur once and
>not with any of the current defined items.  Should ANY be inside of the *?
>
>11.  Section 7.1 -- Please remove all references to MD5.  We should not be
>pushing the older potentially bad hash algorithms (after all MD2 is not here
>either).  SHA1 will cover our needs until the AES hash algorithm comes along

I'd be interested in others input on this point.  MD5 was
traditionally the hash algorithm used in IETF protocols until SHA1
came along.  Are there examples of IETF protocols with SHA1 but
without MD5?

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

>13. Section 8.1
>	- Step 2 - "Calculate the digest over the result of the
>transformations."
>	- Step 3 - formatting on objectreference is incorrect.
>	- Step 4 - space between SignedInfo/Element
>	- Step 5 - references step d
>	- Step f) - should be moved to step 6.
>
>14.  Section 8.2
>	- Step 6 - references steps c and d.
>	- Remove last sentence of step 6 -- this would go to description of
>canonicazation.
>
>15.  We assume that the editorial comments will be removed in the process of
>creating an IETF I-D. 
>
>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 Wednesday, 6 October 1999 00:38:01 UTC