ietf-smime
[Top] [All Lists]

Re: [smime] [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt]

2010-06-10 12:33:45
Hi, all,

I agree with Simon. I don't know what it means to move a doc like the MD2 spec
to historic even means. It's not standards track. It's not a protocol. AFAICT,
it's just a description of an algorithm.

It might be useful to create a "security algorithms roadmap" doc, which lists
all known alg RFCs, and describes which are useful in various ways, and which
are no longer typically used, but singling out MD2 (vs. MD5 except as an HMAC)
seems not particularly useful.

Joe

Simon Josefsson wrote:
Peter Gutmann <pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz> writes:

Simon Josefsson <simon(_at_)josefsson(_dot_)org> writes:

1) MD2 is not on the standards track, it is Informational.  I agree with
  wishes to move "poor" documents from the Standards Track to Historic,
  but I'm not sure I see such a big difference between having a "poor"
  document as Informational or Historic.  Especially for a crypto
  algorithm, which the IETF typically does not put on the standards
  track at all.  Is there some precedent for moving Informational to
  Historic?
It helps to have something like this formally retired so you have a document
to point to when someone wants to use (or continue to use) MD2.  Trying to
explain to them the difference between "Informational" and "Standards Track"
when their requirement is "must be specified in an RFC" isn't generally
useful.

Sure, but MD2 is not used in isolation, it is used in a protocol like
TLS, S/MIME, etc.  Isn't it sufficient, even preferable, to move uses of
MD2 in these protocol to Historic?  That would seem to carry much more
weight -- then people cannot continue to support MD2 in these protocol
and claim to be compliant with the latest specifications.

Note that there are other uses of MD2 that are still fine even if MD2 is
not collision resistant.  Compare how rsync still uses MD4 for checksum
computations, and that won't stop it being a reasonable choice.

I'm mostly playing the devil's advocate here, and want to make sure we
consider the consequences before giving a flippant +1.

/Simon
_______________________________________________
saag mailing list
saag(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/saag

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime