[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: what I am proposing re HMAC
Just to be clear, what I am proposing on HMAC is this:
1) We leave 1828 alone. We do not advance it further but we do not
"replace" it, meaning new RFCs do NOT "supersede" it in the way a
replacement would.
2) We publish an RFC as a proposed standard for HMAC.
3) We think of the HMAC transform not as a replacement for the
existing transforms but as a new transform. Any key negotiation
protocols that exist do not replace the meaning of "use the 1828
transform" with using HMAC -- they think of HMAC as a new
transform. I do not want the new RFC to "supersede" 1828 as a
replacement RFC would. One of the reasons I'm strongly opinioned on
this is that I expect this situation will occur over and over in
the next decade -- we will discover something and want to replace
what people are using. Right now we can fail to advance 1828 as
part of this process, but in general what we are doing is creating
NEW transforms, not REPLACING old ones. The new transforms are then
encouraged to be "must implement".
4) We leave the HMAC RFC at proposed standard long enough for the cryp
to
community to really get its teeth in. Being at proposed should be
sufficient to encourage vendors to implement. I know Hugo would
probably like it to advance to draft standard more quickly, but my
gut instinct says "wait". Proofs are good, I fully believe Hugo is
a good crypto guy and that his proofs are excellent, but this is
engineering at this point, not math. Proposed standard should be
sufficient for a while.
5) If we desire, we may issue a document clarifying 1828 for
historical reasons, but we do this as an informational RFC.
There's no problem with any of this. But we need point 6 -- the status
of 1828 and HMAC as mandatory/recommended/elective etc. What do we
tell people they MUST implement? My own view is to make HMAC mandatory
and 1828 recommended -- and recommended only because there's already
a lot out there.