Subject: Re: [pkix] [Trans] Certificate Transparency and user agent warnings

From: Eran Messeri <[email-masked]>
Date: Wed, 22 Apr 2015 15:02:19 +0100

On Wed, Apr 22, 2015 at 10:20 AM, Jeffrey Walton <[email-masked]> wrote:

> 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.
>
File a bug with Chrome? Chrome treats local trust roots differently AFAIK
and the Chromium issue tracker is the place  to get authoritative  answers
about this behaviour.

>
> Jeff
>
> On Wed, Apr 22, 2015 at 5:03 AM, Rob Stradling <[email-masked]>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/trans
>