Thanks Yoav! Comments: > So this is when we get to make fun of the newbie, as promised in > http://www.ietf.org/mail-archive/web/websec/current/msg00521.html ?
Woo hoo! > Cool! So add a reference to RFC 2119 (see for example any draft or RFC). > Otherwise you're not allowed to say "MUST". Done. >Also have a "Security Considerations" section, even if initially it will also >say "to be added", or the classic cop-out, "security I did this by re-naming our security considerations section to "Security Considerations". :) > One more issue, Go code (as opposed to pseudo code, although I would bet your > pseudocode compiles) should go in an appendix - it's just a section within > the "back" tag. Done. > And one comment as to substance. Section 3.1 says "Have a safety net. > Generate a backup key pair, get it signed..." I agree that this is a good > idea for e-commerce site that lose sales on any outage. But what if I > generate a backup key pair for my personal website (www.yoavnir.com is not > it!), and not get it signed at all? Then if my regular private key gets > compromised, I then get it signed by some other CA (or the same CA). With DV > certificates this takes minutes. That part is not MUST, and is in a section called "guidance". So it's not a mandate. Also later on we acknowledge the last-minute signing case. Also, we say at the outset that HSTS certificate pinning is for sites with high operational maturity — if an operator is not prepared to plan for disaster, that's a sign they might not need or want HSTS certificate pinning. At least not now, in this early stage. I don't want for this feature to get a bad reputation when unprepared operators get burned. _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
