On 02/10/2012 11:40 AM, Erwann Abalea wrote: > Le vendredi 10 février 2012 01:32:47 UTC+1, Ondrej Mikle a écrit : > [...] >> A quote from Lucky Green >> (http://lists.randombit.net/pipermail/cryptography/2011-December/001918.html): >> >>> Most (but not all) of the CAs that I worked with over the years did not >>> have anybody on the operations side full time that would know how to >>> place a revocation reason into the CRL. > > What kind of CA are these?
Last time I tried to ask about specific CAs, I got an answer: "You must joking, right?" (NDAs are prolific in this line of business.) That's why I favor public disclosure of sub-CA certs that is currently being discusses at mozilla.dev.security.policy. >>> Which is why the majority of CRL >>> entries include an unspecified reason code or the ever popular reason >>> code "NULL". > > Before Google announce, what was the revocation reason used for? Nothing. At the very least it was used by researchers (EFF, crlwatch just to name a few). > So even if the revocation reason is taken into account during the revocation > action, and stored in the CA database, outputing this reason in a CRL parsed > by a machine that doesn't care about why a certificate has been revoked is > useless. UI of TLS clients could be different for specific revocation reasons. It's really a corner case (just for the sole purpose of an example). RFC 5280 says: CRL issuers are strongly encouraged to include meaningful reason codes in CRL entries; however, the reason code CRL entry extension SHOULD be absent instead of using the unspecified (0) reasonCode value. Why not use it? Following the logic "no code I know of parses it anyway" we could drop many kinds of fields from other protocols. > Now, after some thought (thanks, Jean-Marc), if Google could come up with an > efficient mechanism so that revocation is really checked, that's cool. The > "less than 100k" is a challenge, I'd like to see how it will be solved, given > the large CA base and unequal technical expertise of them. I'm glad that Google came up with the proposal. Despite being incomplete/controversial, this time the discussion actually may end up in something being changed for the better (instead of the usual "oh well" ending). Ondrej -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
