At 4:06 PM -0500 2/29/08, Turner, Sean P. wrote:
>In addition, it is not acceptable to reference in the
*normative* references "work in progess", i.e.[ECCADD].
I'm pretty sure this is done all the time. There are 17 IDs in the RFC
editor queue with works-in-progress in normative references.
Sean is correct. This will cause the draft to be stuck in the RFC
Editor publication queue until the other document becomes an RFC, but
there is absolutely nothing wrong with this in a last-call draft.
>The same applies for [SHS]. The text states:
NOTE [to be removed upon publication as an RFC]: NIST has not yet
finalized FIPS 186-3 and there is a chance that the draft may be
changed. This may result in differences between what is documented
in the current version of this document and what is in the
FIPS. It
is intended to synchronize the final version of this draft with the
FIPS before publication as an RFC.
The FIPS PUB 186-3 part that this ID needs has very little chance of
changing. The WG wanted this note to be safe.
Again, Sean is right. It is quite common to have comments like "This
section to be removed upon publication" in documents going into the
RFC Editor queue.
>There is a more substantive comment on the first paragraph of
section 1.
The text states:
If an implementation chooses to support one of the algorithms
discussed in this document, then the implementation MUST do so as
described in this document.
I believe the text should be:
If an implementation chooses to support one of the algorithms
discussed in this document, then the implementation MUST do so as
described in [SHS].
The algorithms aren't defined in this document only the OIDs and where they
go in CMS ... so I still think it's actually "as described in this
document". But, Spencer suggests removing the sentences because they're not
needed and I tend to agree with him.
Spencer wins on this one. The sentence doesn't make much sense in a
standards-track document.
>A small discussion in the security considerations section on
the advantages (in particular in terms of performances versus
security) of using one or another function from the SHA2
family would be helpful.
I'll see if I can't get something from NIST (or at least point to it).
I'll disagree with this. These are not security considerations; they
are performance considerations. And pretty obvious ones at that.
>While I welcome this draft, everybody should take into
consideration that, if the SHA2 family happens to be broken
then we will be at risk.
This should be mentioned into the security considerations section.
If an algorithm is cracked then isn't it obvious that we're in trouble? No
other algorithm document I could find says something like this so I'm
inclined to not include this in the security considerations section.
... or anywhere else. If any algorithm (hash, encryption, signing,
...) is broken, it is broken. Sean's right here.