Re: [Trans] draft-ietf-trans-rfc6962-bis-31

Paul made the point quite accurately - CT is orthogonal to
name-constraining a CA, and can be used to validate the CA has adhered to
the constrained names.

Additionally, there's no way to signal to a user agent that  such a CA
would be "exempt" from CT (some user agents have Enterprise controls to
allow instances managed by the organization to not require CT for certain
domains, though).

On Thu, Jun 20, 2019 at 12:44 AM Paul Wouters <paul@nohats.ca> wrote:

> On Wed, 19 Jun 2019, Rashmi Jha wrote:
>
> > Have you looked into the options of not requiring CT for CAs which are
> constrained to a brief list of domains ? I understand this was considered
> in the past but couldn’t find details why this was not
> > accepted.
>
> Whether or not to require CT is not part of the document. This seems
> more like a question to browser vendors. The draft only states:
>
>
>     In addition, if TLS clients will not accept unlogged certificates,
>     then site owners will have a greater incentive to submit certificates
>     to logs, possibly with the assistance of their CA, increasing the
>     overall transparency of the system.
>
> The "if" there is important. It is not a decision made in this document
> or this Working Group.
>
> The draft only lists the requirements and formats for when CT is used.
>
> > Named constraint by default provide the assurance as to what domains
> they will issue. CT becomes an additional network call in in issuance of
> certificate which can be prevented.
>
> Not "assurance", but "expectation". CT is there to confirm this
> expectation. Surely, you want CT logs to show captured certificates that
> were signed by a CA outside of that CA's own Named constraint policy?
>
> Additionally, if you skip accepting certificates within a named
> constraint, what do you do when some CA claims ".com" as their
> named constraint?
>
> Paul
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>