On Mon, Jun 03, 2013 at 04:25:21PM +0100, Ben Laurie wrote:
> > In what context is the normative languate below (
> > https://tools.ietf.org/html/draft-laurie-pki-sunlight-12#section-3
> > ) intended to apply?
> >
> > TLS servers MUST present an SCT from one or more logs to the
> > TLS client together with the certificate. TLS clients MUST
> > reject certificates that do not have a valid SCT for the end-entity
> > certificate.
> >
> > Must private-label internal-only corporate CAs implement this
> > standard?
>
> No.
>
> > Does this apply only to certificates that chain to
> > designated roots?
>
> Yes.
>
> > The above
> > requirement seems rather bold without some constraints on its scope.
>
> We should, perhaps, have said something about private CAs. Possibly
> this was omitted because all interested parties already understood the
> exemption and so failed to notice we hadn't put it in the I-D.
I think this is important to add. Otherwise there seems to be an
inadvertent conflict with DANE TLSA usage 2 and 3. Clients that
implement both standards should be able to verify at least privately
issued usage 3 EE certs, and privately issued usage 2 trust-anchors.
I think it should be clarified that CT hardens PKIX validation in
the context of the existing public CA PKI for trust chained to
designated PKIX roots (and eventually clients are expected to only
support CT conformant public roots, plus any private roots that
CT-exempted by the client).
When a client that supports both PKIX + CT and another PKI (say
DANE TLSA) is not using PKIX (e.g. DANE usage 2/3), it should be
clear that CT does not apply, and the client is still CT conformant
when it does not apply CT rules outside their intended scope.
Is that a fair statement of the implicit consensus? It may be helpful
to make it explicit, so as to avoid confusion.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
