Subject: [pkix] NameConstraints criticality flag

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 25 May 2012 12:47:49 -0400

The issue was discussed here earlier without a conclusion. I just wanted to
point out that the issue is currently the subject of a ballot in CABForum:

http://cabforum.org/pipermail/public/2012-May/000027.html

Delete the following text from the "Subordinate CA Certificate" section of
both the Baseline Requirements Appendix B and EV Guidelines Appendix B:
 "All other fields and extensions MUST be set in accordance to RFC 5280."
 AND replace it with the following:
 "F. nameConstraints (optional)
 . If present, this extension SHOULD be marked critical*.
 All other fields and extensions MUST be set in accordance to RFC 5280.
 * Non-critical Name Constraints are an exception to RFC 5280 that MAY be
used until the Name Constraints extension is supported by Application
Software Suppliers whose software is used by a substantial portion of
Relying Parties worldwide."

Anyone who wants to follow the ballot discussion can do so at:
http://cabforum.org/mailman/listinfo/public

The reason this change is being considered is as follows:

1) Deployment of name constraints without a criticality flag provides an
immediate an advantageous reduction in risk without impact on any deployed
systems.

2) Deployment of name constraints with a criticality flag would entail an
unacceptable incompatibility with widely deployed systems.

3) None of the following reasons advanced for requiring name constraints to
be marked critical has been found to be persuasive:

3a) 'Critical means important' - no it does not, clients are required to
process extensions that they understand regardless of whether they are
marked critical or not.

3b) 'This is not a requirement for the DoD' - this is not about the DoD PKI.

3c) 'People should deploy RFC 5280 compliant systems rather than change the
spec' - This is not a normative argument. People should live in brotherly
peace and harmony too but the fact that they don't is the reason we need
PKI in the first place.

This change has been considered by a group of experts whose credentials and
experience in the PKI space is at least equal to that of this WG. So
please, no appeals to authority.

Should this ballot pass, I will submit an ID to propose making the same
change to RFC5280 as an erratum. In my personal view, it is clearly
desirable for the IETF specifications to track the deployed specification.

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

---

From: Michael StJohns <[email-masked]>
Date: Fri, 25 May 2012 15:57:49 -0400

I hesitate to respond to this, but my review of the bidding is not that there wasn't a conclusion, but that there was no consensus for change.

I think I support the status quo.

Assuming a "Root CA -> CA with Name Constraint -> End Entity certificate chain" there are three degrees of freedom:  1) Whether the NC is marked critical, 2) whether the EE certificate has a name compliant with the NC, and 3) whether the RP understands the NC extension.

The combinations are thus:

Critical/Compliant/Understands - >  Accepts the cert
Critical/Compliant/Does not understand -> Rejects the cert  ****
Critical/Non-Compliant/Understands -> Rejects the cert
Critical/Non-Compliant/Does not understand -> Rejects the cert
Non-Critical/Compliant/Understands -> Accepts the cert
Non-Critical/Compliant/Does not understand -> Accepts the cert
Non-Critical/Non-Compliant/Understands -> Rejects the cert
Non-Critical/Non-Compliant/Does not understand -> Accepts the cert.  ****

(There is one other combination - no NC present -> Accepts the cert)

The two items marked with **** are combinations where possibly the "wrong" thing happened.  The first one is just due to the implementation at the RP not being complete enough, but complies with the policy imposed on the NC CA by the root.  The second is due to a violation of policy - the NC CA was able to issue a certificate with a name that violated the name constraints imposed upon it by the root CA and have it accepted by an RP that didn't understand the NC extension. 

You also end up with a situation where a "GOOD" RP (one that understands the NC), ends up rejecting the certificate - which is probably not what you wanted.

Phil - you're proposing a change which is the equivalent of posting a guard at the door to a building and requiring the guard to reject bad badges if they are offered, but allowing anyone who doesn't present a badge to enter the building.

If the Root CA doesn't care about enforceable name constraints, it probably shouldn't include them in the NC CA certificate.  If it wants them to be enforced, then the NC extension needs to be marked critical.

And on a last topic.  I'm finding the arm twisting a bit distasteful.  If the CAB forum wants to pick its marbles and leave, just do it and stop trying to coerce the process.

Mike

At 12:47 PM 5/25/2012, Phillip Hallam-Baker wrote:
>The issue was discussed here earlier without a conclusion. I just wanted to point out that the issue is currently the subject of a ballot in CABForum:
>
><http://cabforum.org/pipermail/public/2012-May/000027.html>http://cabforum.org/pipermail/public/2012-May/000027.html 
>
>Delete the following text from the "Subordinate CA Certificate" section of both the Baseline Requirements Appendix B and EV Guidelines Appendix B:
>* Non-critical Name Constraints are an exception to RFC 5280 that MAY be used until the Name Constraints extension is supported by Application Software Suppliers whose software is used by a substantial portion of Relying Parties worldwide."
>
>
><http://cabforum.org/mailman/listinfo/public>http://cabforum.org/mailman/listinfo/public 
>
>1) Deployment of name constraints without a criticality flag provides an immediate an advantageous reduction in risk without impact on any deployed systems.
>
>2) Deployment of name constraints with a criticality flag would entail an unacceptable incompatibility with widely deployed systems.
>
>3) None of the following reasons advanced for requiring name constraints to be marked critical has been found to be persuasive: 
>
>3a) 'Critical means important' - no it does not, clients are required to process extensions that they understand regardless of whether they are marked critical or not.
>
>3c) 'People should deploy RFC 5280 compliant systems rather than change the spec' - This is not a normative argument. People should live in brotherly peace and harmony too but the fact that they don't is the reason we need PKI in the first place.
>
>This change has been considered by a group of experts whose credentials and experience in the PKI space is at least equal to that of this WG. So please, no appeals to authority.
>
>
>Should this ballot pass, I will submit an ID to propose making the same change to RFC5280 as an erratum. In my personal view, it is clearly desirable for the IETF specifications to track the deployed specification.
>
>-- 
>Website: <http://hallambaker.com/>http://hallambaker.com/
>
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

---

From: Wan-Teh Chang <[email-masked]>
Date: Fri, 25 May 2012 13:52:39 -0700

On Fri, May 25, 2012 at 12:57 PM, Michael StJohns <[email-masked]> wrote:
>
> Phil - you're proposing a change which is the equivalent of posting a guard
> at the door to a building and requiring the guard to reject bad badges if
> they are offered, but allowing anyone who doesn't present a badge to enter
> the building.

No.  A better analogy is as follows:

Current status: no buildings have a guard posted.  A person who
doesn't present a badge can enter all buildings.

Proposed change: some buildings will have guards posted.  A person who
doesn't present a badge can still enter the buildings that have no
guards, but won't be able to enter the buildings that have guards
posted.

Wan-Teh

---

From: Martin Rex <[email-masked]>
Date: Fri, 25 May 2012 22:59:12 +0200 (MEST)

Michael StJohns wrote:
> 
> Phil - you're proposing a change which is the equivalent of posting
> a guard at the door to a building and requiring the guard to reject
> bad badges if they are offered, but allowing anyone who doesn't
> present a badge to enter the building.

This is an incorrect analogy.

The certificate holder himself can not selectively make the name constraint
invisible to RPs.  ONLY the issuing CA can perform an educated individual
risk management decision whether a name constraint imposed on a certificate
it issues must be unconditionally enforced, or whether it is sufficient
when only the RPs that care reject it.

Since it is up to the CA that issues the cert, it remains in full control
of the feature.  There will be exactly ZERO unforseeable consequences,
and it is the behaviour recommended by X.509! (and where the PKIX profile
differs from X.509 without providing a justification--and no matter how
much you and others in the PKIX WG have been writing, I have not seen
a single rationale that could justify to _not_ let the CA decide about
criticality of name constraints.

> 
> If the Root CA doesn't care about enforceable name constraints,
> it probably shouldn't include them in the NC CA certificate.
> If it wants them to be enforced, then the NC extension needs
> to be marked critical.

I'm sorry, but that explanation does not account for the fact that
support for name constraints has always been, and still is optional
for RPs and has resulted in a huge installed base that does, in fact,
not support name constraints (that includes all version of OpenSSL < 1.0)

> 
> And on a last topic.  I'm finding the arm twisting a bit distasteful.
> If the CAB forum wants to pick its marbles and leave, just do it and
> stop trying to coerce the process.

The idea behind X.509 certificate profiles is that consumers can
select the certificate profile that fits best their usage requirements.

As it has become obvious, the certificate profile that calls itself
the "Internet Certificate and CRL profile" has been neglecting itself
and the installed base on what it says about name constraints.

There are two possible resolutions: the Internet Certificate and CRL profile
(PKIX) is changed to match the installed base, or the applications will
have to use a different or modified profile that matches their requirements
better.

Listen to your customers, or your customers will eventually go elsewhere!

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 25 May 2012 17:29:06 -0400

On Fri, May 25, 2012 at 3:57 PM, Michael StJohns <[email-masked]>wrote:

>  I hesitate to respond to this, but my review of the bidding is not that
> there wasn't a conclusion, but that there was no consensus for change.
>
> Assuming a "Root CA -> CA with Name Constraint -> End Entity certificate
> chain" there are three degrees of freedom:  1) Whether the NC is marked
> critical, 2) whether the EE certificate has a name compliant with the NC,
> and 3) whether the RP understands the NC extension.
>
> The two items marked with **** are combinations where possibly the "wrong"
> thing happened.  The first one is just due to the implementation at the RP
> not being complete enough, but complies with the policy imposed on the NC
> CA by the root.  The second is due to a violation of policy - the NC CA was
> able to issue a certificate with a name that violated the name constraints
> imposed upon it by the root CA and have it accepted by an RP that didn't
> understand the NC extension.
>

I don't understand your analysis here.

Nothing that is being proposed will actually affect the required behavior
of the clients. The only thing that will change is that CAs will now be
permitted to issue certificates with a non critical NC constraint and so
the last four cases are more likely to occur.

We don't actually have the following conditions occurring in the wild:

Non-Critical/Compliant/Understands -> REJECT for violating RFC5280
Non-Critical/Compliant/Does not understand ->  REJECT for violating RFC5280

Non-Critical/Non-Compliant/Understands ->  REJECT for violating RFC5280
Non-Critical/Non-Compliant/Does not understand -> REJECT for violating
RFC5280

So we are not talking about a change in code here, merely a change in what
CAs will be issuing.

 You also end up with a situation where a "GOOD" RP (one that understands
> the NC), ends up rejecting the certificate - which is probably not what you
> wanted.
>

That is not an observed behavior in existing systems. The criticality flag
does not affect the semantics of an extension. The only change in behavior
is directed at systems that don't support the extension.

In this case the desired behavior is that systems that do not enforce NCs
ignore them and accept the certificate.

>  Phil - you're proposing a change which is the equivalent of posting a
> guard at the door to a building and requiring the guard to reject bad
> badges if they are offered, but allowing anyone who doesn't present a badge
> to enter the building.
>

Absolutely not the case. What I am proposing is exactly what Visa and
MasterCard have done with chip and pin. If you have a C&P card then you
must use the C&P authentication system but a C&P enabled POS terminal MAY
accept legacy mag stripe cards because the US banks are too thick to
realize that there is a demand.

Now in practice there are many merchants that do in fact adopt your
approach which is why using US issued CCs is now almost impossible in
non-tourist parts of Europe. Whatever the interchange agreement might say,
many merchants do not accept magstripe cards and the European banks have
zero intention of forcing them to.

If the Root CA doesn't care about enforceable name constraints, it probably
> shouldn't include them in the NC CA certificate.  If it wants them to be
> enforced, then the NC extension needs to be marked critical.
>

That is your opinion. The CAs and the browser providers appear to have come
to a different conclusion.

>  And on a last topic.  I'm finding the arm twisting a bit distasteful.  If
> the CAB forum wants to pick its marbles and leave, just do it and stop
> trying to coerce the process.
>

You mean, like was done to the ITU X.509 working group almost twenty years
ago now.

The fact is that I am rather tired of the current situation where only the
US Govt. and its contractors get to have any input into this working group.
Or more specifically the US DoD and its contractors.

We have a real world constraint here that we have to meet in our
deployment. Progress in the WG was held up by a handful of people who have
no stake in the matter. So the decision has moved elsewhere. If you don't
like that outcome then maybe this WG needs to rethink the way that it works
as have many other IETF WGs.

I really don't see a reason why US DoD and its contractors should get to
veto standards for commercial PKI.

At present the assumption seems to be that PKIX is perfect and any proposal
for change should begin from the presumption that change is bad. Other WGs
have decided that change is a good thing and that opponents should be able
to point to some harm.

You can try to pretend that the only reason for the current breakdown in
the relationship between the PKI industry and the PKIX working group is
that the commercial CAs and browser providers don't understand the security
risks. I think it is rather ridiculous that the WG would want to take the
disagreement to the point of forcing an actual divorce. To take it to the
point of a breach over a single bit is a bit like having a

As far as I am concerned the mandate of this WG is not to teach the
industry how to suck eggs. We really do have quite a bit of security
expertise.

The scope of PKIX should be strictly limited to defining standards and
specifications. It should explain the security consequences of a
configuration but it should not presume to decide what the appropriate risk
mitigation strategy is for the industry.

The only reason we have a schism here is because the PKIX WG has
overstepped the scope of authority that the industry is willing to grant
it. You can get upset about that if you like. But remember how this
started. The industry came to IETF because it was unhappy with ITU process.
The only reason that PKIX matters is because there is an industry that mad
it matter.

You might want the PKIX WG to have authority over the industry, but that
was never the deal.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 25 May 2012 23:13:59 -0400

That is precisely right, the desired behavior is:

Compliant/Understands -> Accepts the cert
Compliant/Does not understand -> Accepts the cert
Non-Compliant/Understands -> Rejects the cert
Non-Compliant/Does not understand -> Accepts the cert.

We expressly DO NOT WANT browsers to reject a certificate unless they
understand the NC constraint. That is the behavior we desire.

That is precisely the behavior that not setting the criticality bit provides.

On Fri, May 25, 2012 at 10:03 PM, Ryan Sleevi <[email-masked]> wrote:
> This last behaviour, which you identify as the "wrong" thing happening, is
> realistically a policy decision, and one that should be dealt with by the
> respective CA and their policies.
>
> So rather than the "wrong thing", it's the exact same thing as the "No NC
> Present" case. Same result - so for CAs, this is the RIGHT thing, because
> it has no discernable behaviour change for clients in the
> "Non-Critical/Non-Compliant/Does not understand" case from the effective
> "No NC Present", while it IMPROVES the situation for the
> "Non-Critical/Non-Compliant/Understands" case.
>
> The current state of the industry is that no public CA issuing public
> certificates for use on the Internet wants to use name constraints,
> because they present a compatibility issue. CAs therefore choose to issue
> unconstrained CAs, which are accepted by clients, and rather than
> technical measures, attempt to use procedural/contractual/legal measures
> to constrain the CA.
>
> As Phil has pointed out, this is undesirable for browser vendors and other
> RPs, because there is no programatic awareness of whatever the procedural
> or contractual constraints may be between the two CAs, therefore it's not
> possible to detect violations of policy.
>
> For a CA that wishes to programatically enforce NC as policy:
>  - Mark the extension as critical, and it will be processed as such.
> For a CA that wishes to programatically /advertise/ NC:
>  - Mark the extension as non-critical. Compliant implementations will
> process or reject. Non-compliant implementations will treat it as if
> there was no NC present.
>
>
>>
>>  CA by the root.  The second is due to a violation of policy - the NC CA
>>  was able to issue a certificate with a name that violated the name
>>  constraints imposed upon it by the root CA and have it accepted by an RP
>>  that didn't understand the NC extension.
>>
>>  the NC), ends up rejecting the certificate - which is probably not what
>>  you wanted.
>>
>>  badges if they are offered, but allowing anyone who doesn't present a
>>  badge to enter the building.
>>
>>  If the Root CA doesn't care about enforceable name constraints, it
>>  probably shouldn't include them in the NC CA certificate.  If it wants
>>  them to be enforced, then the NC extension needs to be marked critical.
>>
>> >The issue was discussed here earlier without a conclusion. I just wanted
>> > to point out that the issue is currently the subject of a ballot in
>> > CABForum:
>> >
>> >Delete the following text from the "Subordinate CA Certificate" section
>> > of both the Baseline Requirements Appendix B and EV Guidelines Appendix
>> > B:
>> > immediate an advantageous reduction in risk without impact on any
>> > deployed systems.
>> >
>> >3) None of the following reasons advanced for requiring name constraints
>> > to be marked critical has been found to be persuasive:
>> >
>> >3c) 'People should deploy RFC 5280 compliant systems rather than change
>> > the spec' - This is not a normative argument. People should live in
>> > brotherly peace and harmony too but the fact that they don't is the
>> > reason we need PKI in the first place.
>> >
>> >This change has been considered by a group of experts whose credentials
>> > and experience in the PKI space is at least equal to that of this WG. So

---

From: 王文正 <[email-masked]>
Date: Sat, 26 May 2012 14:57:19 +0800

Phillip,

If the "we" in your last post means the CAB Forum, I would like to remind you that the ballot is still in progress and its close date is June 1.
Therefore, what you posted here does not necessary reprsent the consensus of the CAB Forum.
There might be members, like me, who will choose to vote against the motion. Who knows.
I think it will be more appopriate if we wait untill the ballot closed and then speak here for the CAB Forum.

Wen-Cheng Wang

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Phillip Hallam-Baker [[email-masked]]
Sent: Saturday, May 26, 2012 11:13 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] NameConstraints criticality flag

On Fri, May 25, 2012 at 10:03 PM, Ryan Sleevi <[email-masked]> wrote:
>> >Website: <http://hallambaker.com/>http://hallambaker.com/<http://hallambaker.com/%3Ehttp://hallambaker.com/>
>> >

---

From: Martin Rex <[email-masked]>
Date: Sat, 26 May 2012 14:10:36 +0200 (MEST)

Speaking about support of NameConstraints (I briefly looked at the
code in OpenSSL 1.0), the existing PKIX document looks somewhat
unclear to me.

rfc5280 Section 6.1 Basic Path Validation says

   The primary goal of path validation is to verify the binding between
   a subject distinguished name or a subject alternative name and
   subject public key, as represented in the target certificate, based
   on the public key of the trust anchor.  In most cases, the target
   certificate will be an end entity certificate, but the target
   certificate may be a CA certificate as long as the subject public key
   is to be used for a purpose other than verifying the signature on a
   public key certificate.  Verifying the binding between the name and
   subject public key requires obtaining a sequence of certificates that
*> support that binding.  The procedure performed to obtain this
*> sequence of certificates is outside the scope of this specification.

and declares the "procedure to obtain this sequence of certficates
outside of the scope of this specification".

But looking at ITU-T X.509 (11/2008), Processing of name constraints

Appendix G.3.3

   G.3.3 Examples where multiple Cross Certificates with
         Name Constraint Extension are needed

  In some cases, it may be required that more than one certificate be
  issued from a CA to another CA in order to achieve the desired results.
  This might be the case if some of the name constraints requirements
  conflict, or if the disjunctive evaluation of different name forms
  is required.

There seems to be a contradiction in that processing of name constraints
has a prerequisite of building several alternative certification paths,
and this very issue being out of scope for PKIX.

Looking at the details of name constraints processing, the included
subtree looks like white-listing, whereas the excluded subtree looks
like black-listing (the latter being an unconditionally bad idea when
it comes to security).

While i believe that strict processing of the included tree (memcmp
on the head of the ASN.1 blob) is a good idea, I'm wondering what
kind of comparison is expected for the excluded subtree?  Should there
be a memcmp on the head of the ASN.1 blob as well, or is a component-wise
comparison of the RDName attribute values expected that normalizes the
attribute values to the same encoding for comparison and performs
case-insensitive comparison of the attribute values where the
directory attributes call for it.

And what about the weird side effect of ASN.1 DER encoding of multiple
Attribute value pairs within an RDName set?

If it is supposed to be a security feature, the specification should
have clearly predictable behaviour.  To me, it doesn't look that there
is predictable behaviour specified for processing of name constraints
for distinguished names.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 26 May 2012 12:53:44 -0400

Absolutely correct. Which I tried to make clear in the first post informing
people that the ballot is in progress

The industry has not yet decided this issue. But it has decided to decide.
The issue is not going to be blocked by a handful of people in this working
group

The IETF may not have votes but that does not stop others holding one

I see no reason to defer to people who are not interested in my
requirements and give me no vote

Sent from my iPhone

On May 26, 2012, at 2:57 AM, "王文正" <[email-masked]> wrote:

 Phillip,

If the "we" in your last post means the CAB Forum, I would like to remind
you that the ballot is still in progress and its close date is June 1.
Therefore, what you posted here does not necessary reprsent the consensus
of the CAB Forum.
There might be members, like me, who will choose to vote against the
motion. Who knows.
I think it will be more appopriate if we wait untill the ballot closed and
then speak here for the CAB Forum.

 Wen-Cheng Wang

 ------------------------------
*From:* [email-masked] [[email-masked]] On Behalf Of Phillip
Hallam-Baker [[email-masked]]
*Sent:* Saturday, May 26, 2012 11:13 AM
*To:* [email-masked]
*Cc:* [email-masked]
*Subject:* Re: [pkix] NameConstraints criticality flag

That is precisely the behavior that not setting the criticality bit
provides.

>>  And on a last topic.  I'm finding the arm twisting a bit distasteful.
 If
>> ><http://cabforum.org/pipermail/public/2012-May/000027.html>
>> ><http://cabforum.org/mailman/listinfo/public>

---

From: Russ Housley <[email-masked]>
Date: Sat, 26 May 2012 14:34:14 -0400

Phillip:

> I see no reason to defer to people who are not interested in my requirements and give me no vote

Indeed.  Why should the open IETF community defer to a closed community?

Russ

---

From: Santosh Chokhani <[email-masked]>
Date: Sat, 26 May 2012 17:33:01 -0400

+1

Why don't these folks go and work with Opera and Safari developers to get this right.  There are open source toolkits if these folks need the code or reference implementation to see a worked example.

I see no need or benefit to dilute a security standard for the implementers who do not get security or do not want to implement when explained.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Saturday, May 26, 2012 2:34 PM
To: IETF PKIX
Subject: Re: [pkix] NameConstraints criticality flag

Phillip:

Russ

---

From: "Ryan Sleevi" <[email-masked]>
Date: Sat, 26 May 2012 14:57:35 -0700

>  +1
>
>  Why don't these folks go and work with Opera and Safari developers to get
>  this right.  There are open source toolkits if these folks need the code
>  or reference implementation to see a worked example.

As mentioned several times already, because regardless of what tomorrows
software does, there will still be millions of users who wish to use the
Internet who will be running older software.

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.

Further, unless and until every single CA simultaneously adopts critical
NC, there will always be an incentive for CAs to offer
technically-unconstrained (but still constrained by
legal/procedural/contractual) sub-CAs, since that is the only RFC 5280
'compliant' means.

This continued hardline opposition to non-critical nameConstraints does
nothing doom them to being a non-implementable relic of the standards
process, rather than being a viable path forward to a more secure
Internet. Certainly, it would mean that the PKIX profile and the "PKI on
the Internet" profile end up diverging, which does nothing to help
adoption or understanding.

>
>  I see no need or benefit to dilute a security standard for the
>  implementers who do not get security or do not want to implement when
>  explained.

As has also been mentioned before, the expectation of 'fail closed' when
encountering NC is a realistic decision of policy, not security, and has
arguably no place in an IETF standard. While you can say that always
having 'fail closed' is good for security, which I think no one will
disagree with you on, the decision on when it's desirable to 'fail open'
and 'fail closed' is one that should be left to relying parties, NOT
mandated.

It's not a matter of "implementers who do not get security" at this point
- it's a matter of "standards making unnecessary policy requirements". As
easy as it is to make ad hominem attacks, it's a lot harder to rewrite
history and have all legacy implementations supporting nameConstraints. So
rather than trying to do that, can we at least recognize the policy
decision involved here?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 26 May 2012 18:06:58 -0400

Anyone who agrees to the IPR policy can participate in CABForum

CABforum is considerably more open in its governance than IETF. Here i have absolutely no decision making power. Nor have i any vote.

So if CaBForum is closed, then so is IETF. 

I do not see a process in which an obstructionist minority can exercise veto power to defend the status quo regardless of merit to be consensus based. 

If you want decision making to return to the IETF in matters PKI then we are going to have to consider a charter change for this WG as a minimum.

Sent from my iPad

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 26 May 2012 18:20:40 -0400

Of course it is in everyones interest for every browser to support NCs. But many deployed browsers cannot be updated and we see no reason to brick peoples mobile phones.

As for people not getting security, you really do need to understand the difference between not accepting your conslusion and not being competent. They simply do not consider your position to be valid and they are ignoring it. Calling them stupid is not going to cause them to revise their opinion.

Sent from my iPad

On May 26, 2012, at 17:33, Santosh Chokhani <[email-masked]> wrote:

> +1
>  
> Why don’t these folks go and work with Opera and Safari developers to get this right.  There are open source toolkits if these folks need the code or reference implementation to see a worked example.
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 26 May 2012 23:41:52 +0100

Phill,

> So if CaBForum is closed, then so is IETF. 

That is such utter nonsense.

My guess is that you know its nonsense too but somehow
think it helps your argument. From I would say pretty
much any P-O-V, it just doesn't. (Unless maybe the P-O-V
with one's foot in one's mouth perhaps;-)

S.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 26 May 2012 18:11:59 -0700

The CABForum is a major user of the specs from this WG, so participation there seems on-topic for this mailing list, at least for a bit.

> Anyone who agrees to the IPR policy can participate in CABForum

Is that true? I see no mention of that rule on the CABForum web page. Further, I see no mention of the current members or its leadership.

> CABforum is considerably more open in its governance than IETF.

That's good to hear, but hard to verify. Where are the CABForum's governance rules listed? Where is its leadership listed?

(FWIW, these questions aren't aimed at Phill. Anyone from the CABForum is welcome to educate those of us who can't find the information!)

--Paul Hoffman

---

From: Michael StJohns <[email-masked]>
Date: Sat, 26 May 2012 21:14:52 -0400

>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: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 26 May 2012 21:46:05 -0400

On Sat, May 26, 2012 at 9:14 PM, Michael StJohns <[email-masked]>wrote:

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

Think of it like a spam filter.

It is much more important for a spam filter to ensure that all legitimate
mail is delivered than to ensure that no spam gest through. Setting the
criticality bit ensures that about 20% of users will get a false positive
rejection of the cert.

A false positive rate of even 1% is unacceptable.

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

You make a major mistake here in assuming that the value of name
constraints is in client enforcement.

Actually I think client enforcement of PKI path math is rather over-rated
compared to the power of being able to detect AND REPORT anomalies.

Since the majority of browsers do process Name Constraints, lets use this
tool right now.

> 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 seem confused here. The critical flag has no effect on any browser
unless it does not support the marked extension.

A browser MAY reject a certificate for not being compliant with RFC 5280,
but no browser is known to do so.

A browser that processes Name Constraints is REQUIRED to do so EVEN IF THE
CRITICALITY BIT IS NOT SET.

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

It won't be compliant with the 5280 profile, correct.

But how do we proceed if (as I expect) we have an essentially unanimous
vote by the browser providers and the CAs to ignore 5280 on this point?

Wouldn't that demonstrate a clear consensus in the industry in favor of the
change?

I think that the decision making in PKIX is broken and that there have to
be changes or this group is going to be irrelevant.

At the moment there is a presumption in favor of the status quo and any
proposal that is brought here is shot down by a small group of people
regardless of the merits.

That isn't going to work any more.

If what you really want is for all those annoying industry people to go
take their ball home and play elsewhere then just let us know and we can do
just that and leave you to do whatever it is you want to do in peace.

If you want us to stay then you have to accept that we understand our own
requirements and respect that our expertise in the field may equal or even
exceed your own.

Zero false positives is an absolute requirement for us.

---

From: "Ryan Sleevi" <[email-masked]>
Date: Sat, 26 May 2012 18:50:55 -0700

On Sat, May 26, 2012 6:14 pm, Michael StJohns wrote:
>  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.
>
>  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.
>
>  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).
>
>  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.

Here's where it breaks down, and with all due respect to the CAs that
participate here and in the CABForum: There is absolutely zero economic or
practical incentive for the WKR to want to "make sure that the
certificates issued by the subordinate CA are enforcably within
mikestjohncompany.com"

That's the reality of today and the past two decades. The WKR has
absolutely zero obligation or incentive to protect clients/RP. They have
every economic incentive to ensure you, Mike StJohns, don't start issuing
certs off your root, which is why they constrain you with contractual and
legal means, and every market incentive to ensure that if you, Mike
StJohns, ask for a cert that can work with 98% of user-facing clients, it
will. If they find you to be issuing certs outside of your contract,
they'll revoke your cert - but that's not because of a desire to protect
clients/RPs, that's out of a desire to protect their business interests
(as you note when comparing X vs 10X's cost/benefits).

Browser vendors and root store operators understandably don't like this -
this leaves enforcement and detection solely in the hands of the WKRs,
many of whom will not or cannot (due to contractual, legal, or economic
reasons) disclose that they've issued an intermediate CA to Mike StJohns
for use within mikestjohnscompany.com. This is bad.

Now, if we continue further, one could argue that browsers/RPs should
simply say the NC MUST be critical or the root will be removed. For public
CAs that are "Too Big Too Fail", this penalizes the browsers and users, in
that removing such roots now means that users cannot validate 9/10 of the
certificates on the Internet. For WKRs, such a requirement creates an
economic penalty that is potentially life-threatening to their business -
and must be protected by any means possible.

Instead, a compromise has been reached - non-critical name constraints.
Browsers can then programatically enforce what the WKRs are contractually
enforcing, and WKRs can now programatically advertise the constraints
they're enforcing contractually/legally. Further, as shown by proposed
changes to items such as the Mozilla Root Certificate Policy, technical
constraints can then be incorporated as /requirements/ for inclusions
within the root store programs - ensuring that they get widely deployed by
CAs. Further, if you want to buy one of those 10X certificates from a WKR,
root store requirements such as Mozilla's will require that you be
/audited/ to the same degree as the WKR - something that cannot and is not
distinguished by today.

As more and more NC-certs are issued, clients/libraries that don't
implement support for NC are now seen as security liabilities - and 'the
market' can take care of educating customers/users, which encourages
vendors to implement support for NC /as written/.

People on the list can defend the purity of RFC 5280, its grand and noble
intentions for security, but the reality is that many clients don't even
ascribe to implement all of RFC 5280, 'just enough' to have some perceived
modicum of security. If you were to look in any of the IETF Working
Groups, you'd undoubtedly see a concern for and recognition of legacy
interoperability - but here, it seems anathema to make any concessions
that would aid such a goal.

Again, I don't think anyone one disagrees that critical NC would be a
great thing. But without a giant Internet flag day - which no one really
wants and the economic incentives favour those who don't - their
deployment is simply not going to happen.

>    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: Tom Ritter <[email-masked]>
Date: Sat, 26 May 2012 23:09:56 -0400

I was the only non-member at the first "Open" meeting of the CABForum, and
subsequent meetings have been reverted back to private invitation. Also, my
contribution to the "public list" (non antagonistic, merely pointing out a
relevant link) was rejected because I'm not a member.

The suggestion that it is more open, _right now_ is ridiculous.  Once the
new governance proposals (which are secret as of now) are decided on and
take effect, maybe it will approach the level of openness the IETF enjoys,
where at least anyone can voice opinions and propose changes.

I don't aim to turn this list into a place to air grievances with the
forum, but because you asked, and because I have tried to be involved, I'll
offer my experiences.

-tom

---

From: Sean Leonard <[email-masked]>
Date: Sat, 26 May 2012 22:48:54 -0700

On 5/26/2012 6:46 PM, Phillip Hallam-Baker wrote:
> It is much more important for a spam filter to ensure that all 
> legitimate mail is delivered than to ensure that no spam gest through. 
> Setting the criticality bit ensures that about 20% of users will get a 
> false positive rejection of the cert.
>

This is a misleading characterization.

Enforcing the processing of a name constraint extension is more like a 
false negative. The cert "should be valid", but the processing software 
says "it's not valid", because the criticality bit is enforced when the 
extension cannot be processed. That would be a false negative.

False negatives are sad. A system with a high degree of false negatives 
is not usable. Spam filters, of course, have a lot of false negatives.

But false positives (accepting a certificate when it is widely 
recognized to be invalid, such as the ComodoHacker and DigiNotar 
incidents) are far worse.

> Zero false positives is an absolute requirement for us.

Zero false positives is a requirement for strong security in the 
Internet community. Just don't confuse which is "false positive" and 
which is "false negative". See DigiNotar. The browser industry voted on 
that with its feet.

Sean

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 27 May 2012 07:56:14 -0400

On Sun, May 27, 2012 at 1:48 AM, Sean Leonard <[email-masked]> wrote:

> False negatives are sad. A system with a high degree of false negatives is
> not usable. Spam filters, of course, have a lot of false negatives.
>
> But false positives (accepting a certificate when it is widely recognized
> to be invalid, such as the ComodoHacker and DigiNotar incidents) are far
> worse.

Since the Comodo certificates were revoked, an RP that implemented
revocation checks properly should not have trusted the certs anyway.

Name Constraints would not have had any effect in either case.

>>
>
> Zero false positives is a requirement for strong security in the Internet
> community. Just don't confuse which is "false positive" and which is "false
> negative". See DigiNotar. The browser industry voted on that with its feet.

No, this proposal comes from Mozilla.

The browser providers have almost unanimously decided not to support hard
fail on revocation checks and have not revised that opinion in the light of
the attacks.

As a reality check here, application vulnerabilities are rather more
consequential than CA compromises such as buffer overruns and happen with
far greater frequency.

---

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

> incidents) are far worse.

I think you got your falses mixed. The terms are taken from medicine, where a "positive" means "yes, you have cancer", or actually from statistics where the null hypothesis is falsely rejected.  In security, a false positive would be rejecting a certificate that is valid, while a false negative is accepting a certificate that is not valid.

---

From: Tim Moses <[email-masked]>
Date: Mon, 28 May 2012 15:54:56 +0000

Hi Paul. The CABForum is currently in the throes of deciding what role it wants to play going forward. I think there has been some misunderstanding of its current role. The Forum exists to coordinate the views of SSL CAs and present those views to the PMAs of the secure Web, i.e. the browser/OS suppliers. The PMAs are free to accept or reject those views and look to other sources of expertise as they see fit. 

It has been suggested that the Forum take on a broader mandate, and/or act as a conduit for other experts. These suggestions are currently under consideration. And, during this period of consideration, its positions and procedures may seem a bit uncoordinated. For that, I offer my apologies. We want to get through this transition period as fast as possible, and make sure that we can be effective in whatever new role we choose.  

It is my hope and expectation that the future Forum will adopt a degree of openness well suited to its new role. 

All the best. Tim.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 28 May 2012 11:15:28 -0700

Thanks, Tim, that's good to hear. But that doesn't answer my questions from below. Can "anyone who agrees to the IPR policy can participate in CABForum"? Is the CABforum "considerably more open in its governance than IETF"?

--Paul Hoffman

---

From: Tim Moses <[email-masked]>
Date: Mon, 28 May 2012 18:42:26 +0000

Paul - I don't want to get into a comparison.  But, I can tell you that, as befits its current mandate, voting membership is limited to representatives of SSL CAs and root-program operators.  Within those groups there are no restrictions except an acceptance of the IPR policy.  All technical issues are decided by ballot amongst voting members.

The Forum has also extended observer status to experts in the auditing community, and certificate subscriber community.

We recently started distributing meeting agendas and minutes on a publicly-readable mail list.

The Forum does the bulk of its work in bi-weekly teleconferences and, as a no-fee organization, and as a matter of economics, it is not at present possible to accept more than 30 or so participants in that setting.  Commonly, participation levels are in the range 20-30.

In case anyone were so motivated, both the PKIX and Mozilla dev-sec-pol lists would be effective places to express opinions about the Forum and its work products.

As mentioned previously, this is all in a state of flux.  Ask me again at the end of the summer and I expect I will give a quite different answer.

All the best.  Tim.

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Monday, May 28, 2012 2:15 PM
To: Tim Moses
Cc: IETF PKIX
Subject: Re: [pkix] CABForum membership

--Paul Hoffman

---

From: "Ryan Sleevi" <[email-masked]>
Date: Fri, 25 May 2012 19:03:08 -0700