Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03

From: =JeffH <[email-masked]>
Date: Wed, 12 May 2010 16:23:28 -0700

> From: ArkanoiD <[email-masked]>
 >
 > It does not really answer the question, we should analyse certificates seen
 > "in the wild" ;-)
 >
 > On Wed, May 12, 2010 at 03:58:23PM -0700, Love H?rnquist ?strand wrote:
 >>
 >> 12 maj 2010 kl. 15:37 skrev Peter Saint-Andre:
 >>
 >> >> So I'm not sure right now what to say about that. I suspect we can still
 >> >> stipulate that the only RDN having attr type of CN that we'll pay
 >> >> attention to is the one at the far end of the RDN sequence comprising
 >> >> the DN.
 >> >
 >> > We can stipulate that, but is it realistic?
 >>
 >> Yes, since that's what RFC 2818 said.

in essence I'm agreed with ArkanoiD.

In particular here's what RFC 2818 sez (in section 3.1 Server Identity)..

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

..which is ambiguous because X.501 does not explicitly state which RDN in the 
DN sequence is the most specific (it's implied) and there allegedly exist 
non-trivial slices of current practice don't necessarily follow that 
stipulation anyway (for whatever reasons).

Also, we should note that the current rev of "CA/Browser Forum: Guidelines For 
The Issuance And Management Of Extended Validation Certificates (version 1.2)" 
<http://cabforum.org/Guidelines_v1_2.pdf> specifies using CN (commonName) 
containing the host domain name /or/ dNSName in subjectAlternativeName (see 
section 8.1.1(2) therein), rather than deprecating use of subject:commonName 
(in that doc's notation). that doc also doesn't specify where in the DN's RDN 
sequence an RDN of type commonName should/must be placed.

(so we have some evangelizing to do with the CABForum folk...)

=JeffH

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 12 May 2010 17:39:31 -0700

12 maj 2010 kl. 16:23 skrev =JeffH:

> ..which is ambiguous because X.501 does not explicitly state which RDN in the DN sequence is the most specific (it's implied) and there allegedly exist non-trivial slices of current practice don't necessarily follow that stipulation anyway (for whatever reasons).

rfc5280 claims that dn are hierarchical, and it make sense when you apply name constraints on the subject DN (permitted/excluded subtree).

Love

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 14 May 2010 10:48:46 +0200

> ..which is ambiguous because X.501 does not explicitly state which RDN 
> in the DN sequence is the most specific (it's implied) and there 
> allegedly exist non-trivial slices of current practice don't 
> necessarily follow that stipulation anyway (for whatever reasons).
DNs as a sequences of RDNs form a hierarchical name space similar to the 
DNS name space.
with the difference that the "labels" are not just a piece of texts but 
are structured , i.e.
SET OF of attribute/values assertions.

If one writes "a.b.c" then this is something that can be described as a 
string folling DNS name syntax,
and I could use it in whatever environment.

What is ambiguous in 2818 is that you may have a set of AVAs  with more 
than one
occurence of an AVA with common name. In theory...

Using the term 'field' is somewhat sloppy wording.

>
> Also, we should note that the current rev of "CA/Browser Forum: 
> Guidelines For The Issuance And Management Of Extended Validation 
> Certificates (version 1.2)" <http://cabforum.org/Guidelines_v1_2.pdf> 
> specifies using CN (commonName) containing the host domain name /or/ 
> dNSName in subjectAlternativeName (see section 8.1.1(2) therein), 
> rather than deprecating use of subject:commonName (in that doc's 
> notation). that doc also doesn't specify where in the DN's RDN 

Indeed. This is not surprising, if one looks at certification policies,
they are also pretty unprecise in that area.

But: what is deprecated in RFC 2818 is the fact not using
a subjectAltName:

    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.

At least, if I understand the "otherwise" correctly and apply
Boolean an IETF logic.

As soon as one adds a subjectAltName, a verifier conformant
to 2818 doesn't even look for a common name.

As a "best practice", one may say that having
exactly one common name AVA in a single value RDN with
ensures that the cert is recognized as one belonging
to the intended host.

and to have an identical value in a subjectAltName

One may add that putting it as the last element in the
sequence covers the 0.000001% of very strange things,
I'd rather say that it is not necessary for this RDN
to be the last (i.e. explicitely tell verifiers so)

> (so we have some evangelizing to do with the CABForum folk...)

Well, my hourly fee is ... negotiable :-)

I (really don't) wonder how many of the CAs in that forum allow a
certificate request with two common names...

I think it is very important that the RFC use clear wording that
is also easy to understand by non native English.

    7.  The certificate SHOULD NOT represent the server's DNS domain name
        in a Relative Distinguished Name (RDN) of type Common Name (CN)
        (see [LDAP-SCHEMA]) within the subjectName field, even though it
        is recognized that many deployed clients still check for this
        legacy identifier configuration within certificate subjectName.

I do not see any reason for this unless one adds 'only' before the
within. see above.

        However, if this legacy identifer configuration is employed, then
        the server's DNS domain name MUST be placed in the last (most
        specific) RDN within the RDN sequence making up the certificate's
        subjectName, as the order of RDNs is determined by the DER-
        encoded Name within the server's PKIX certificate.

If one takes the text without saying that subjectAltName has precedece,
I think the message is wrong.

   The subject field of a PKIX Certificate is defined as a X.501 type
    Name [PKIX] and known as a Distinguished Name (DN).  See also [X.501]
    A DN is an ordered sequence of attribute type and attribute value
    pairs (termed "attribute value assertions (AVAs)"), where the
    attributes are to be those of the subject.  Each AVA is also termed a
    "Relative Distinguished Name (RDN)".  The RDNs are ordered in the DN
    sequence from most general to most specific.

this is simply wrong.

       DistinguishedName ::= RDNSequence

       RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

       RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
           AttributeTypeAndValue

       AttributeTypeAndValue ::= SEQUENCE {
           type  AttributeType,
           value AttributeValue }

    Often such a
    DN string representation is ordered from left-to-right, most specific
    to most general.  See [LDAP-AUTH] for details.

I'd rather say that unfortunately both orderings occur and
it not always obvious to see which is used. I know about a
institude's CA that has country (C=DE) as last element
got that certified. :-)

    8.  The certificate MUST NOT represent the server's DNS domain name
        by means of a series of Domain Component (DC) attributes (because
        the order of Domain Components is not guaranteed, certain attacks
        are possible if DC attributes are included).

I think that this is also not nice wording. What is ment IMO is
that the server MUST NOT assume that whatever is put in DCs
is recognized as a domain name.

One should be careful about such words, sine it may be that
some extremely strict verifier misinterprets it. Talking about
'certain attacks' doesn't seem a useful information.

    2.  After the server provides its presented identifiers in the form
        of an PKIX certificate, the client checks each of its reference
        identifiers against the presented identifiers for the purpose of
        finding a match.

'presents its' instead of 'provides its presented'
and remove 'after'. It maybe present out of band

        The reference identifiers is matched with identifiers
        included/present/provided/electable in a PKIX certificate
        belonging to the server, i.e. by which the intended
        communication of data verification can be authenticated
        cryptograhically.

I don't really like PKIX here, one may have an X509 cert that is not
conformant to the PKIX profile.

   In addition to checking identifiers, a client MAY complete further
    checks to ensure that the server is authorized to provide the
    requested service.  However, methods for doing so (e.g., consulting
    local policy information) are out of scope for this document.

The chapter talks about Server identity verification. This paragraph
doesn't belong to this imo.

    o  The list SHOULD NOT include a CN-ID; however, the CN-ID (if
       included) MUST be constructed only from the source domain and
       never from a target domain.

       Note: A client MUST NOT construct a reference identifier
       corresponding to Relative Distinguished Names (RDNs) other than
       the Common Name and MUST NOT check for such RDNs in the presented
       identifiers.  In particular, this means that a client MUST NOT
       check a series of Domain Component (DC) attributes if included in
       the certificate (because the order of Domain Components is not
       guaranteed, certain attacks are possible if DC attributes are
       checked).

since a CN-ID is:

      CN-ID = a Relative Distinguished Name (RDN) of type Common Name
          (CN)

what is the purpose of the note?

3.4.4 seems to have a lot of redundant information and not the
same as already presented elsewhere. All text starting from
thesecond paragraph can be replaced by

    Therefore, if and only if the identity set does not include
    subjectAltName extensions of type dNSName, SRVName, or
    uniformResourceIdentifier (or any application-specific subjectAltName
    extensions), the client MAY as a fallback check cfor a CN-ID.

The examples may be put into the description of the certificate subject
structure.

3.6: There may also be the case where the server does not present a cert
at all. not the case of tls etc, but one may verify signatures of OCSP,
TSAs etc.

have fun
/PS

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 28 May 2010 16:00:53 -0600

> Using the term 'field' is somewhat sloppy wording.

We borrowed that wording from RFC 5280. Do you have a suggestion for
improvement? And, from the perspective of this proposed BCP, does it
make a material difference?

> I do not see any reason for this unless one adds 'only' before the

How about removing the words "within the subjectName field"?

> I think the message is wrong.

Does this proposed BCP say that the subjectAltName has precedence? If
that is not clear, then we need to clarify it.

>       AttributeTypeAndValue ::= SEQUENCE {

Our working copy of version -05 currently says:

   The subject field of a PKIX certificate is defined as an X.501 type
   Name and known as a Distinguished Name (DN) -- see [X.501] and
   [PKIX].  A DN is an ordered sequence of Relative Distinguished Name
   (RDNs), where an RDN is a set (i.e., an unordered group) of type-and-
   value pairs [LDAP-DN], each of which asserts some attribute about the
   subject of the certificate.  The RDNs are ordered in the DN sequence
   from most general to most specific.

>    to most general.  See [LDAP-AUTH] for details.

OK. In fact do we need to say anything about the order (specific to
general or general to specific)?

> institude's CA that has country (C=DE) as last element

So:

   ... In practice, the RDNs can be ordered in
   the DN sequence from most general to most specific or most specific
   to general, and the order cannot be relied upon.

Better?

> is recognized as a domain name.

This section is about certificate issuance, not client processing (or
server interpretation of the certificate, which so far is utterly out of
scope for this proposed BCP).

> 'certain attacks' doesn't seem a useful information.

Consider:

1. DC=com, DC=example, DC=cn

vs.

2. DC=cn, DC=example, DC=com

Clearly com.example.cn != cn.example.com, but if one interpreted DCs
then both of those DNS domain names would match #1 and #2.

We can add more text about this to the spec.

> and remove 'after'. It maybe present out of band

Sure. Changed.

> conformant to the PKIX profile.

One may, but we're not trying to cover every possible profile of X.509v3
here, only those conformant to the PKIX profile.

> doesn't belong to this imo.

It's just an implementation note. I've added some clarifying text.

> what is the purpose of the note?

The purpose of the note is to warn client developers against using DCs.

> same as already presented elsewhere. 

Repetition is not necessarily a bad thing. We assume that client
developers will read only section 3, not section 4.

> All text starting from

Maybe, but I think the repetition is useful. I'll double-check this when
I have more time.

> at all. not the case of tls etc, but one may verify signatures of OCSP,

Out of scope. We might write another spec about such use cases, but in
this case we think we're covering at least 80% of the usage.

> have fun

Always. :)

Peter

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

---

From: Peter Sylvester <[email-masked]>
Date: Sat, 29 May 2010 13:47:12 +0200

>> occurence of an AVA with common name. In theory...
The sentence starting with 'What" was the comment.

>> Using the term 'field' is somewhat sloppy wording.
There are two usages of field. There is no 'Common namefield".
> make a material difference?
There is a subsject field, but such thing as a 'Common name field'.

Using vocabulary which is undefined is not the best way to explain
best practices, i.e. to clarify usages, IMO.

>>> Certificates (version 1.2)"<http://cabforum.org/Guidelines_v1_2.pdf>
No comment here??

> How about removing the words "within the subjectName field"?
The point is not (since already said) that there is no such thing
as 'an RDN of type Common Name', there are only AVAs but:

The SHOULD NOT may be misleading for a non-native English.
It may be understood as "It is not a good idea at all to put
an attribute of type Common Name in any RDN since it can be
misunderstood as the server's name independantly of what
is put in the subjectAltname extension."   'represent' is ambiguous
here.

exampe, you a Common Name attribute containing the server's name
and if the cert has a subjectAltName, have I 'represented' the
server's name in the Common Name or not? I have put it in,
I don't expect that someone verifies it there, but still, I have
can think I have represented it in two places.

> that is not clear, then we need to clarify it.
As I said, here you have room for clarification. You essentially
rewrite 2818 (the most specific) without clarifying the
amiguity of multiple AVAs and without mentioning that
is is a BAD idea to have several attributs with type Common
Name.

"However, if this legacy identifier configuration is employed,
   in order to be surely recognizable, there SHOULD only
   be one attribute of type Common Name, and that ava
   SHOULD occur in a single element RDN."

>     from most general to most specific.
Ok.
> general or general to specific)?
The RDN order is the only thing clearly defined. What one should say
is that unfortunately there are the two orders in textual representations
multiplied by the two ways of reading them and that when tools
are displaying rdns in windows, things may be worse.

"When creating DNs, care must be taken in order to be sure that
the desired order of the RDN sequence is obtained."

>     to general, and the order cannot be relied upon.
In the DN encoding, the first element is the most significant
(for the decoding party).

The encoding party MUST be careful that the first element
is encoding receives the intended attribute.
> scope for this proposed BCP).
"Certain attacks", IMO, that's not something to be used to justify
a MUST NOT.

The point is the word "represent". As above.
> then both of those DNS domain names would match #1 and #2.
And you can have dc=cn.example.com
>> and remove 'after'. It maybe present out of band
Ok
> here, only those conformant to the PKIX profile.
fair.

> It's just an implementation note. I've added some clarifying text.
will see.
> The purpose of the note is to warn client developers against using DCs.
Hm, need to think more.
> developers will read only section 3, not section 4.
You seem to consider this as a matter of style, I don't.
We may be in violant disagreement,  I don't fight. :-)
> Maybe, but I think the repetition is useful. I'll double-check this when
Hm, if you  succeed to get more time, tell me the recipe. :-)
> this case we think we're covering at least 80% of the usage.
Why out of scope? what has the interpretation of a cert to do with
the way it is detected/communicated?

regards
Peter

---

From: Peter Sylvester <[email-masked]>
Date: Sat, 29 May 2010 19:46:56 +0200

some more details.

In 1.1:

There is the possibility to indicate several identities:

"Only a match between the client's reference identity and the server's
presented identity enables the client to be sure that the certificate
can legitimately be used to secure the connection."
==>
"In general, a match between the client's reference identity and one of the server's
presented identities is required to enable the client to be sure that the certificate
can legitimately be used to authenticate the connection."

(see: "The application server is identified by a name or names carried in
    the subject field and/or the subjectAltName extension of the
    certificate.")

"The Internet Public Key Infrastructure" sounds ambiguous quite right to me.
- The only thing of a PKI in question that is ever transmitted
   and visible in the Internet might be the server's certificate.
- There is no "Internet PKI"  (like the DNS).

"in the context of the Internet Public Key Infrastructure using X.509"
==>
"in the context of a Public Key Infrastructure using X.509".

    Likewise, during TLS negotiation the server presents
    its conception of the server's identity

    Application protocols have traditionally specified their own rules
    for representing and verifying server identities.

I suggest to replace "represent" by "present". (The word represent seems
to be used interchangeable with present in the current text). I'd prefer
even 'indicate' instead.

/PS

---

From: Martin Rex <[email-masked]>
Date: Mon, 31 May 2010 17:18:17 +0200 (MEST)

Peter Sylvester wrote:
> example, you a Common Name attribute containing the server's name

There is going to be software that will check the CN= RDName of the
certificate subject name for a match, even when subjectAltName of
type dNSName are present.  Either because they're fully backwards
compatible or because they do not check subjectAltNames at all.

While there have been few implementations checking for multiple
CN= parts, the guideline in rfc-2818 for subjectAltNames seems
to be much clearer, that there can be more than one, and more
than one needs to be checked.

The original approach to use a single certificate for several
hosts was to use a wildcard (*).  Personally, I prefer the multiple
individual hostnames to the wildcard.

Example: https://www.entrust.com  

It contains a CN=www.entrust.com and two subjectAltNames
type dNSName with the values "www.entrust.com" and "secure.entrust.com"

And a reasonable, fully backwards compatible approach to server endpoint
identification would be to check all names for a match sequentially,
and succeed when any one matches.

-Martin

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

---

From: ArkanoiD <[email-masked]>
Date: Mon, 31 May 2010 22:58:14 +0400

> compatible or because they do not check subjectAltNames at all.

Actually it should not, though i do not see any harm in behaving that
way.

> than one needs to be checked.

..and multiple CNs are likely to be an error. I'd better reject this
certificate as invalid.
> and succeed when any one matches.

But we may safely ignore CN in this case, and that's what we probably intend
to do.