Hi Rich, Peter, all, Thanks for the comments. My suggestions were more related to X.509 CRLs, which are the ones we standardized in PKIX.
Personally, I do not think that CRLSet is something that we should really be concerned with at IETF. In particular, I think that CRLSet is a bad and fast fix to a real problem that (a) is available from one single vendor, (b) completely ignores the golden rule about PKIs by substituting the real source of trust (the CA) with an application-level (chrome) decision (not even user-driven!), and (c) is an ad-hoc not-standardized solution. For client side certificates, I think that checking the revocation status in that environment carries even more privacy concerns. This might be true especially when the certificate to be checked is issued by a CA that is not connected to the services offered by the server. For example, if you are checking the revocation from a 3rd party CA (e.g. for granting access to a building), checking the revocation status of that certificate might reveal the user's position or even its activity (e.g. logging into her e-mail or accessing a building) to the CA's revocation servers - they have no business knowing that information and that info might even be disclosed to passive attackers that monitor the traffic. Another example, can be when using client-side certificates for WiFi roaming. Therefore I think that also for client-side certificates the privacy issue is quite relevant. Just my two cents... Cheers, Max On Dec 1, 2014, at 10:24 PM, Salz, Rich <[email protected]> wrote: >>> Certificate Revocation Lists (CRLs) provide the most supported >>> revocationinformation distribution mechanism. Although updates to >>> the CRLformat (e.g., partitioned CRLs, delta CRLs) have been defined >>> toaddress scalability issues, they are rarely used in favor of more >>> compact formats. However, it is important to notice that the use of >>> CRLs might provide better privacy-preserving properties than other >>> protocols (e.g., OCSP), especially when considering the validation of >>> client-side certificate. > > Are you using CRL as a generic term -- to include tihngs like CRLset, for > example? If so, then this makes sense. But if so, then I think the wording > needs to be tweaked, since portioning and delta CRL's are only for the > classic X.509 CRL structures.But then if it does include generic, then Chrome > support for CRLSet is a pretty widely deployed use on the Web. The private > point raised is important. Not sure if it's important for client certificates > (since you've already decided to give the server your cert); I do think it is > VERY important for server-side certificates, where not letting national-scale > adversaries know where you might be connecting is (well, er) key. > > -- > Principal Security Engineer, Akamai Technologies > IM: [email protected] Twitter: RichSalz > _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
