top | item 7553004

RFC7169 – No Secrecy Afforded X.509 extension silently published (on 2014-04-01)

54 points| mykhal | 12 years ago |tools.ietf.org | reply

16 comments

order
[+] HCIdivision17|12 years ago|reply
The simplicity of the signal is refreshing: TRUE if the key is shared, FALSE if the key is shared but the signer doesn't want to explicitly say so. Elegant.
[+] ealexhudson|12 years ago|reply
Simple, elegant, legally unworkable/wrong.
[+] ath0|12 years ago|reply
April Fools Day RFC's are a grand tradition. My favorite is "The Extension of MIME Content Types to a New Medium", RFC 1437... complete with extremely dated Dan Quayle joke. IP over Avian Carriers, RFC 2549, is a close second.
[+] mandalar12|12 years ago|reply
I loved the IP Avian Carriers too. My favorite is "Hyper Text Coffee Pot Control Protocol" or RFC 2324, defining the HTTP error 418 "I'm a teapot".
[+] csense|12 years ago|reply
Whenever someone says "...but why don't we just implement a security feature which denies access to clients that try to do X?" where X is something extremely vague like "steal money" that is really hard to translate into an algorithm that could conceivably be implemented, I reply by noting that unfortunately their idea won't work since malware authors have such a low rate of RFC 3514 adoption.
[+] tc_|12 years ago|reply
Believe it or not, there is actual IETF precedence for this:

http://tools.ietf.org/html/rfc6189#section-11

(which they really should have cited in RFC 7169)

When the IETF was deciding whether to standards-track ZRTP or DTLS-SRTP, one of the decision points was Phil's refusal to remove the disclosure flag from ZRTP. The committee wouldn't consider adopting ZRTP unless the disclosure flag was dropped.

Incidentally, this is also a case of creative patent use. Phil received a patent for some core design elements of ZRTP, then freely licensed the patent as long as you correctly implement the disclosure flag.