HN Explorer

9 comments

[ 1.2 ms ] story [ 24.7 ms ] thread
duskwuff
It seems like a stretch to call a feature "mandatory" which was described by a RFC as "deprecated" 17 years ago.

RFCs are not a death pact. Standards can change, especially where security is concerned.

jaimex2
this. The author sounds like a your usual snarky old burnt out IT dinosaur.

"Ughhhh, something changed again! Why does tech always do this?!"

rkeene2
I'm not. I do a lot of interesting work, much of which does not rely upon any standards because it changes so much.

Standards CAN change. This standard DIDN'T change. The Chromium developers referenced this particular RFC (RFC 2818) in reference to a bug as to why this mandatory feature (per the RFC) was disabled, when the document they referenced doesn't agree with their conclusion.

dragonwriter
It's clearly and explicitly mandatory, "MUST" means something quite specific.

Now, perhaps one can argue that there is a good reason to behave this way anyway, but it's clearly violating the spec.

rkeene2
The feature of CAs generating certificates that way is deprecated says RFC 2818 in a non-normative way (since it's outside the scope of RFC 2818).

The feature of supporting it is mandatory says RFC 2818 in a normative way.

It is mandatory if we are to agree on HTTPS being defined by RFC 2818, which the Chromium developers themselves referenced.

nerdponx
"While operators should not create certificates this way because it is deprecated, HTTPS clients MUST support this or they are not compliant with RFC 2818. That is, creating certificates this way is deprecated -- HTTPS clients MUST still support it."