Hi Rob, Thanks.
> If 2, then I suspect that this is out of scope for CT, since it seems likely > that most CT logs accepted by browsers will only issue SCTs for > (intermediate or end-entity) certs that chain to publicly-trusted roots. Yes, this is the case. Is there a call-out or spec somewhere that states SCT is required of public CAs; but not CAs for internal or private PKIs? I'm concerned with an in-house, private PKI and the warnings that have been showing up in Chrome. Jeff On Wed, Apr 22, 2015 at 5:03 AM, Rob Stradling <[email protected]> wrote: > (Cross-posting to TRANS) > > Jeffrey, does "private PKI" mean... > > 1. A publicly-trusted root, a publicly-logged intermediate, and non-logged > end-entity certs. > or > 2. A non-publicly-trusted root, a non-logged intermediate, and non-logged > end-entity certs. > > If 1, then please take a look at the mechanism in 6962-bis [1] for logging a > name-constrained intermediate CA certificate in place of the end-entity > certs issued under it. > > If 2, then I suspect that this is out of scope for CT, since it seems likely > that most CT logs accepted by browsers will only issue SCTs for > (intermediate or end-entity) certs that chain to publicly-trusted roots. > > > [1] > https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/?include_text=1 > > > On 22/04/15 00:59, Jeffrey Walton wrote: >> >> According to the CT FAQ at >> http://www.certificate-transparency.org/faq, there are three ways to >> avoid warnings in some user agents: >> >> * X509v3 Certificate Extension >> * TLS Extension >> * OCSP Stapling >> >> If a private PKI includes a subordinate in the chain that is name >> constrained, then can that be used in lieu of the three methods above? >> >> RFC 6962 does not discuss it (https://tools.ietf.org/html/rfc6962). >> But I feel like if the problem is issuing server certificates for >> domains *not* authorized to do so, then name constraints seems like a >> natural solution. >> >> Thanks in advance. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
