On Wed, Oct 30, 2013 at 5:14 PM, Rick Andrews <[email protected]> wrote: > I'd like to explore how "Notification shall be made in an authenticated and > trusted manner". Kathleen's wiki page says to send email to > [email protected] or file a bug. How would Mozilla determine that the > request was legitimate?
If you do it in a bugzilla bug report, then you will be authenticated using your bugzilla credentials. > I suspect that Mozilla already maintains a short list of contacts for each > CA. Only they (or some selected subset of them) should be able to report a > revocation. Mozilla should have some other means of authenticating them. > Maybe you have a cell phone number for each, which you will call to validate > the request. If the reporter attaches the affected certificates, and/or links to the OCSP responses (which you can do if your OCSP responder supports GET), we can verify the revocation by looking at the OCSP responses. This will allow *anybody* to report a revocation to us in a way that we can authenticate. If a CA is reporting a revocation that it hasn't revoked via OCSP then we can only authenticate the request by checking the bugzilla credentials that were used to file the report. > From the CA's perspective, I'd like this process to work the same for Apple, > Microsoft and any other trusted root operator. I urge Mozilla to work with > these other companies to come up with a unified standard. I do not know if we need a new standard for this right away. We should investigate whether bugzilla.mozilla.org can serve as an unofficial clearinghouse for the smaller trusted root operators. bugzilla.mozilla.org has an API that allows programmatic access for filing bugs (which would allow CAs to build automation) and programmatic access for querying for bugs (which would allow the smaller trusted root operators to extract the information automatically from bugzilla). I expect that the number of revocations that need to be reported using this mechanism would be very, very low. If it is not very low then I'd like to investigate ways to make it very low. For example, dropping the CRLDP extension from intermediate certificates might allow CAs to avoid rotating intermediates so frequently since "too big to fail" will not be an issue (at least regarding the size of CRLs). Similarly, shortening the (allowed) validity period of externally-operated intermediate certificates so the validity period never extends beyond the length of the fully-paid-up part of the customer's contract with the CA may greatly reduce the number of intermediate certificates that get revoked. Improving mis-issuance prevention measures should drive the number of mis-issuances to zero, ideally. Improving the TLS protocol to make multi-stapling practical performance-wise, combined with a must-staple X.509 extension that applies to intermediates, should also greatly reduce the need for reporting revocations this way. With all this in mind, it isn't clear that we'd benefit from having a interim standard to hold us over until all revocation information can be stapled into every full handshake in an efficient way. In fact, I could see such an interim standard being harmful if it distracts implementers from working towards making multi-stapling work 100% of the time. Cheers, Brian _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
