Indeed, that was my first reaction as well. Both RFCs are standards track, which I have been told updating is an involved process, especially since RFC3230 hasn't seen much implementation until we started using it (AFAIK). Now we have a few clients and more on the way.
I was advised just to update the registry. It is out of date and contains inconsistencies. On Sat, Dec 5, 2009 at 12:34 AM, Eran Hammer-Lahav <[email protected]> wrote: > This raises the obvious question - shouldn't we take greater action than > simply update one of them? Should we consider combining them? Perhaps update > the reason why we have them and make them more useful for other use cases? > > I am just looking for clarifications. > > EHL > > >> -----Original Message----- >> From: Anthony Bryan [mailto:[email protected]] >> Sent: Friday, December 04, 2009 5:21 PM >> To: Eran Hammer-Lahav >> Cc: [email protected]; HTTP Working Group ([email protected]) >> Subject: Re: Last Call: draft-bryan-http-digest-algorithm-values-update >> (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC >> >> Eran, to my knowledge there is no relationship between the two registries, >> besides some overlap. The registry you mention appears to be just hash >> function names and references a few X.509 RFCs. I don't know about the >> history but it seems to be a more generic list. (We reference that registry >> in >> draft-bryan-metalink). >> >> Here is the registry draft-bryan-http-digest-algorithm-values-update >> would update: >> Hypertext Transfer Protocol (HTTP) Digest Algorithm Values >> http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml >> >> RFC 3230, which created this registry, doesn't refer to it by name, which >> isn't >> too helpful in finding it. The algorithms haven't been updated, so the newest >> entry is SHA, and some other references were inconsistent (different base64 >> RFCs) and outdated (SHA), which this draft fixes. It also includes values >> which >> are not in the other >> registry: UNIXsum, UNIXcksum. "All digest-algorithm values are case- >> insensitive." >> (We also reference this registry in draft-bryan-metalinkhttp). >> >> I agree, SHA vs sha-1 in the registries could be confusing but both these >> registries have co-existed for 7 years. I don't know how much either has >> been used in practice, besides our 2 drafts. >> >> On Fri, Dec 4, 2009 at 12:42 PM, Eran Hammer-Lahav >> <[email protected]> wrote: >> > I am supportive of updating *a* registry. >> > >> > The OAuth working group has an open requirement for standard identifiers >> to describe hash/digest functions. >> > >> > What is not clear to me is the relationship of this registry and: >> > >> > http://www.iana.org/assignments/hash-function-text-names/ >> > >> > which seems to overlap. >> > >> > I am not sure why we need both, and if we do (because they are protocol >> specific and required for interoperability), how should a new specification >> decide which to use or if a new registry is required. For example my >> uneducated reading of 4572 suggests it is not exactly the same use case as >> the previous RFCs using that registry. >> > >> > In addition, using different tokens for the same algorithm across protocols >> seems like a bad idea (lower case, upper case, SHA vs sha-1). >> > >> > And since both include MD5... arguments about appropriate hash algorithm >> to increase security fail. >> > >> > EHL >> > >> > >> >> -----Original Message----- >> >> From: [email protected] [mailto:ietf-announce- >> >> [email protected]] On Behalf Of The IESG >> >> Sent: Friday, December 04, 2009 6:44 AM >> >> To: IETF-Announce >> >> Subject: Last Call: draft-bryan-http-digest-algorithm-values-update >> >> (Additional Hash Algorithms for HTTP Instance Digests) to >> >> Informational RFC >> >> >> >> The IESG has received a request from an individual submitter to >> >> consider the following document: >> >> >> >> - 'Additional Hash Algorithms for HTTP Instance Digests ' >> >> <draft-bryan-http-digest-algorithm-values-update-03.txt> as an >> >> Informational RFC >> >> >> >> The IESG plans to make a decision in the next few weeks, and solicits >> >> final comments on this action. Please send substantive comments to >> >> the [email protected] mailing lists by 2010-01-01. Exceptionally, >> >> comments may be sent to [email protected] instead. In either case, please >> >> retain the beginning of the Subject line to allow automated sorting. >> >> >> >> The file can be obtained via >> >> http://www.ietf.org/internet-drafts/draft-bryan-http-digest-algorithm >> >> - >> >> values-update-03.txt >> >> >> >> >> >> IESG discussion can be tracked via >> >> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dT >> >> ag= >> >> 19094&rfc_flag=0 >> >> >> >> _______________________________________________ >> >> IETF-Announce mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/ietf-announce -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
