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

From: Rashmi Jha <[email-masked]>
Date: Wed, 19 Jun 2019 22:15:33 +0000

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.

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.

Opinions ? Could you assist to forward it to the right email aliases if this isn't one?

Thanks, Rashmi Jha.
Azure Security Program Manager
Microsoft Corporation
[email-masked]<mailto:[email-masked]>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 19 Jun 2019 19:43:42 -0400 (EDT)

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

---

From: Eran Messeri <[email-masked]>
Date: Thu, 20 Jun 2019 11:09:33 +0100

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-masked]> 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.
>
> > 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.
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Rashmi Jha <[email-masked]>
Date: Wed, 26 Jun 2019 01:50:42 +0000

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=[email-masked]>
Sent: Thursday, June 20, 2019 3:10 AM
To: Paul Wouters <[email-masked]>
Cc: Rashmi Jha <[email-masked]>; [email-masked]
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-masked]<mailto:[email-masked]>> wrote:

Paul

_______________________________________________
Trans mailing list
[email-masked]<mailto:[email-masked]>
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>

---

From: Watson Ladd <[email-masked]>
Date: Tue, 25 Jun 2019 18:55:55 -0700

On Tue, Jun 25, 2019 at 6:51 PM Rashmi Jha
<rashmij=[email-masked]> wrote:
> 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…

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.

> 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.
>

Wildcards are supported just fine. What's the application where this
is a problem?

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Rashmi Jha <[email-masked]>
Date: Wed, 26 Jun 2019 02:27:57 +0000

Thanks Watson.  Appreciate the response. 

1. We can surely argue critical or non-critical.  Named constraints can be critical or non-critical
2. Constraints are defined on Issuing CA as per RFC 5280.  See below RFC extract.
3. One of the CT issue is that the persona used to build the solution is thinking of only an application developer, site operator. The cloud scenario is a miss - The scenario is that I want to deploy my application in ~100 regions worldwide. I want to deploy my application at the same time across the world.
4. Wildcard - just  search or google it and there are numerous articles conveying the issue with wildcards. 

A question from my side : What is the role of this WG ? 

4.2.1.10.  Name Constraints

   The name constraints extension, which MUST be used only in a CA
   certificate, indicates a name space within which all subject names in
   subsequent certificates in a certification path MUST be located.
   Restrictions apply to the subject distinguished name and apply to
   subject alternative names.  Restrictions apply only when the
   specified name form is present.  If no name of the type is in the
   certificate, the certificate is acceptable.

-----Original Message-----
From: Watson Ladd <[email-masked]> 
Sent: Tuesday, June 25, 2019 6:56 PM
To: Rashmi Jha <[email-masked]>
Cc: Eran Messeri <[email-masked]>; Paul Wouters <[email-masked]>; [email-masked]
Subject: Re: [Trans] draft-ietf-trans-rfc6962-bis-31

On Tue, Jun 25, 2019 at 6:51 PM Rashmi Jha <rashmij=[email-masked]> wrote:
> 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.

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.

> 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).

> (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?
> > 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.
>
> The "if" there is important. It is not a decision made in this 
> document or this Working Group.
>
> 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?
>
> constraint, what do you do when some CA claims ".com" as their named 
> constraint?
>
> Paul
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Ftrans&amp;data=02%7C01%7Crashmij%40mic
> rosoft.com%7C48af4c32534d4f589b8008d6f9d9796a%7C72f988bf86f141af91ab2d
> 7cd011db47%7C1%7C0%7C636971109771716859&amp;sdata=97MDIyztKi8%2FGCc6IZ
> urR1%2Bjgt7LF0BnQ7pHnIZNs%2Fw%3D&amp;reserved=0
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Ftrans&amp;data=02%7C01%7Crashmij%40mic
> rosoft.com%7C48af4c32534d4f589b8008d6f9d9796a%7C72f988bf86f141af91ab2d
> 7cd011db47%7C1%7C0%7C636971109771716859&amp;sdata=97MDIyztKi8%2FGCc6IZ
> urR1%2Bjgt7LF0BnQ7pHnIZNs%2Fw%3D&amp;reserved=0

---

From: Paul Wouters <[email-masked]>
Date: Wed, 26 Jun 2019 00:31:14 -0400 (EDT)

> 1. We can surely argue critical or non-critical.  Named constraints can be critical or non-critical

What is a non-critical named constraint? If the client does not
understand the named constraint, and it is non-critical, wouldn't it
mean the client may continue and ignore the thing, not knowing it is a
name constraint? That seems odd to me, as it would defeat the purpose
of it.

> 3. One of the CT issue is that the persona used to build the solution is thinking of only an application developer, site operator. The cloud scenario is a miss - The scenario is that I want to depl…

How is CT preventing this for you?

> A question from my side : What is the role of this WG ?

https://datatracker.ietf.org/wg/trans/about/

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 26 Jun 2019 00:42:25 -0400 (EDT)

[speaking as an individual only]

>  *  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.  

Sure, but having a CA per TLD or even per group of SLD's would explode
the number of CAs required. And if these all need to comply to the
CAB/Forum rules, that's a lot of auditing.

> 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…

How would you detect a mis-issuance within the named constraint without CT?

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

It could mention DNSSEC and DANE (TLSA), but I don't think it is
neccessary in this document.

>  *  CT adds burden for each certificate issuance. It adds ~7seconds to every cert issuance and it adds a new failure endpoint in the path.

I don't think it adds latency if you regularly fetch the latest tree head?

>  *  CT has 0 alternatives.

DNSSEC with DANE/TLSA is an alternative.

> There is no mechanism for redaction.

[chair hat on ]

Redaction has been brought up a number of times, but has not seen enough
work done for it to be added in this document. Later on, it was suggested
redaction should be done as a separate document.

[/chair hat]

> 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.

The draft only talks about the protocol. Whether or not to allow or
require it, in the presence or absence of CT, is up the the browser
vendors. So my question to you would be, if name constraints are to
be considered for this draft, would it require a document change?

> 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.

I'm confused that you say there are no alternatives and that
alternatives should be mentioned in the document?

Paul