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

Name constraints itself if orthogonal to CT but both of these achieve the same goal.  Restrict a CA to issue certs for the domains they are suppose to. The difference is following :

  *   In CT, you log the cert into CT logs at the time of issuance of each cert
  *   Name constrained is upfront where CA declares that I am going to issue certs only for ford.com, jaguar.com (hypothetically) and that’s it.

Named constraints CA shouldn’t need to log each time when a cert is issued.  Because the verification and monitor of whether the CA has complied with the goal is done offline or a different time in both the scenarios.

The draft doesn’t address what should be an alternative for folks who don’t want CT

  *   CT adds burden for each certificate issuance. It adds ~7seconds to every cert issuance and it adds a new failure endpoint in the path.
  *   CT has 0 alternatives. There is no mechanism for redaction.
(The only alternative to have subdomain level redaction is to use wildcard which is just from the list of ‘what not to do’s’ in PKI. )

CT drives an important industry-wide goal. There are other ways to achieve the same goal. And for organizations where each millisecond matters, the user agent should support an alternative rather than add load and failure point at their critical path of issuance.  Named constraints is within the books of PKI.  A CA can be held accountable like any other CA/Browser baseline requirements that if they issue certs outside of their constraints then they should take immediate action or get distrusted. It won’t be any different from a CA doing a wrong thing and got caught via CT monitors.

This draft should prescribe an alternative to achieve the same goal which is achieved by CT and the details on that alternative can be covered somewhere else.

Thanks, Rashmi Jha.

From: Eran Messeri <eranm=40google.com@dmarc.ietf.org>
Sent: Thursday, June 20, 2019 3:10 AM
To: Paul Wouters <paul@nohats.ca>
Cc: Rashmi Jha <rashmij@microsoft.com>om>; trans@ietf.org
Subject: 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<mailto: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<mailto:Trans@ietf.org>
https://www.ietf.org/mailman/listinfo/trans<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftrans&data=02%7C01%7Crashmij%40microsoft.com%7Cae474da982b54ba3357208d6f5677794%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636966222079605740&sdata=cYfP2gFkeY8Pdm%2BEaHNv%2BXfoAV00%2BSUlMvaiAw8ee1o%3D&reserved=0>