Subject: [pkix] Way Forward: Name Constraints Criticality

From: Santosh Chokhani <[email-masked]>
Date: Sun, 27 May 2012 11:09:50 -0400

I agree with Mike.

In light of the fact we seem to have established positions which we do not wish to change, I thought we should see if there are options we could agree on.

To that end and since the thread has several sub-threads, I have begun a new thread.

Here are the options that come to my mind.  There may be others.

Option 1: Do not change the standard

Option 2: Do not change the standard but add language akin to the following in an appropriate place in the standard " It is recognized that a CA may wish to make the name constraints extension non-critical in order to maximize interoperability.  Such CA shall either use other mechanisms that are not specified in this standard or shall make such a decision based on trading off increased interoperability and security exposure"

Option 3: Change the standard to make the extension "recommended to be critical for a period of time"  This period of time should be short and should be only made if Opera and Safari decision makers are willing to provide the support for the extension ASAP in their browsers and maximize updates to the current version.  We can add the applicable language and revision from Option 2.  I would set this date to be expiry date of CA certificate since revocation checking in browsers is uneven.

Option 4: Change the standard to make the extension "recommended to be critical".  I would be against it.

May be we could use this or similar method to get a vote on the WG since in my opinion no one is saying anything new.

-----Original Message-----
From: Michael StJohns [mailto:[email-masked]] 
Sent: Saturday, May 26, 2012 9:15 PM
To: [email-masked]; Santosh Chokhani
Cc: IETF PKIX
Subject: Re: [pkix] NameConstraints criticality flag

At 05:57 PM 5/26/2012, Ryan Sleevi wrote:
>Any CA who makes NC critical will necessarily prevent these users from 
>accessing any servers whose certificates chain to them. Considering 
>that so much of market position within the CA ecosystem is being able 
>to interoperate with legacy systems, this is a unbearable market 
>penalty for any CA. Considering the first mover penalties are so high, 
>no CA wishing to stay in business would adopt NC.

I keep trying to understand this type of a statement, but it gives me a bad case of cognitive dissonance.  I'm actually thinking that a critical NC and not being able to access those servers is a good thing and the whole idea of NC in the first place.

Here's how I imagine an NC would be used.

I'm a company that wants to issue certificates to my servers that chain back to a well known root.  I *don't* want to have to do a server by server request to get certificates so I contract with the well known root (WKR) to get a CA certificate owned by my company signed.  

The WKR has two types of CA signing it will do - the first contains an NC that constrains me to issue certificates with names that are subordinate to "mikestjohnscompany.com" and costs X, the second that does not contain an NC and costs 10 X (mainly because the WKR doesn't want it competing with them for issuing TLS server certificates for random companies).

If  the WKR is only getting X, then the WKR is going to want to make sure that the certificates issued by the subordinate CA are enforceably within mikestjohnscompany.com which means setting the critical bit.   If your (Ryan, Phil, etc) assumption is that very few RPs understand NC, then setting the bit to non-critical means that the NC is basically useless, and almost any name issued by that subordinate CA is going to be accepted by the vast majority of RPs including those not under mikestjohnscompany.com.  

Amusingly, if there are enough of  non-critical NC/Non-Compliant name server certificates (because some subordinate CA was gaming the system, or was just stupid about how they set up their CA) deployed, deployments of browsers that implement NC support may never happen because those now NC supporting browsers will not be able to reach the servers with non-compliant certificates.  Talk about anti-incentive.

You're trying to deal with a legacy issue the wrong way (or so I believe).   But, as someone else noted, it really is  - in the final analysis - up to the issuing CA whether to set the critical bit or not.  So as CA vendors you should feel free to set the bit as you please - it just won't be compliant with the 5280 profile if its set non-critical.  Personally, I'd rather you just not include the NC in the certificate.

Later, Mike

---

From: Sean Leonard <[email-masked]>
Date: Sun, 27 May 2012 08:27:36 -0700

Santosh provides a reasonable 4-option framework for a vote.

---

From: Michael StJohns <[email-masked]>
Date: Sun, 27 May 2012 15:06:16 -0400

Hi Santosh -

I think you've got the correct 4 cases, but 5280 and its ilk are implementation standards/recommendations, and not so much operational guidance and your options 2 and 3 are really operational guidance twiddles.

I'm actually thinking the right answer is for Phil et al to publish an Informational RFC that says they are doing X for Y reasons, note that this conflicts with 5280, note why they are doing it, note that other CAs may or may not want to do the same, and leave RFC5280 alone.

That keeps 5280 in-line with the goals of best technical guidance* and still gives a place to record operational ... necessities?

Mike

Note: *  As far as I can tell, the push by Phil et al for the change is not so much best technical guidance, but a semi-pragmatic and all capitalistic attempt to do something useful with NC without screwing up the CA business model - not wrong in and of itself, just not quite what is supposed to work in the IETF.  The IETF has mostly been about trying to find the best technical approach which is why we've been so adamant over the years about people participating as individuals and not as representatives of their employers.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 28 May 2012 15:38:40 +0300

Hi Santosh

I don't really see the difference between options 2 and 4. In option #2 we're keeping the MUST, but adding language that says that CAs can decide to make it non-critical if certain conditions apply and/or they decide to trade off interoperability for security. IMO this is the very definition of SHOULD

Yoav

On May 27, 2012, at 6:09 PM, Santosh Chokhani wrote:

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
> 
> Scanned by Check Point Total Security Gateway.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 30 May 2012 10:20:34 -0400

I dont see that either.

Commercial CAs now face a mandate from Mozilla that requires them to use Name Constraints.

I have a draft of a draft that sets out the required client behavior when encountering a certificate that is not 5280 compliant with respect to criticality setting and the consequences of not setting criticality.

Sent from my iPad

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 30 May 2012 15:35:23 -0400

PHB,

If you are going to recommend rules beyond 5280 (e.g., if something is marked NC and 5280 says it should be critical), that is a non-starter.  We do not need to add such rules and they do not serve any useful purpose.

-----Original Message-----
From: Phillip Hallam-Baker [mailto:[email-masked]] 
Sent: Wednesday, May 30, 2012 10:21 AM
To: Yoav Nir
Cc: Santosh Chokhani; IETF PKIX
Subject: Re: [pkix] Way Forward: Name Constraints Criticality

I dont see that either.

Sent from my iPad

On May 28, 2012, at 8:38, Yoav Nir <[email-masked]> wrote:

> Hi Santosh
> 
> I don't really see the difference between options 2 and 4. In option 
> #2 we're keeping the MUST, but adding language that says that CAs can 
> decide to make it non-critical if certain conditions apply and/or they 
> decide to trade off interoperability for security. IMO this is the 
> very definition of SHOULD
> 
> Yoav
> 
>>> Any CA who makes NC critical will necessarily prevent these users 
>>> from accessing any servers whose certificates chain to them. 
>>> Considering that so much of market position within the CA ecosystem 
>>> is being able to interoperate with legacy systems, this is a 
>>> unbearable market penalty for any CA. Considering the first mover 
>>> penalties are so high, no CA wishing to stay in business would adopt NC.
>>

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 30 May 2012 23:01:54 +0200

Phillip Hallam-Baker a écrit :
> I have a draft of a draft that sets out the required client behavior
> when encountering a certificate that is not 5280 compliant with
> respect to criticality setting and the consequences of not setting
> criticality.

This shouldn't be needed.

Maybe option 5 would be :
- Modify RFC5280 to say that whilst compliant implementation MAY add 
additional restrictions to the Certification Path Validation algorithm, 
those restrictions SHOULD NOT cause to reject as invalid a certificate 
that contains a non critical extension that RFC5280 defines as critical.

Actually I think it would be best to say also that implementation SHOULD 
display a warning about it in interactive settings.

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 30 May 2012 17:17:40 -0400

> that contains a non critical extension that RFC5280 defines as critical.

RFC 5280 already (effectively) says that:

    While the certificate and CRL profiles specified in Sections 4 and 5
    of this document specify values for certificate and CRL fields and
    extensions that are considered to be appropriate for the Internet
    PKI, the algorithm presented in this section is not limited to
    accepting certificates and CRLs that conform to these profiles.
    Therefore, the algorithm only includes checks to verify that the
    certification path is valid according to X.509 and does not include
    checks to verify that the certificates and CRLs conform to this
    profile.  While the algorithm could be extended to include checks for
    conformance to the profiles in Sections 4 and 5, this profile
    RECOMMENDS against including such checks.

This applies to the criticality of the nameConstraints extension since 
RFC 5280 states that conforming CAs must mark the nameConstraints 
extension as critical, but does not "define" the extension as critical.  
The extension is defined in X.509, and X.509 says that the extension may 
be marked as either critical or non-critical.  So, this is different 
from an extension such as the issuingDistributionPoint CRL extension, 
which X.509 says is always critical (i.e., is defined as critical).  
Even in this case, however, the path validation algorithm does not 
include a step to verify that the CRL issuer marked the extension as 
critical.

Dave

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 30 May 2012 17:41:06 -0400

What I propose to do is to write a document that explains the steps that
are necessary to write software that works with and the security
consequences of accepting the certificates that CAs will be required to
distribute in the next few weeks baring the (unlikely) event that Mozilla
changes its mind.

I think that the practical utility of that document is rather obvious.

On Wed, May 30, 2012 at 3:35 PM, Santosh Chokhani <[email-masked]>wrote:

> PHB,
>
> If you are going to recommend rules beyond 5280 (e.g., if something is
> marked NC and 5280 says it should be critical), that is a non-starter.  We
> do not need to add such rules and they do not serve any useful purpose.
>
> I have a draft of a draft that sets out the required client behavior when
> encountering a certificate that is not 5280 compliant with respect to
> criticality setting and the consequences of not setting criticality.
>
>
>
>
> Sent from my iPad
>
> >> In light of the fact we seem to have established positions which we do
> not wish to change, I thought we should see if there are options we could
> agree on.
> >>
> >> Option 2: Do not change the standard but add language akin to the
> following in an appropriate place in the standard " It is recognized that a
> CA may wish to make the name constraints extension non-critical in order to
> maximize interoperability.  Such CA shall either use other mechanisms that
> are not specified in this standard or shall make such a decision based on
> trading off increased interoperability and security exposure"
> >>
> >> Option 3: Change the standard to make the extension "recommended to be
> critical for a period of time"  This period of time should be short and
> should be only made if Opera and Safari decision makers are willing to
> provide the support for the extension ASAP in their browsers and maximize
> updates to the current version.  We can add the applicable language and
> revision from Option 2.  I would set this date to be expiry date of CA
> certificate since revocation checking in browsers is uneven.
> >>
> >> May be we could use this or similar method to get a vote on the WG
> since in my opinion no one is saying anything new.
> >>
> >> I keep trying to understand this type of a statement, but it gives me a
> bad case of cognitive dissonance.  I'm actually thinking that a critical NC
> and not being able to access those servers is a good thing and the whole
> idea of NC in the first place.
> >>
> >> I'm a company that wants to issue certificates to my servers that chain
> back to a well known root.  I *don't* want to have to do a server by server
> request to get certificates so I contract with the well known root (WKR) to
> get a CA certificate owned by my company signed.
> >>
> >> The WKR has two types of CA signing it will do - the first contains an
> NC that constrains me to issue certificates with names that are subordinate
> to "mikestjohnscompany.com" and costs X, the second that does not contain
> an NC and costs 10 X (mainly because the WKR doesn't want it competing with
> them for issuing TLS server certificates for random companies).
> >>
> >> If  the WKR is only getting X, then the WKR is going to want to make
> sure that the certificates issued by the subordinate CA are enforceably
> within mikestjohnscompany.com which means setting the critical bit.   If
> your (Ryan, Phil, etc) assumption is that very few RPs understand NC, then
> setting the bit to non-critical means that the NC is basically useless, and
> almost any name issued by that subordinate CA is going to be accepted by
> the vast majority of RPs including those not under mikestjohnscompany.com.
> >>
> >> Amusingly, if there are enough of  non-critical NC/Non-Compliant name
> server certificates (because some subordinate CA was gaming the system, or
> was just stupid about how they set up their CA) deployed, deployments of
> browsers that implement NC support may never happen because those now NC
> supporting browsers will not be able to reach the servers with
> non-compliant certificates.  Talk about anti-incentive.
> >>
> >> You're trying to deal with a legacy issue the wrong way (or so I
> believe).   But, as someone else noted, it really is  - in the final
> analysis - up to the issuing CA whether to set the critical bit or not.  So
> as CA vendors you should feel free to set the bit as you please - it just
> won't be compliant with the 5280 profile if its set non-critical.
>  Personally, I'd rather you just not include the NC in the certificate.
> >>
> >> Later, Mike
> >>
> >>
> >>
> >>
> >>
> >>

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 30 May 2012 17:47:48 -0400

On Wed, May 30, 2012 at 5:17 PM, David A. Cooper <[email-masked]>wrote:

> This applies to the criticality of the nameConstraints extension since RFC
> 5280 states that conforming CAs must mark the nameConstraints extension as
> critical, but does not "define" the extension as critical.  The extension
> is defined in X.509, and X.509 says that the extension may be marked as
> either critical or non-critical.  So, this is different from an extension
> such as the issuingDistributionPoint CRL extension, which X.509 says is
> always critical (i.e., is defined as critical).  Even in this case,
> however, the path validation algorithm does not include a step to verify
> that the CRL issuer marked the extension as critical.
>

Given that attempting to enforce this particular check will now cause
damage, I think it is a good thing to have a document that notes that this
is the case.

Enforcing RFC 5280 compliance on certs would seem to be an idiotic thing to
attempt in any case since there is no guarantee that RFC 5280 will be the
perpetual internet standard in any case.

In particular, I can't see how any revision to RFC 5280 is going to manage
to get to DRAFT or FULL standard when the industry has taken a conscious
decision to reject the WG advice on this point.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 30 May 2012 23:53:11 +0100

Phill,

On 05/30/2012 10:47 PM, Phillip Hallam-Baker wrote:

> damage, 

I guess we disagree about that.

> I think it is a good thing to have a document that notes that this
> is the case.

Sure. Sounds like a fine thing for the ISE.

> perpetual internet standard in any case.

I don't see how you can believe that, know about IETF processes,
and see any utility in any standards.

> decision to reject the WG advice on this point.

There are no longer draft or full standards, just proposed and
Internet standards. (two-levels).

S

---

From: Wan-Teh Chang <[email-masked]>
Date: Wed, 30 May 2012 16:31:13 -0700

RFC 2459 (a predecessor of RFC 5280) is 129 pages long.

Isn't it possible that the reviewers of such a long document may have
overlooked the full implications of "[The name constraints] extension
MUST be critical"?

Is the US DoD using the name constraints extension?

Thanks,
Wan-Teh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 31 May 2012 08:48:08 -0400

The point of standards is to achieve interoperability.

You are defending a standard that requires the industry to issue
certificates that are going to break interoperability.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 31 May 2012 13:58:42 +0100

> The point of standards is to achieve interoperability.

Sure.

> certificates that are going to break interoperability.

Nope. I'm not "defending" anything, nor am I going on
any offensive.

I was correcting some wrong statements you made and
suggesting a way forward.

S

---

From: Yoav Nir <[email-masked]>
Date: Thu, 31 May 2012 16:10:35 +0300

> suggesting a way forward.

I don't see how PHB is wrong here. It would be wrong for an RP to check that a certificate complies with RFC 5280. Suppose the discussion of a few months ago ended differently, and the WG was convinced to remove the requirement in RFC 5280 that name constraints MUST be critical. We would then issue a new RFC (7280?) that said so. Soon there would be certificates around with non-critical name constraints, perfectly compliant with the new standard, but the old client would reject them.

So PHB is right. The client should not make validation on the certificates that they comply, unless the standard says that it should (or must or may).

As David Cooper said, RFC 5280 already says that anyway.

Yoav

---

From: Rob Stradling <[email-masked]>
Date: Thu, 31 May 2012 14:52:10 +0100

> overlooked the full implications of "[The name constraints] extension

I think it's worth noting that the X.509 spec and the current CABForum 
motion are in agreement.

X.509 (08/2005) says:
"8.4.2.2 Name constraints extension
...
This extension may, at the option of the certificate issuer, be either 
critical or non-critical. It is recommended that it be
flagged critical, otherwise a certificate user may not check that 
subsequent certificates in a certification path are located
in the name space intended by the issuing CA."

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 31 May 2012 15:05:52 +0100

On 05/31/2012 02:10 PM, Yoav Nir wrote:
> I don't see how PHB is wrong here. 

I think if you read what I wrote you'd see that I was correcting
wrong statements, e.g. cab forum are more open, that there is still
a draft standard. I wasn't getting back into the meat of the
extended discussion we had on this before. And I'm still not,
other than to point out that there is the ISE route.

S

> It would be wrong for an RP to check that a certificate complies with
RFC 5280. Suppose the discussion of a few months ago ended differently,
and the WG was convinced to remove the requirement in RFC 5280 that name
constraints MUST be critical. We would then issue a new RFC (7280?) that
said so. Soon there would be certificates around with non-critical name
constraints, perfectly compliant with the new standard, but the old
client would reject them.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 31 May 2012 14:08:25 +0000

>Is the US DoD using the name constraints extension?

The Federal Bridge CA uses critical NC in cross-certs it issues.

-- T

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 31 May 2012 10:36:23 -0400

In the context of bridge CA I agree that the NCs would have to be marked
critical. Otherwise every agency could issue certs for every other agency.

Commercial CA certification relationships are far more restrictive and in
particular they are not bidirectional.

We have a disagreement here between the US govt and their contractors and
the commercial sector. Now that is fine but I don't see how one PKI user
should get to dictate terms to the rest of us.

It is permitted by the X.509v3 spec and this is a purely operational
matter. PKIX should never have stuck their nose in and they should take it
out.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 31 May 2012 10:35:04 -0400

>Is the US DoD using the name constraints extension?

The U.S. federal PKI bridge (more broader than the DoD) relies on the name
constraints extension in cross certs.

Steve

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 31 May 2012 10:51:08 -0400

The issue does not have anything to do with the type of PKI.

As mentioned previously, X.509 does not call for any of the extensions in the certificate to be critical.

5280 profile choice is based on security since marking the constraints extensions NC exposes relying parties that do not understand the semantics of the extensions.

If you used X.509 as a model, basic constraints will not be marked critical either.

This crusade seems to be driven by outlier browsers' lack of support for the extension or by the desire to compromise security to enhance interoperability.

I started this thread to build consensus on options.  There are other threads to voice opinions on.

Let us keep this thread to discuss the options to build consensus since once again no one is saying anything new.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, May 31, 2012 10:36 AM
To: Miller, Timothy J.
Cc: IETF PKIX
Subject: Re: [pkix] Way Forward: Name Constraints Criticality

In the context of bridge CA I agree that the NCs would have to be marked critical. Otherwise every agency could issue certs for every other agency.

Commercial CA certification relationships are far more restrictive and in particular they are not bidirectional.

We have a disagreement here between the US govt and their contractors and the commercial sector. Now that is fine but I don't see how one PKI user should get to dictate terms to the rest of us.

It is permitted by the X.509v3 spec and this is a purely operational matter. PKIX should never have stuck their nose in and they should take it out.

On Thu, May 31, 2012 at 10:08 AM, Miller, Timothy J. <[email-masked]<mailto:[email-masked]>> wrote:

-- T

_______________________________________________
pkix mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pkix

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 31 May 2012 10:56:49 -0400

Open-ness depends on where you sit.

I just don't find the PKIX DoD cabal to be in the least bit open or
representative of my industry.

On Thu, May 31, 2012 at 10:05 AM, Stephen Farrell <[email-masked]
> wrote:

> > So PHB is right. The client should not make validation on the
> certificates that they comply, unless the standard says that it should (or
> must or may).
> >

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 31 May 2012 14:58:04 +0000

I guess I just don't see why you'd include NC in a cert but *not* mark it
critical.  Non-critical NC basically says "Beyond this point you should
{only see/never see} the following names, but we don't actually care if
you pay attention."

-- T

On 5/31/12 9:51 AM, "Santosh Chokhani" <[email-masked]> wrote:

>5280 profile choice is based on security since marking the constraints
>extensions NC exposes relying parties that do not understand the
>semantics of the extensions.
> 
>This crusade seems to be driven by outlier browsers¹ lack of support for
>the extension or by the desire to compromise security to enhance
>interoperability.
> 
>Let us keep this thread to discuss the options to build consensus since
>once again no one is saying anything new.
> 
>matter. PKIX should never have stuck their nose in and they should take
>it out.
>
>

---

From: Michael StJohns <[email-masked]>
Date: Thu, 31 May 2012 13:26:57 -0400

Phil - 

Reading the draft mozilla policy (http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html) you have two choices, either use technical controls or non-technical controls.  

For technical controls - you need to do NameConstraints, KeyUsage and ExtendedKeyUsage all in compliance with RFC5280.  (but see the exception cited in the document I note below) 

For non-technical controls, you need to be able to say the subordinate CA is following the rules.    So how hard is setting up an auditor or auditing process?

>Each externally-operated subordinate CA must either be audited in accordance with <http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/index.html>Mozilla's CA Certificate Policy or be technically constrained. 

And making me wonder once and for all if this is a strawman you've set up to try and knock down, the draft policy says:

>Name Constraints do not need to be marked as critical at this time. 

So exactly why are you trying to change RFC5280 when you've already been given a get out of jail free card?

At 05:41 PM 5/30/2012, Phillip Hallam-Baker wrote:
>What I propose to do is to write a document that explains the steps that are necessary to write software that works with and the security consequences of accepting the certificates that CAs will be required to distribute in the next few weeks baring the (unlikely) event that Mozilla changes its mind.
>
>On Wed, May 30, 2012 at 3:35 PM, Santosh Chokhani <<mailto:[email-masked]>[email-masked]> wrote:
>PHB,
>
>On May 28, 2012, at 8:38, Yoav Nir <<mailto:[email-masked]>[email-masked]> wrote:
>
>> Hi Santosh
>>
>>> To: <mailto:[email-masked]>[email-masked]; Santosh Chokhani
>>> Cc: IETF PKIX
>>> The WKR has two types of CA signing it will do - the first contains an NC that constrains me to issue certificates with names that are subordinate to "<http://mikestjohnscompany.com>mikestjohnscompany.com" and costs X, the second that does not contain an NC and costs 10 X (mainly because the WKR doesn't want it competing with them for issuing TLS server certificates for random companies).
>>>
>>> If  the WKR is only getting X, then the WKR is going to want to make sure that the certificates issued by the subordinate CA are enforceably within <http://mikestjohnscompany.com>mikestjohnscompany.com which means setting the critical bit.   If your (Ryan, Phil, etc) assumption is that very few RPs understand NC, then setting the bit to non-critical means that the NC is basically useless, and almost any name issued by that subordinate CA is going to be accepted by the vast majority of RPs including those not under <http://mikestjohnscompany.com>mikestjohnscompany.com.
>>>
>>> <mailto:[email-masked]>[email-masked]
>> <mailto:[email-masked]>[email-masked]
>Website: <http://hallambaker.com/>http://hallambaker.com/
>

---

From: Adam Langley <[email-masked]>
Date: Thu, 31 May 2012 13:30:50 -0400

> {only see/never see} the following names, but we don't actually care if

The alternative is an intermediate CA certificate without any Name
Constraints at all. By including non-critical Name Constraints the
world benefits from fewer, all-powerful certificates as most clients
will enforce them. However, given the size of the Internet these days,
we can't reasonably deploy things that cause significant breakage.

This is not ideal. Ideally we wouldn't start from where we are but,
given that we have to, I believe that this is a positive step.

Cheers

AGL

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 31 May 2012 14:20:36 -0400

Nobody disputes that CAs should and will do things that avoid significant breakage.

The question is whether the purpose of RFC 5280 is to define a "correct" profile (defining what we're trying to achieve) or a "practical" profile (defining things that are not desired, but are necessary to accommodate deficiencies in the current environment).

If we were writing an electric power profile, the choice is between saying line voltage on customer premises:
  *  MUST be 120V +/-5V  (knowing full well that under peak demand the utility
     may need to violate the standard and crank it down to 100V to avoid losing
     power altogether), or
  *  SHOULD be 120V  (allowing the utility the freedom to do whatever it thinks necessary
     without being declared out-of-spec)

My vote is still for the "correct" profile.  A CA may issue certs that don't follow 5280 when necessary to accommodate market conditions.  But the fact that there are exceptions is a signal to the CA to periodically re-evaluate the market and remove the exception when it becomes practical to do so.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Langley
Sent: Thursday, May 31, 2012 1:31 PM
To: Miller, Timothy J.
Cc: IETF PKIX
Subject: Re: [pkix] Way Forward: Name Constraints Criticality

On Thu, May 31, 2012 at 10:58 AM, Miller, Timothy J. <[email-masked]> wrote:
> I guess I just don't see why you'd include NC in a cert but *not* mark 
> it critical.  Non-critical NC basically says "Beyond this point you 
> should {only see/never see} the following names, but we don't actually 
> care if you pay attention."

The alternative is an intermediate CA certificate without any Name Constraints at all. By including non-critical Name Constraints the world benefits from fewer, all-powerful certificates as most clients will enforce them. However, given the size of the Internet these days, we can't reasonably deploy things that cause significant breakage.

This is not ideal. Ideally we wouldn't start from where we are but, given that we have to, I believe that this is a positive step.

Cheers

AGL

---

From: Steve Howard <[email-masked]>
Date: Thu, 31 May 2012 16:27:07 -0400

I have been watching this thread with interest.  So far, the discussion does
not contemplate bridged infrastructure.  Rather, the predominance of the
discussion is driven by the PKI up to a WKR.

As a bridge, CertiPath does apply name constraints, and we mark them
critical, for our enterprise customers.  We find this both useful and not to
be an interoperability issue for our customers.

Respectfully,
Steve

Stephen P. Howard | Vice President, Credentials | CertiPath LLC
2300 Corporate Park Drive, Ste 150, Herndon, VA 20171
PH +1.703.793.7879 | Direct +1.703.319.3171 | FAX +1.703.773.6262
Email [email-masked]
CertiPath: Enabling Trusted Communication www.certipath.com

-----Original Message-----
From: Wan-Teh Chang [mailto:[email-masked]] 
Sent: Wednesday, May 30, 2012 7:31 PM
To: IETF PKIX
Subject: Re: [pkix] Way Forward: Name Constraints Criticality

Isn't it possible that the reviewers of such a long document may have
overlooked the full implications of "[The name constraints] extension MUST
be critical"?

Thanks,
Wan-Teh

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 1 Jun 2012 09:50:36 +1000

> {only see/never see} the following names, but we don't actually care if

The last phrase is better re-phrased as:
"..., but we [the CA] don't actually force you [the relying parties] to pay attention -- that is your choice/responsibility."

RFC5280 almost gives each relying party the choice by saying they SHOULD (not MUST) handle name constraints on domain names, but then effectively takes away that choice by forcing a CA to make one decision for all relying parties (critical constraint, or no constraint). 

--
James Manger

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 31 May 2012 22:19:37 -0400

I am not going to reply to the points discussed at length already.

I do however note that the security considerations for marking name
constraints critical are markedly different for bridge CA configurations.

In particular you are going to be a most unhappy bunny if you try to
operate a bridge CA type infrastructure and do not mark your NCs as
critical. In particular every CA in the bridge becomes a defacto root for
every other member and the whole point of the bridge is utterly lost.

Whether it is a must or a should, we probably don't want that particular
point to get lost.