Subject: [pkix] [Technical Errata Reported] RFC5280 (3693)

From: RFC Errata System <[email-masked]>
Date: Mon, 12 Aug 2013 05:56:39 -0700 (PDT)

The following errata report has been submitted for RFC5280,
"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5280&eid=3693

--------------------------------------
Type: Technical
Reported by: Florian Weimer <[email-masked]>

Section: 4.2.1.10

Original Text
-------------
   DNS name restrictions are expressed as host.example.com.  Any DNS
   name that can be constructed by simply adding zero or more labels to
   the left-hand side of the name satisfies the name constraint.  For
   example, www.host.example.com would satisfy the constraint but
   host1.example.com would not.

Corrected Text
--------------
[Add this to the paragraph]

   If an implementation extracts DNS names from the subject
   distinguished name, DNS name restrictions MUST be applied
   to these names as well.

Notes
-----
When used with TLS and HTTP (according to RFC 2818), section 4.2.1.10, Name Constraints, is technically a NOP that doesn't constraint the CA that has this attribute because RFC 2818 mandates processing of the common name attribute in the subject distinguished name.  Consequentially, the constraint can be bypassed by issuing a certificate without a subject alternative name.  The fix is to apply the DNS name restrictions to the relevant parts of the subject distinguished name, too, as implemented here:

https://bugzilla.mozilla.org/show_bug.cgi?id=394919

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5280 (draft-ietf-pkix-rfc3280bis-11)
--------------------------------------
Title               : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Publication Date    : May 2008
Author(s)           : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk
Category            : PROPOSED STANDARD
Source              : Public-Key Infrastructure (X.509)
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Yoav Nir <[email-masked]>
Date: Wed, 14 Aug 2013 05:30:48 +0000

Forwarding to PKIX because of too many addressees.

On Aug 14, 2013, at 8:15 AM, Yoav Nir <[email-masked]> wrote:

IMO this is not an erratum. RFC 2818 acknowledges the practice of placing the FQDN in the Common Name field, but recommends not to do it. 

Sure, the authors of RFC 5280 could have said "It is common practice, as documented in [RFC5280] to place the FQDN in the Common Name field for certificates in use for HTTPS. Because of this, DNS name constraints MUST be applied to that field as well.". Choosing not to do so may have been the right or the wrong decision, but it's not a textual or technical error.

I also don't think it's a good idea, because certificates are used in other domains than HTTPS. 

But most important, there is a bunch of certificates out there that are perfectly valid according to RFC 5280, which would become invalid based on the suggested fix in the report. If we want to do this, I think this requires an updated RFC (or at least, an updating RFC). You shouldn't prohibit valid certificates with an Errata Report.

Yoav

On Aug 12, 2013, at 3:56 PM, RFC Errata System <[email-masked]> wrote:

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Aug 2013 11:25:25 -0400

I agree with Yoav. The suggested change is not editorial; it represents 
a significant
technical change. It also does not accurately reflect the intent of the WG.

This erratum should be rejected.

Steve
------

---

From: [email-masked] (Martin Rex)
Date: Wed, 14 Aug 2013 20:09:59 +0200 (CEST)

Yoav Nir wrote:
> IMO this is not an erratum. RFC 2818 acknowledges the practice of
> placing the FQDN in the Common Name field, but recommends not to do it. 

rfc2818 goes even further:

http://tools.ietf.org/html/rfc2818#page-5

   If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity. Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used. Although
   the use of the Common Name is existing practice, it is deprecated and
   Certification Authorities are encouraged to use the dNSName instead.

There are two significant problems with the idea in this errata:

1) Name constraints processing is something that is performed entirely
   within the so called "path validation function (rfc5280 Section 6.1)
   and rfc5280 explicitly says that using an X.509 08/2005 path validation
   function as a substitute is OK.  This change will not fly with
   the latter.

2) Name constraints are only processed for an EE cert if a name of that
   type is present in the certficate.  Combined with what rfc2818 _truely_
   says, this amounts to a NO-OP.

     a) if any CA Cert on the path contains NameConstraints on
        SubjectAltNames type DNSName, but the EE-Cert contains no
        SubjectAltName of type DNSName, then these NameConstraints
        must be ignored.

     b) if any CA Cert on the path contains NameConstraints on
        SubjectAltNames of type DNSName, and the EE-Cert contains
        SubjectAltNames of type DNSName, the constraints will be
        processed, but per rfc2818 Section 3.1, the CN= part of the
        certificate must be ignored for the purpose of Server
        Endpoint identification.

So currently, this idea looks somewhat half-baked to me.

Anyone can implement any behaviour and still argue compliance.
There is nothing that the proposed change (which is _not_ an errata)
would change about the situation.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 14 Aug 2013 11:47:01 -0700

I think it is filled as a technical not an editorial erratum. And I also
think that this should be editorial :).

The intent is clearly stated in 4.2.1.10 paragraph 4.

"If a name constraints extension that is marked as critical imposes
constraints on a particular name form, and an instance of  that name form
appears in the subject field or subjectAltName extension of a subsequent
certificate, then the application MUST  either process the constraint or
reject the certificate."

So the fact that the DNS name was extracted from subjectName as opposed to
subjectAltName is irrelevant. The constraint must be applied in either case.

The proposed text clarifies this. Whether it is redundant is a different
question altogether.
Explicit  clarification is provided for RFC822Name. So I do not see a reason
for not providing the same for DNS names.

-Piyush

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stephen Kent
> Sent: Wednesday, August 14, 2013 8:25 AM
> To: RFC Errata System
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693)
> 
> I agree with Yoav. The suggested change is not editorial; it represents a
> significant technical change. It also does not accurately reflect the
intent of
> the WG.
> > The following errata report has been submitted for RFC5280, "Internet
> > X.509 Public Key Infrastructure Certificate and Certificate Revocation
List
> (CRL) Profile".
> > When used with TLS and HTTP (according to RFC 2818), section 4.2.1.10,
> Name Constraints, is technically a NOP that doesn't constraint the CA that
has
> this attribute because RFC 2818 mandates processing of the common name
> attribute in the subject distinguished name.  Consequentially, the
constraint
> can be bypassed by issuing a certificate without a subject alternative
name.
> The fix is to apply the DNS name restrictions to the relevant parts of the
> subject distinguished name, too, as implemented here:
> >
> >
> >
> > use "Reply All" to discuss whether it should be verified or rejected.
> > When a decision is reached, the verifying party (IESG) can log in to
> > change the status and edit the report, if necessary.
> >
> > Title               : Internet X.509 Public Key Infrastructure
Certificate and
> Certificate Revocation List (CRL) Profile
> > Author(s)           : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R.
Housley,
> W. Polk

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 14 Aug 2013 12:07:35 -0700

> Sure, the authors of RFC 5280 could have said "It is common practice, as
> documented in [RFC5280] to place the FQDN in the Common Name field for
> certificates in use for HTTPS. Because of this, DNS name constraints MUST
be
> applied to that field as well.". Choosing not to do so may have been the
right
> or the wrong decision, but it's not a textual or technical error.

>From 5280:
"Restrictions apply to the subject distinguished name and apply to  subject
alternative names."
I would interpret that this applies to all name types.

> I also don't think it's a good idea, because certificates are used in
other
> domains than HTTPS.
> 
> But most important, there is a bunch of certificates out there that are
> perfectly valid according to RFC 5280, which would become invalid based on
> the suggested fix in the report. If we want to do this, I think this
requires an
> updated RFC (or at least, an updating RFC). You shouldn't prohibit valid
> certificates with an Errata Report.

Not sure of the existence of the certificates that you refer to. Why would a
genuine sub CA issue a certificate with a DNS name that it is not authorized
to issue?

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Aug 2013 16:43:07 -0400

Piyush,
> subjectAltName is irrelevant. The constraint must be applied in either case.
I disagree. The source of the identifier is relevant. The first paragraph of
4.2.1.10 ends with these 2 sentences:

Restrictions apply only when thespecified name form is present.
If no name of the type is in thecertificate, the certificate is
    acceptable.

When a DNS name appears in the Subject name, not the subject alt name 
extension, it
it not typed as a DNS name. It is an attribute of a Subject DN, often a
CN attribute. If it were expressed as a series of domainComponent 
attributes,
then I might agree that it was typed as a DNS name, but that does not 
tend to happen
in practice. Also, pages 21-22 note that use of the domainComponent 
attribute is
not a substitute for using a dNSName in the Subject alt name extension, 
and that
there is NO requirement for an implementation to convert a sequence of 
DCs into
a DNS name. But such a conversion is what would be needed to perform the 
name
constraints comparison, so ...

Note further that, on pages 41-42, an explicit exception is made for 
rfcC822 names that
are encoded in a DN as an attribute type of emailAddress. If the intent 
was to create the same exception for DNS names appearing in the Subject 
field, it would appear in this section. It does not. So there seems to 
be no basis for assuming that the treatment
of a DNS name that appears in the Subject name field using some 
attribute(s) is an
oversight.

Steve

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 14 Aug 2013 15:20:50 -0700

Stephan,

Your explanation below convinces me that 5280 does not require relying
parties to apply name constraint on DNS names extracted from the CN.

However, I still think that it was an oversight and not a conscious
decision. At that time this WG did not take into account the common practice
of using CN for DNS name in server certificates. I did not find any
discussions in the pkix archive which indicate that WG discussed the
applicability of NC on DNS name embedded in CN and consciously decided to
leave any excpetions for DNS name out of the text.

The purpose of NC extension is to allow a CA to constraint the sub CA.
Current RFC 5280 text allows sub CAs to bypass any constraint on the DNS
name by issuing a certificate without the altName. Won't you agree that it
defeats the purpose of having a NC extension.

This issue was raised last year as well by Santosh without any conclusion.
http://www.ietf.org/mail-archive/web/pkix/current/msg30897.html.

BTW,  it seems that both Mozilla and chrome apply DNS name constraints to
DNS name extracted from CN.

-Piyush

From: Stephen Kent [mailto:[email-masked]] 
Sent: Wednesday, August 14, 2013 1:43 PM
To: Piyush Jain
Cc: 'RFC Errata System'; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693)

Piyush,

 

   Restrictions apply only when the specified name form is present.
   If no name of the type is in the certificate, the certificate is
   acceptable.

When a DNS name appears in the Subject name, not the subject alt name
extension, it
it not typed as a DNS name. It is an attribute of a Subject DN, often a
CN attribute. If it were expressed as a series of domainComponent
attributes,
then I might agree that it was typed as a DNS name, but that does not tend
to happen 
in practice. Also, pages 21-22 note that use of the domainComponent
attribute is 
not a substitute for using a dNSName in the Subject alt name extension, and
that
there is NO requirement for an implementation to convert a sequence of DCs
into
a DNS name. But such a conversion is what would be needed to perform the
name 
constraints comparison, so ...

Note further that, on pages 41-42, an explicit exception is made for rfcC822
names that
are encoded in a DN as an attribute type of emailAddress. If the intent was
to create the same exception for DNS names appearing in the Subject field,
it would appear in this section. It does not. So there seems to be no basis
for assuming that the treatment 
of a DNS name that appears in the Subject name field using some attribute(s)
is an
oversight.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 15 Aug 2013 13:46:20 -0400

Piyush,

> decision.
I have chaired the WG since it's inception, 16 years ago. My 
recollection is that you began participating on this list relatively 
recently. So, I think my perception of what
was the intent of the WG, vs. what was an oversight, has a better 
foundation.
>
> At that time this WG did not take into account the common practice of 
> using CN for DNS name in server certificates. I did not find any 
> applicability of NC on DNS name embedded in CN and consciously decided 
> to leave any excpetions for DNS name out of the text.
>
We knew it was common practice, and we wanted to discourage it, not 
endorse it.
> Current RFC 5280 text allows sub CAs to bypass any constraint on the 
> DNS name by issuing a certificate without the altName. Won't you agree 
> that it defeats the purpose of having a NC extension.
>
The normal operation of public TAs for 20 years has avoided use of NC, 
probably because use of this extension might diminish revenue 
opportunities. Only recently have  some of these CAs decided that NC 
might be a good idea, and only if it were NOT marked
critical (because f a vendor support issue). Frankly, if we're binding 
DNS names to public keys, DANE is the best approach.
> BTW, it seems that both Mozilla and chrome apply DNS name constraints 
> to DNS name extracted from CN.
>
>
I am not aware of what additional tests these browsers might impose.

Steve

---

From: Tom Gindin <[email-masked]>
Date: Fri, 16 Aug 2013 21:50:46 -0400

The statement "is technically a NOP" in this erratum is wrong, 
since the name constraint does restrict most uses of DNS name in a 
certificate.  An accurate description of this complaint would be "does not 
effectively constrain all DNS Names used by RFC 2818".  The complaint 
appears to assume that all CN attribute values should be constrained in 
this way.  However, many (and perhaps most) CN attribute values don't have 
DNS names in them.  RFC 5280 section 4.2.1.6 already requires that the 
subjectAltName field be populated when a DNS name is used ("Whenever such 
identities are to be bound into a
 certificate, the subject alternative name (or issuer alternative
 name) extension MUST be used"), and RFC 2818 section 3.1 gives SAN 
preference over CN when both are present.  For that matter, RFC 2459 
4.2.1.7 had the same requirement as 5280 14 years ago.
        Changes along these lines are particularly inappropriate for RFC 
5280 because it isn't clear how one can reliably determine whether a CN 
contains a DNS name or not.  The heuristic about having periods but no 
spaces really isn't robust enough for inclusion in a standard.  Since 2818 
does NOT restrict its scope to certificates using the appropriate key 
purposes, 5280's algorithm could not be effectively modified even if this 
group were willing to include something like "if Extended Key Usage 
contains server-auth and the SubjectAlternativeName extension is missing".
        Something that would produce the effect that the author appears to 
want might be that a TLS client implementation SHOULD perform name 
constraint verification before carrying out the check on the CN in RFC 
2818 section 3.1 (2nd sentence of 3rd paragraph).  However, that's a 
change rather than an erratum, and it's specific to RFC 2818 and would be 
a new subsection of a successor to that RFC.  In any case, it would NOT 
apply to RFC 2459/3280/5280-compliant certificates, because that check on 
the CN never occurs for them.
        The current algorithm in section 6 couldn't be simply modified for 
this purpose anyway, since the subtree checks occur for each element in 
the tree and the CN check doesn't apply to intermediate certificates. 

Tom Gindin

From:   "Piyush Jain" <[email-masked]>
To:     "'Stephen Kent'" <[email-masked]>, 
Cc:     [email-masked], [email-masked], [email-masked], 
[email-masked], "'RFC Errata System'" <[email-masked]>
Date:   08/14/2013 06:21 PM
Subject:        Re: [pkix] [Technical Errata Reported] RFC5280 (3693)
Sent by:        [email-masked]

Stephan,
 
Your explanation below convinces me that 5280 does not require relying 
parties to apply name constraint on DNS names extracted from the CN.
However, I still think that it was an oversight and not a conscious 
decision. At that time this WG did not take into account the common 
practice of using CN for DNS name in server certificates. I did not find 
any discussions in the pkix archive which indicate that WG discussed the 
applicability of NC on DNS name embedded in CN and consciously decided to 
leave any excpetions for DNS name out of the text.
 
The purpose of NC extension is to allow a CA to constraint the sub CA. 
Current RFC 5280 text allows sub CAs to bypass any constraint on the DNS 
name by issuing a certificate without the altName. Won?t you agree that it 
defeats the purpose of having a NC extension.

 
-Piyush

Piyush,

 
 
So the fact that the DNS name was extracted from subjectName as opposed to
subjectAltName is irrelevant. The constraint must be applied in either 
case.
I disagree. The source of the identifier is relevant. The first paragraph 
of
4.2.1.10 ends with these 2 sentences:

Note further that, on pages 41-42, an explicit exception is made for 
rfcC822 names that
are encoded in a DN as an attribute type of emailAddress. If the intent 
was to create the same exception for DNS names appearing in the Subject 
field, it would appear in this section. It does not. So there seems to be 
no basis for assuming that the treatment 
of a DNS name that appears in the Subject name field using some 
attribute(s) is an
oversight.

Steve_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 16 Aug 2013 21:46:27 -0700

Agreed.

Such checks cannot be performed by the basic path validator as defined by
the RFC 5280. 

This check, however should be performed by a TLS client if it extracts DNS
name from CN. So it belongs in the TLS specification. 

-Piyush

From: Tom Gindin [mailto:[email-masked]] 
Sent: Friday, August 16, 2013 6:51 PM
To: Piyush Jain
Cc: [email-masked]; 'Stephen Kent'; [email-masked]; 'RFC Errata System';
[email-masked]; [email-masked]
Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693)

        The statement "is technically a NOP" in this erratum is wrong, since
the name constraint does restrict most uses of DNS name in a certificate.
An accurate description of this complaint would be "does not effectively
constrain all DNS Names used by RFC 2818".  The complaint appears to assume
that all CN attribute values should be constrained in this way.  However,
many (and perhaps most) CN attribute values don't have DNS names in them.
RFC 5280 section 4.2.1.6 already requires that the subjectAltName field be
populated when a DNS name is used ("Whenever such identities are to be bound
into a certificate, the subject alternative name (or issuer alternative
name) extension MUST be used"), and RFC 2818 section 3.1 gives SAN
preference over CN when both are present.  For that matter, RFC 2459 4.2.1.7
had the same requirement as 5280 14 years ago. 
        Changes along these lines are particularly inappropriate for RFC
5280 because it isn't clear how one can reliably determine whether a CN
contains a DNS name or not.  The heuristic about having periods but no
spaces really isn't robust enough for inclusion in a standard.  Since 2818
does NOT restrict its scope to certificates using the appropriate key
purposes, 5280's algorithm could not be effectively modified even if this
group were willing to include something like "if Extended Key Usage contains
server-auth and the SubjectAlternativeName extension is missing". 
        Something that would produce the effect that the author appears to
want might be that a TLS client implementation SHOULD perform name
constraint verification before carrying out the check on the CN in RFC 2818
section 3.1 (2nd sentence of 3rd paragraph).  However, that's a change
rather than an erratum, and it's specific to RFC 2818 and would be a new
subsection of a successor to that RFC.  In any case, it would NOT apply to
RFC 2459/3280/5280-compliant certificates, because that check on the CN
never occurs for them. 
        The current algorithm in section 6 couldn't be simply modified for
this purpose anyway, since the subtree checks occur for each element in the
tree and the CN check doesn't apply to intermediate certificates.   

Tom Gindin

  _____  

Stephan, 

  
This issue was raised last year as well by Santosh without any conclusion.
<http://www.ietf.org/mail-archive/web/pkix/current/msg30897.html>
http://www.ietf.org/mail-archive/web/pkix/current/msg30897.html. 

-Piyush 
  
From: Stephen Kent [ <mailto:[email-masked]> mailto:[email-masked]] 
  
Piyush,

  

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

---

From: Tom Gindin <[email-masked]>
Date: Tue, 20 Aug 2013 21:53:58 -0400

Piyush, TLS doesn't specify the matching rules between requested 
server names and certificates, HTTPS (RFC 2818) does.  That has the 
somewhat odd result that LDAPS' only matching rules for this purpose are 
those it inherits from HTTPS.  Perhaps those rules should be split out of 
2818 and be added to TLS, but they haven't yet been.
        Since this can't ever apply to a 5280-compliant cert, shouldn't it 
go to a different place if not rejected - either 2818 or a successor which 
is part of the TLS set?

                 Tom Gindin

From:   "Piyush Jain" <[email-masked]>
To:     Tom Gindin/Watson/IBM@IBMUS, 
Cc:     <[email-masked]>, "'Stephen Kent'" <[email-masked]>, 
<[email-masked]>, "'RFC Errata System'" <[email-masked]>, 
<[email-masked]>, <[email-masked]>
Date:   08/17/2013 12:46 AM
Subject:        RE: [pkix] [Technical Errata Reported] RFC5280 (3693)

Agreed.

-Piyush

From: Tom Gindin [mailto:[email-masked]] 
Sent: Friday, August 16, 2013 6:51 PM
To: Piyush Jain
Cc: [email-masked]; 'Stephen Kent'; [email-masked]; 'RFC Errata 
System'; [email-masked]; [email-masked]
Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693)
 
identities are to be bound into a certificate, the subject alternative 
name (or issuer alternative name) extension MUST be used"), and RFC 2818 
section 3.1 gives SAN preference over CN when both are present.  For that 
matter, RFC 2459 4.2.1.7 had the same requirement as 5280 14 years ago. 

Tom Gindin

Stephan, 

  

-Piyush 

Piyush,

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Aug 2013 20:02:13 -0600

On 8/20/13 7:53 PM, Tom Gindin wrote:
> server names and certificates, HTTPS (RFC 2818) does.

Please see RFC 6125, too.

> That has the somewhat odd result that LDAPS' only matching rules
> for this purpose are those it inherits from HTTPS.

Actually, the rules for LDAP are specified in RFC 4513 (which
superseded the rules from RFC 2830).

> Perhaps those rules should be split out of 2818 and be added to
> TLS, but they haven't yet been.

The rules for each application protocol are still defined in the
relevant specifications for those protocols. In RFC 6125 we attempted
to generalize the rules, but RFC 6125 does not supersede the rules
that are already defined for each application protocol (until and
unless each protocol decides to use a profile of RFC 6125).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 20 Aug 2013 19:31:54 -0700

Thanks for providing the references Peter.

So a quick look at 4513 and 6125 indicates that the issue raised by this
erratum is not addressed anywhere and any application protocol designed over
TLS is vulnerable if client implementations extract DNS name from
certificate CN.

I guess the place to have this discussion is TLS WG.

-Piyush

> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Tuesday, August 20, 2013 7:02 PM
> To: Tom Gindin
> Cc: Piyush Jain; [email-masked]; [email-masked]; [email-masked];
> 'RFC Errata System'
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > That has the somewhat odd result that LDAPS' only matching rules for
> > this purpose are those it inherits from HTTPS.
> 
> Actually, the rules for LDAP are specified in RFC 4513 (which superseded
the
> rules from RFC 2830).
> 
> > Perhaps those rules should be split out of 2818 and be added to TLS,
> > but they haven't yet been.
> 
> The rules for each application protocol are still defined in the relevant
> specifications for those protocols. In RFC 6125 we attempted to generalize
> the rules, but RFC 6125 does not supersede the rules that are already
> defined for each application protocol (until and unless each protocol
decides
> to use a profile of RFC 6125).
> 
> Peter
> 
> - --
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJSFB+lAAoJEOoGpJErxa2pBaoP/RwpMJnAjKL2eyi7huvLLKjo
> SeQEYwXONyg3Fa6w5mUeptPDxd+G9eShy2c/M83GdAzQ8uoxC1Wjm7BFPx
> u+p5e5
> 2x7t7Paa0J9s3uXh7Tn7IdILw3BI0akwH6CfeHMx0u1b2Pbfh1doe9tmeMBrc54
> Q
> ay5UygDrfMuG5Ti35zColmrhHA/1f+l1Y/cfymiDWylbuaY+DZMms+FE06cE4yn
> W
> YXTZluPmCN3aJAtWxXcjAYGDd0R0sgE8S99H8idUtSGVV5OVN/W76BOlcJ+f3Z
> /1
> ltxhQ7qS/wIfnjUxsKGH8BTZISQ0cpPjf07F/R9nJI/ZgZ1aJPOA5nI8L7MTRgiC
> lpBSlK5YMca+qk4fDOh/QvOtjKkDild4aTtRkoJYR0SgyGpXpm4Vlptbpcz/rmH7
> Cnlbvq+V5Fj5RsoiybBpmyXVhSDo57XO8fNiORl7ffG26FtFYHJOCET3RdDSjyRK
> Q7dyBxQM68zPe6GWJLOjc949UMXUvpujIIRnOG4wUHxNji/736YxnxoG/atrG
> OJ+
> peiG2J00rcCJHhMB2s0PcocA2F+g/wLRoilK8eoWmMtHgT+7DMrg9VIMJqr6hf
> M5
> dEpzdV944vfZr96VI5KnRT6tG15+/ZYhab+DYVOnmYrmISXDMB40s0jnukNhrJ5
> i
> NfQ10n0XfgpXalVDOVkK
> =rgRN
> -----END PGP SIGNATURE-----

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Aug 2013 21:05:39 -0600

> Thanks for providing the references Peter.

You're welcome.

(BTW, would you be so kind as to please refrain from top-posting? It
makes the discussion hard to follow.)

> So a quick look at 4513 and 6125 indicates that the issue raised by
> this erratum is not addressed anywhere and any application protocol
> designed over TLS is vulnerable if client implementations extract
> DNS name from certificate CN.

As Steve Kent noted, we're actively trying to discourage that
behavior. In RFC 6125 we tried hard to lobby for an end to checking
the CN, but we weren't able to reach consensus on that within the CA,
browser, security, and application communities. I sure hope we can get
there in 6125bis.

(However, name constraints are explicitly out of scope for RFC 6125.)

> I guess the place to have this discussion is TLS WG.

I tend to agree.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/