Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
RFC7169 – No Secrecy Afforded X.509 extension silently published (on 2014-04-01) (ietf.org)
54 points by mykhal on April 8, 2014 | hide | past | favorite | 16 comments


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.


Simple, elegant, legally unworkable/wrong.


FYI, this sentence refers to https://en.wikipedia.org/wiki/Warrant_canary which provides a legal way to bypass criminal penalties for disclosing information.


Actually, the legality is unproven. There's still information being passed from the person served with the warrant and the person being spied on.


The legality is unproven but Apple's General Counsel's office has embraced it. It is an increasingly mainstream idea. It should be standardized.


Would you really give advice to hold the court in contempt?


It may be legal, but the "contempt of court" ruling that will inevitably and immediately follow is also legal.


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.


Yes, but RFC 2549 was actually implemented in Norway, successfully sending a ping and receiving responses: https://en.wikipedia.org/wiki/IP_over_Avian_Carriers#Real-li...


HTTP error response code 418 (RFC2324) is my favorite because many servers have actually implemented it. The recent RFC7168 extends it.


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".


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.


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.


What a coincidence, https://tools.ietf.org is vulnerable by the Heartbleed attack (https://news.ycombinator.com/item?id=7548991), which is enough to consider IETF private key compromised. Remember, every joke has a grain of truth.


so they've been at it since 1978. how this "tradition" have not been abandoned many years ago is beyond me.

https://en.wikipedia.org/wiki/April_Fools%27_Day_RFC


Why would they abandon it? It's fun.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: