On Sep 20, 2011, at 9:08 PM, Chris Palmer wrote: > Is attached, now in XML. The main change is that I got rid of widely > and rightly reviled pin revocation business, and replaced it with a > better idea from Trevor Perrin. Big thanks to everyone who reviewed > and commented on the previous draft. Precisely how to generate > fingerprints is answered with working code from Adam Langley. The > gross errors that surely remain are my fault alone. :)
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 ? Cool! So add a reference to RFC 2119 (see for example any draft or RFC). Otherwise you're not allowed to say "MUST". Also have a "Security Considerations" section, even if initially it will also say "to be added", or the classic cop-out, "security considerations are interspersed throughout this document". 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. 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. Just as some institutions like banks or Google have hot standby server farms that switch over in milliseconds, while the IETF is fine with hour-long outages (as long as they're rare), websites can make a trade=off of expense vs availability of the website certificate. I don't think the draft should mandate the hot-standby datacenter approach. Yoav _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
