Hi Peter, all, It looks ok.. although I would have preferred to maintain some kind of reference to partitioned and delta CRL with reference to X.509 (PKIX) - since we are talking about TLS, x.509 is the standard of reference for client and server certificates.
Just my 2 cents... Cheers, Max > On Dec 1, 2014, at 9:01 PM, Peter Saint-Andre - &yet <[email protected]> wrote: > >> On 11/13/14, 7:59 PM, Dr. Massimiliano Pala wrote: >> Hi all, >> >> If it is not too late... regarding Session 7.5 - first bullet point: the >> text seems a bit too restrictive. Probably in the context of current Web >> Browser CRLs are not used today, but other environments still make a >> wide use of CRLs. I also would like to add a privacy consideration about >> the use of CRLs vs. other mechanisms. >> >> For this I would the text from: >> >> Certificate Revocation Lists (CRLs) are not scalable and therefore >> rarely used. >> >> >> to something like the following: >> >> 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. >> >> The last consideration stems from the fact that by using CRLs, a service >> does not need to communicate to the certificate issuing authority (e.g., >> the CA or the entity running an OCSP server) and disclose the >> certificate for which the revocation status is requested. > > How about this? > > o Although Certificate Revocation Lists (CRLs) are the most widely > supported mechanism for distributing revocation information, they > have known scaling challenges that limit their usefulness. > However, CRLs might provide better privacy-preserving properties > than other techniques (e.g., OCSP), since there is no need to > communicate with a third party regarding the certificate that a > client is checking. > > Peter > > -- > Peter Saint-Andre > https://andyet.com/ _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
