On Wed, Sep 25, 2019, 06:30 Neil Dunbar via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > > > On 24 Sep 2019, at 07:35, Clint Wilson via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > > […] it seems like one useful change for us > > here may be to issue those final certs without the SCTs rather than > > abandoning the pre-cert as we do today. We'd obviously still need to > > re-attempt issuance of another cert with the SCT list (as that's what a > > vast majority of customers expect), but reducing the number of orphaned > > pre-certs seems like a reasonably good thing, even if inconsequential for > > how we interact with the (pre-cert || cert). > > Perhaps I’m misunderstanding, but wouldn’t the generation of a set of > certificates (at least two in that set - one with SCTs embedded, and one > without) end up with several certificates signed by the same Issuing CA, > but with identical serial numbers? This would violate RFC 5280 Section > 4.1.2.2. For publicly trusted CAs, a (pre-cert, cert) pair does not violate > that condition by virtue of BR Section 7.1.2.5. Combining the two > documents, it would seem that the number of certificates following a > pre-certificate issuance is strictly limited to one. > > Again - I may have misunderstood: apologies if this is the case - > corrections welcome. > > Regards, > > Neil Sorry, I think the misunderstanding is my fault. You're correct if the same pre-cert was used for two subsequent leaf signings. What I meant was where now we would abandon retrying signing of the leaf due to failure in retrieval of the SCTs, we would instead sign the leaf without SCTs, then start the entire process over again once CT logs were available (new tbsCert, new pre-cert, new leaf). So same subject/sAN contents, but not the same serial number. Cheers! Clint _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy