Re: Extending Android Device Compatibility for Let's Encrypt Certificates

As mentioned in the blog post, and as we'll elaborate on further in an upcoming post, one of the drawbacks of this arrangement is that there actually is a class of clients for which chaining to an expired root doesn't work: versions of OpenSSL prior to 1.1. This is the same failure mode as various

Re: Extending Android Device Compatibility for Let's Encrypt Certificates

In cases where we expect OpenSSL to be validating the chain, we expect that ISRG Root X1 is also in the trust store (unlike older versions of Android, where we know that it hasn't been added). As such, there will be two certificates in the chain which are also in the local trust store: ISRG Root

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

One potential approach would be to make it so that issuances after July 1, 2021 require a validation no more than 398 days old. The currently-proposed wording ("verify that each dNSName or IPAddress is current and correct at intervals of 398 days or less") lends itself to that interpretation, it

Re: Policy 2.7.1: MRSP Issue #211: Align OCSP requirements in Mozilla's policy with the BRs

As an individual, I'd prefer that the Mozilla root program requirements incorporate the entirety of BR§4.9.10 by reference, i.e. I prefer option (2). I prefer (2) over (1) because it makes it easier to "diff" the respective documents. Given that MRSP§6 appears to be strictly looser than

Re: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

I think that an explicit carve-out for time-scoped CRLs is a very good idea. In the case that this change to the MRSP is adopted, I suspect that LE would scope CRLs by notAfter quite tightly, with perhaps one CRL per 24 or even 6 hours of issuance. We would pick a small interval such that we

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

Hi Kathleen, It was my impression from earlier discussions that the plan was for the new CCADB field to contain a URL which points to a document containing only a JSON array of partitioned CRL URLs, rather than the new CCADB

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

On Fri, Feb 26, 2021 at 12:05 PM Ryan Sleevi wrote: > You can still do parallel signing. I was trying to account for that > explicitly with the notion of the “pre-reserved” set of URLs. However, that > also makes an assumption I should have been more explicit about: whether > the expectation is

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

On Fri, Feb 26, 2021 at 5:18 PM Ryan Sleevi wrote: > I do believe it's problematic for the OCSP and CRL versions of the > repository to be out of sync, but also agree this is an area that is useful > to clarify. To that end, I filed > https://github.com/cabforum/servercert/issues/252 to make

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

2021 at 9:53 AM Ryan Sleevi wrote: > > > On Thu, Feb 25, 2021 at 12:33 PM Aaron Gable via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Obviously this plan may have changed due to other off-list conversations, >> but I would like t

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

Similarly, snipping and replying to portions of your message below: On Thu, Feb 25, 2021 at 12:52 PM Ryan Sleevi wrote: > Am I understanding your proposal correctly that "any published JSON > document be valid for a certain period of time" effectively means that each > update of the JSON

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

Thanks for the reminder that CCADB automatically dereferences URLs for archival purposes, and for the info about existing automation! I don't personally have CCADB credentials, so all of my knowledge of it is based on what I've learned from others at LE and from this list. If we leave out the