On Tue, Jun 25, 2019 at 6:51 PM Rashmi Jha <[email protected]> wrote: > > 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.
Criticial name constraints are I think still a nonstarter. > > > > 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. Are we talking about roots are are we talking about intermediates? Because the following fun can happen: 1: Honest Achmed's trusted CA isues Dubious Constrained Intermediate with name constraints for "example.com" 2: Dubious Constrained Intermediate issues cert for example.com Crucially Honest Achmed isn't actually honest and that cert is going to do terrible things. CT catches the issuance, name constraints do not. > > > > 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. What application has this delay be a problem and requires trust by browsers? (Which again this WG doesn't deal with). > 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. ) Wildcards are supported just fine. What's the application where this is a problem? > > > > 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 <[email protected]> > Sent: Thursday, June 20, 2019 3:10 AM > To: Paul Wouters <[email protected]> > Cc: Rashmi Jha <[email protected]>; [email protected] > 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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/trans > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
