Subject: rfc 3280bis

From: Peter Sylvester <[email-masked]>
Date: Mon, 14 Jan 2008 12:33:59 +0100

Hello,

to my opinion there is (at least) one small error in RFC3280 which is also
in the new version.

If the subjectAltName extension contains a DNS name, the text restricts
the values to a subject of RFC 1034. This does not allow to represent
valid DNS hostnames according to RFC 1123, example

   www.3cochons.fr

I suggest that a small addition to the paragraph that references the
preferre name syntax1034:
'and modified by chapter Host Names and Numbers of RFC 1123
 (i.e. the first character of a label may be also a digit).'

Peter Sylvester

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 14 Jan 2008 12:15:19 -0500

> (i.e. the first character of a label may be also a digit).'

I believe that Peter is correct here.  The "preferred name syntax" as 
specified by RFC 1034 does not allow a domain label to begin with a 
digit, but there are real domain names that do (e.g., www.3com.com), and 
later RFCs specify that domain labels are allowed to begin with a digit 
(see below).

I understand that it is rather late in the process to be making changes 
to 3280bis, but given that there is likely to be another draft to 
address Chris Newman's comments 
(https://datatracker.ietf.org/idtracker/draft-ietf-pkix-rfc3280bis/comment/76604) 
can this sentence be fixed?

Perhaps the sentence could be changed to read:

   The name MUST be in the "preferred name syntax," as specified by
   section 3.5 of [RFC 1034] and as modified by section 2.1 of [RFC 1123].

Dave

----------------------------------

RFC 1123 (Requirements for Internet Hosts -- Application and Support), 
section 2.1 (Host Names and Numbers):

      The syntax of a legal Internet host name was specified in RFC-952
      [DNS:4].  One aspect of host name syntax is hereby changed: the
      restriction on the first character is relaxed to allow either a
      letter or a digit.  Host software MUST support this more liberal
      syntax.

RFC 3986 (URI Generic Syntax), section 3.2.2 (Host):

   A registered name intended for lookup in the DNS uses the syntax
   defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123].
   Such a name consists of a sequence of domain labels separated by ".",
   each domain label starting and ending with an alphanumeric character
   and possibly also containing "-" characters.

RFC 4519 (LDAP: Schema for User Applications), section 2.4 ('dc'):

   The 'dc' ('domainComponent' in RFC 1274) attribute type is a string
   holding one component, a label, of a DNS domain name
   [RFC1034][RFC2181] naming a host [RFC1123].  That is, a value of this
   attribute is a string of ASCII characters adhering to the following
   ABNF [RFC4234]:

   label = (ALPHA / DIGIT) [*61(ALPHA / DIGIT / HYPHEN) (ALPHA / DIGIT)]
   ALPHA   = %x41-5A / %x61-7A     ; "A"-"Z" / "a"-"z"
   DIGIT   = %x30-39               ; "0"-"9"
   HYPHEN  = %x2D                  ; hyphen ("-")

   It is noted that the directory service will not ensure that values of
   this attribute conform to the host label restrictions [RFC1123]
   illustrated by the <label> production provided above.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Jan 2008 14:09:02 -0500

David,

Then let's make this late minute fix, and keep Sam informed.

Steve

---

From: Russ Housley <[email-masked]>
Date: Mon, 14 Jan 2008 15:52:41 -0500

This suggested wording works for me.

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 16 Jan 2008 13:46:06 +0100

And what about '*.foo.net'?  I cite from SCVP.

   If the nameCompAlgId supplied in the request is id-kp-serverAuth
   [PKIX-1 <http://tools.ietf.org/html/draft-ietf-pkix-scvp-32#ref-PKIX-1>], then GeneralNames supplied in the request MUST be a
   dNSName, and the matching rules to be used are defined in [PKIX-1 <http://tools.ietf.org/html/draft-ietf-pkix-scvp-32#ref-PKIX-1>].

   If a subjectAltName extension is present and includes one or more
   names of type dNSName, a match in any one of the set is considered
   acceptable.  If the subjectAltName extension is omitted, or does not
   include any names of type dNSName, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used.

   Names may contain the wildcard character * which is considered to
   match any single domain name component.  That is, *.a.com matches
   foo.a.com but not bar.foo.a.com.

I think that something like the three lines above should be included in 
3280bis?

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 23 Jan 2008 14:52:22 +0000

I agree to the change proposals before this one.

I would not oppose the wildcard amendment either IF it turns out to be non-controversial to include the change.
"*" is indeed used in commercial certificates today, so it definitely represents a real need.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Peter Sylvester
> Sent: den 16 januari 2008 13:46
> To: Stephen Kent
> Cc: David A. Cooper; pkix
> Subject: Re: rfc 3280bis
>
>    [PKIX-1 <http://tools.ietf.org/html/draft-ietf-pkix-scvp-32#ref-
> PKIX-1>], then GeneralNames supplied in the request MUST be a
>    dNSName, and the matching rules to be used are defined in [PKIX-1
> <http://tools.ietf.org/html/draft-ietf-pkix-scvp-32#ref-PKIX-1>].
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Jan 2008 10:30:33 -0500

At 2:52 PM +0000 1/23/08, Stefan Santesson wrote:
>I would not oppose the wildcard amendment either IF it turns out to 
>be non-controversial to include the change.

I do oppose the DNS wild card proposal.  We had extensive discussions 
about this years ago. The "*" character is not valid in a DNS name, 
and so a cert that carries a DNS name as an alt name ought not use 
this convention.

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 23 Jan 2008 15:39:35 +0000

So this proves to be controversial, as I suspected. This means I will also oppose this change in rfc3280bis.

Stefan Santesson
Senior Program Manager

> From: Stephen Kent [mailto:[email-masked]]
> Sent: den 23 januari 2008 16:31
> To: Stefan Santesson
> Cc: Peter Sylvester; David A. Cooper; pkix
> Subject: RE: rfc 3280bis
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Jan 2008 11:46:06 -0500

At 5:20 PM +0100 1/23/08, Alfredo Esposito wrote:
>If a certifcate has to bind a person/object/server/device to a 
>public key, what does a wildcard name mean?
>
>Dino Esposito

Exactly.

Wildcard DNS naming is intended to communicate the notion that the 
cert Subject is authorized to represent a range of DNS names.  I 
dislike this because it is taking DNS syntax and misusing it.  Note 
that for IP addresses, another form of alt name, we created a new 
extension in RFC 3779 to explicitly represent authorization for 
addresses and to express ranges of such addresses.  We also defined 
extensions to cert path validation to describe how to process these 
extensions in a cert path. If we want to do the same for DNS names, 
we have an example of a way to do this, rather than trying to hack 
the DNS alt name representation and NOT providing explicit semantics 
for the result.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 23 Jan 2008 11:36:59 -0500

> "*" is indeed used in commercial certificates today, so it definitely represents a real need.

First I would like to note that RFC 5055 (SCVP) is not relevant to this 
discussion.  RFC 5055 refers to the use of wildcards in the name 
specified in the request message, not the name in the target certificate.

While I am neither for nor against allowing wildcards in the dNSName 
field, it does seem like too big of a change to be making to the 
document this late in the process.  Making this change would require 
changes to several sections of the document and a number of questions 
would need to be answered before the change could be made:

1)  What would the rules be for allowing wildcard characters?  Which of 
the following would be acceptable: *.a.com, f*.com, foo.*.com, ...?

2) How should name constraints be processed when wildcard characters are 
present?  The current text states the following:

   DNS name restrictions are expressed as host.example.com.  Any DNS
   name that can be constructed by simply adding zero or more subdomains
   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.

Would a subjectAltName of *.example.com fall within the subtree of 
host.example.com?  Would it depend on whether it were a permitted or 
excluded subtree?

We would also need to change the rules for comparing DNS names in 
section 7.2, which currently states:

   When comparing DNS names for equality, conforming implementations
   MUST perform a case-insensitive exact match on the entire DNS name.

At the same time, I can understand Stefan's argument that wildcard 
characters are used in certificates today.  I did a search for the 
string "dNSName" in all of the RFCs and found several that mention the 
use of wildcard characters (relevant text is quoted below).  Several of 
the RFCs state that wildcard characters may be included in the dNSName 
field of a certificate's subjectAltName extension.  A few state that 
wildcard characters must not be considered a match, but that is not the 
same as implying that no certificates are permitted to include a 
wildcard character.  The closest (non-PKIX) RFC that comes to stating 
that the dNSName should not include a wildcard character is RFC 5018, 
which suggests that a wildcard character would only appear if the DNS 
name appeared in a common name attribute in the subject field.

It is not clear that all of these RFCs agree on how the wildcard 
character may be used.  RFC 2818 and RFC 5018 (for the common name 
attribute) explicitly allow a name of the form f*.com.  However, most of 
the RFCs say that a wildcard may only be used as the left-most DNS 
label.  Does that really mean that the wildcard may only be used in the 
left-most DNS label, in which case f*.com would be acceptable, or does 
it mean that when a wildcard character is used the left-most DNS label 
must contain nothing but the wildcard character?  If 3280bis were to 
allow wildcard characters, should the language from RFC 2818 be used or 
the more restrictive language from other RFCs?

I don't particularly like the idea that there are a number of RFCs that 
permit inclusion of wildcard characters when the PKIX profile does not, 
but I wouldn't want 3280bis to be held up waiting for this issue to be 
resolved.

Dave

----------------------------------------------------------------------------------
RFC 2818 (HTTP Over TLS), section 3.1 (Server Identity) [Note: this is 
an Informational RFC]

   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.

   Matching is performed using the matching rules specified by
   [RFC2459].  If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name, a match in any one
   of the set is considered acceptable.) Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

RFC 3501 (INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1), section 
11.1 (STARTTLS Security Considerations)

        If a subjectAltName extension of type dNSName is present in
        the certificate, it SHOULD be used as the source of the
        server's identity.

        Matching is case-insensitive.

        A "*" wildcard character MAY be used as the left-most name
        component in the certificate.  For example, *.example.com
        would match a.example.com, foo.example.com, etc. but would
        not match example.com.

RFC 4513 (Lightweight Directory Access Protocol (LDAP): Authentication 
Methods and Security Mechanisms), section 3.1.3.1 (Comparison of DNS Names)

   The '*' (ASCII 42) wildcard character is allowed in subjectAltName
   values of type dNSName, and then only as the left-most (least
   significant) DNS label in that value.  This wildcard matches any
   left-most DNS label in the server name.  That is, the subject
   *.example.com matches the server names a.example.com and
   b.example.com, but does not match example.com or a.b.example.com.

RFC 4572 (Connection-Oriented Media Transport over the Transport Layer 
Security (TLS) Protocol in the Session Description Protocol (SDP)), 
section 6.1 (Certificate Choice)

      Similarly, if the connection address for the media description is
      specified as a fully-qualified domain name, the endpoint MAY use a
      certificate with a dNSName subjectAltName matching the specified
      'c' line connection-address exactly.  (Wildcard patterns MUST NOT
      be used.)

RFC 4642 (Using Transport Layer Security (TLS) with Network News 
Transfer Protocol (NNTP)), section 5 (Security Considerations)

   -  If a subjectAltName extension of type dNSName is present in the
      certificate, it SHOULD be used as the source of the server's
      identity.

   -  Matching is case-insensitive.

   -  A "*" wildcard character MAY be used as the left-most name
      component in the certificate.  For example, *.example.com would
      match a.example.com, foo.example.com, etc., but would not match
      example.com.

RFC 4712 (Transport Mappings for Real-time Application 
Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)), 
section 2.2.1.5 (Server Identity Check)

   Matching is performed according to these rules:

   o  The client MUST use the server dnsNAME in the subjectAltName field
      to validate the server certificate presented.  The server dnsName
      MUST be part of subjectAltName of the server.

   o  Matching is case-insensitive.

   o  The "*" wildcard character is allowed.  If present, it applies
      only to the left-most name component.

      For example, *.example.com would match a.example.com,
      b.example.com, etc., but not example.com.  If more than one
      identity of a given type is present in the certificate (e.g., more
      than one dNSName name), a match in any one of the set is
      considered acceptable.

RFC 4945 (The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, 
and PKIX), section 3.1.2 (ID_FQDN)

   When comparing the contents of ID with the dNSName field in the
   SubjectAltName extension for equality, case-insensitive string
   comparison MUST be performed.  Note that case-insensitive string
   comparison works on internationalized domain names (IDNs) as
   well (See IDN [12]).  Substring, wildcard, or regular expression
   matching MUST NOT be performed for this comparison.

RFC 4954 (SMTP Service Extension for Authentication), section 14 
(Additional Requirements When Using SASL PLAIN over TLS)

        If a subjectAltName extension of type dNSName is present in the
        certificate, it SHOULD be used as the source of the server's
        identity.

        Matching is case-insensitive.

        A "*" wildcard character MAY be used as the leftmost name
        component in the certificate.  For example, *.example.com would
        match a.example.com, foo.example.com, etc., but would not match
        example.com.

RFC 5018 (Connection Establishment in the Binary Floor Control Protocol 
(BFCP)), section 5.1 (Certificate-Based Server Authentication)

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

   Matching is performed using the matching rules specified by
   [RFC3280].  If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name), a match in any
   one of the set is considered acceptable.  Names in Common Name fields
   may contain the wildcard character *, which is considered to match
   any single domain name component or component fragment (e.g., *.a.com
   matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but
   not bar.com).

---

From: Alfredo Esposito <[email-masked]>
Date: Wed, 23 Jan 2008 17:20:08 +0100

If a certifcate has to bind a person/object/server/device to a public 
key, what does a wildcard name mean?

Dino Esposito

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 23 Jan 2008 22:08:53 +0100

Certificates with wildcards are fairly widely used because they
can save you both hassles and money.

Issuer: https://www.godaddy.com/gdshop/ssl/ssl.asp?ci=8979  A major issuer of SSL certs.

That is, it does not matter what 3280bis says, this is de-facto standard
and I doubt that Microsoft intends to remove support for this in MSIE.

If an issuer creates a certificate for *.com it is a bad issuer while
*.mycompany.com is ok.  Bad issuers don't have their roots
deployed in browsers so I don't see what the problem is.  If
you have bad issuers nothing really helps.

Anders

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 23 Jan 2008 18:19:58 -0500

Can you confirm that these wildcard SSL certificates include the DNS 
name in the dNSName field of the subjectAltName extension rather than in 
a common name attribute in the subject field?  I could not find any 
wildcard certificates, but the web site implies that the common name 
attribute is used in the wildcard SSL certificates and that the 
subjectAltName extension does not include DNS names with wildcards.

Dave

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 24 Jan 2008 00:42:46 +0100

Dave,
I think you are touching another issue, SAN is not always used
( https://www.verisign.com ) and for wildcards it does not make
sense to use it either since all clients understand CN.
For multiple discrete hosts SAN is of course used.

Home-brewed wild-card certificate (which apparently
is accepted by Microsoft's CardSpace):
https://infocard.pingidentity.com/cardspace/

If your desire is outlawing wildcards in SAN I guess you have
no problem but OTOH I don't see that you got rid of *.domains
which I thought was the prime consideration.

Anders

----- Original Message ----- 
From: "David A. Cooper" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sent: Thursday, January 24, 2008 00:19
Subject: Re: Wildcard DNS. Re: rfc 3280bis

Dave

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Jan 2008 13:28:09 -0500

>you have bad issuers nothing really helps.

Putting a DNS name into the CN attribute is bad behavior.  It was one 
thing for CAs to do this when there was no SAN that could represent a 
DNS name, but that has not been the case for years. Inserting an 
invalid DNS name construct, e.g., one with an asterisk, into that 
attribute is more egregious bad behavior.

The situation you describe seems to be:

	- a CA generates a cert that contains a CN value that looks 
like a DNS name, but is syntactically NOT a DNS name

	- a provider of browser software decides to ascribe semantics 
to this CN value.

	- the browser uses this interpretation to make a security 
relevant decision on behalf of the user, e.g., when validating a cert 
for a web site

	- the syntax and semantics adopted by the CA and enforced the 
browser vendor are not consistent with the standards that describe 
certs nor their interpretation by browsers as defined by the 
cognizant IETF WGs (i.e., PKIX & TLS).

Most folks would consider this a bad outcome, as it undermines 
interoperability as promoted through the use of open standards.

The fact that you view this sort of collusion between a CA and a 
browser vendor as a legitimate way to create a (de facto) standard 
suggests that maybe you ought not waste your time in non-de facto 
standards activities, e.g., PKIX.

Steve

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 29 Jan 2008 13:48:53 +0100

maybe someone should update RFC 2818? It talks about the
subjectAltName. It deprecates common name but not wild cards. 

or should there be a note in 3280bis that it updates 2818?

---

From: Stephen Kent <[email-masked]>
Date: Tue, 29 Jan 2008 17:21:12 -0500

>   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

RFC 2818 correctly noted that use of CN to hold a DNS name was 
existing practice then, but that its use was deprecated going 
forward. That RFC is now 7.5 years old.  2818 cites "matching rules" 
from RFC 2459, but 2459 does not specify matching rules for DNS names 
augmented with a wildcard. There is only one reference to wildcard 
characters in 2459. The text says that the interpretation of such 
subject alt names is not defined in 2459, and it even fails to say 
which SANs could make use of wildcard characters. So, the reference 
to 2459 matching rules in 2818 is ambiguous when a wildcard is 
present.

RFC 3280, which superseded 2459, removed the reference to wildcard 
characters in SANs, making it clear that they were no longer 
acceptable.  3280 was published in 2002, 5.5 years ago.

I agree that 2818 should be revised, given that the reference it 
makes to the PKIX cert profile is now 2 revs (.5. years) out of date, 
and no longer valid.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 30 Jan 2008 09:41:16 -0500

RFC 2818 is not the only issue.  As I noted in an earlier message 
(http://www.imc.org/ietf-pkix/mail-archive/msg03834.html), I was able to 
find 9 RFCs that mention the use of wildcard characters, eight of which 
specifically mention using a wildcard character in the dNSName field of 
subjectAltName.  Of these, only RFC 2818 was published before RFC 3280.

It would be nice if there were not a bunch of RFCs out there that were 
inconsistent with the PKIX certificate and CRL profile with respect to 
the inclusion of wildcard characters in the dNSName field of 
subjectAltName, but I think it is too late to address this in 3280bis.  
3280bis has already been approved by the IESG and should be published 
relatively soon, once Chris Newman's editorial comments have been 
addressed 
(https://datatracker.ietf.org/idtracker/draft-ietf-pkix-rfc3280bis/comment/76604).  
The use of wildcard characters in DNS names is clearly a controversial 
topic and so we cannot expect the issue to be resolved quickly.

I believe that if there is ever agreement that the PKIX certificate and 
CRL profile should be changed in this area, then it should be done as a 
separate document that is published as an update to 3280bis.  As I noted 
in my earlier email, even if it were agreed that wildcard characters 
should be allowed, most of the 9 RFCs that I quoted seem to be more 
restrictive than RFC 2818 in how wildcard characters may be used, so it 
would take time to agree on what the PKIX profile should say about the 
permitted uses of wildcard characters.  There would also be a need to 
resolve the name constraints question:

      Would a subjectAltName of *.example.com fall within the
      subtree of host.example.com? Would it depend on whether
      host.example.com was a permitted or excluded subtree?

It does not make sense holding up 3280bis trying to address these issues 
when it is not even clear that there is consensus that the PKIX 
certificate and CRL profile should be changed.

Dave

Stephen Kent wrote:
> existing practice then, but that its use was deprecated going forward. 
> That RFC is now 7.5 years old.  2818 cites "matching rules" from RFC 
> 2459, but 2459 does not specify matching rules for DNS names augmented 
> with a wildcard. There is only one reference to wildcard characters in 
> 2459. The text says that the interpretation of such subject alt names 
> is not defined in 2459, and it even fails to say which SANs could make 
> use of wildcard characters. So, the reference to 2459 matching rules 
> in 2818 is ambiguous when a wildcard is present.
>
> I agree that 2818 should be revised, given that the reference it makes 
> to the PKIX cert profile is now 2 revs (.5. years) out of date, and no 
> longer valid.
>
> Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Jan 2008 10:31:24 -0500

David,

There is no consensus to change 3280bis, so yes, it should proceed 
towards publication as an RFC as is.

If consensus emerges on this topic in the future, I also agree that 
an addendum focusing exclusively on this issue would be the preferred 
solution.

Steve

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 30 Jan 2008 17:47:25 +0100

I fully agree, nice work anyway for looking up all the other RFCs.
> It does not make sense holding up 3280bis trying to address these 
> issues when it is not even clear that there is consensus that the PKIX