Subject: Re: [certid] CN fallback

From: Alexey Melnikov <[email-masked]>
Date: Mon, 05 Apr 2010 22:30:27 +0100

Hi Peter,

Peter Saint-Andre wrote:

>On 3/23/10 8:44 AM, Ludwig Nussel wrote:  
>
>>Hi,
>>
>>| If and only if the identity set does not include subjectAltName
>>| extensions of type dNSName, SRVName, uniformResourceIdentifier (or
>>| other application-specific subjectAltName extensions), the client MAY
>>| as a fallback check the value of the Common Name (CN)
>>
>>What about rewording that to the following?
>>
>>| If and only if the certificate does not include any subjectAltName
>>| extensions, the client MAY as a fallback check the value of the
>>| Common Name (CN)
>>
>
>I don't see a strong reason to change that text. This specification is
>about checking domain names, not IP addresses.
>
>As an aside, I must say that I'm tempted to move everything about CNs to
>a separate section,
>
That would be Ok with me.

>or to remove it entirely, because I don't think it's
>a best current practice for secure authentication.
>  
>
Personally, I don't think removing it is going to be a service to the 
community, because this is the current practice, even if it is not the 
best one.

---

From: "Scott Cantor" <[email-masked]>
Date: Mon, 5 Apr 2010 19:27:01 -0400

> community, because this is the current practice, even if it is not the

Since nothing's referencing this specification yet anyway, why not outline
what people should do, rather than what they are doing?

A previous note mentioned the fact that DNs are hierarchical paths into a
directory. This, of course, is not true; X.500 does not exist as a
global/going concern, so DNs are in fact misleading in this context. Let's
stop pretending otherwise.

-- Scott

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 06 Apr 2010 07:55:11 +0100

>what people should do, rather than what they are doing?
Personally I am hoping that updated versions of documents referenced in 
the Appendix will point to this document. Such updated protocols will 
either have a backward compatibility issue (if text about use of CN is 
removed), or will have to copy the text about use of CN. The latter kind 
of defeats the purpose of having a document that serves as a cookbook 
for TLS server identity verification in protocols.

This is not to say that I am against discouraging use of CN in 
certificates. I am against discouraging by omission.

>directory. This, of course, is not true;
>
This part is actually true, by definition of a DN.

>X.500 does not exist as a
>global/going concern, so DNs are in fact misleading in this context.
>
X.509 is using X.500 constructs such as DNs. So lack of global X.500 
infrastructure is irrelevant in this case.

As a side note: some CAs use X.500 Directories internally, so DNs 
specified in certificates they issue correspond to DNs in their Directories.

>Let's stop pretending otherwise.
>  
>

---

From: "Scott Cantor" <[email-masked]>
Date: Tue, 6 Apr 2010 10:16:24 -0400

> This part is actually true, by definition of a DN.

What DNs are supposed to be and how they're used are fairly different in
lots of systems, and the difference trips up a lot of people.

-- Scott

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Tue, 6 Apr 2010 09:18:22 -0700 (PDT)

> Since nothing's referencing this specification yet anyway, why not 
> outline what people should do, rather than what they are doing?

Because this isn't a brand new subject area.  This doc is intended (IMHO) 
to clarify (lots and lots of) existing practice and nudge it in the right 
direction, not start with a clean sheet.

> A previous note mentioned the fact that DNs are hierarchical paths into 
> a directory. This, of course, is not true; X.500 does not exist as a 

Indeed use of DNs in certs is disconnected from directory usage in 
practice.  Indeed people treat DNs as what they are syntactically, a 
sequence of attribute-value assertions (sometimes "OU=(c) XYZ Corp 2010, 
all rights reserved").  This doesn't change the fact that CAs almost 
always, in my experience, put the intended subject name in the leaf RDN of 
the Subject DN, just because doing otherwise is far less likely to work 
with deployed software.

So it seems to me the doc should say:

* Use subjectAlt in all its wonderfulness.

* Use of Subject DN is traditional and not recommended and being phased 
out, but if you do it you should put the element in a CN that is the leaf 
RDN.

People will be looking to this spec to clarify this naming mystery. 
Leaving out traditional practice because it's icky just leaves the mystery 
to be documented in alleyways instead.

  - RL "Bob"

---

From: "Scott Cantor" <[email-masked]>
Date: Tue, 6 Apr 2010 12:35:37 -0400

> direction, not start with a clean sheet.

If something "adopts" this as an approach, it then inherits all the
practices, and would need to do its own profiling to then limit the options
further. I don't see that happening as much as if the "best practice" were
already here, so the effect is to leave things pretty much as they are.

> to be documented in alleyways instead.

Precluding something doesn't necessarily mean leaving it undocumented or
unmentioned though.

-- Scott

---

From: Ludwig Nussel <[email-masked]>
Date: Fri, 9 Apr 2010 14:43:51 +0200

Peter Saint-Andre wrote:
> a separate section, or to remove it entirely, because I don't think it's
> > That would avoid having generic implementations look into the CN as
> > fallback when it doesn't make sense. iPAddress for example isn't
> > specified by the I-D (why anyways?). 
> 
> 1. Do certification authorities issue certificates to IP addresses? The
> ones I work with don't (probably because they base their certification
> decision on control over the whois data or reserved email addresses for
> a domain name).

I don't know. Think of private CA's used internally by companies.
Software that implements the I-D isn't used exclusively on the
Internet after all.

> 2. If so, is that a best current practice for secure authentication? I
> don't think so.
> 
> 3. Users don't expect to connect to "192.0.2.7", they expect to connect
> to "example.com". That, at least, is one assumption of this I-D. You are
> free to write an I-D that specifies rules for representation and
> verification of IP addresses in certificates, but that's out of scope
> for this I-D.

The problem is that someone actually implementing the identity
checks for a program will come across iPAddress sooner or later.
Generic implementations like gnutls'
gnutls_x509_crt_check_hostname() also have to deal with IP addresses
somehow.
That RFC you are drafting is such a wonderful chance to have this
clarified as well :-)

> > So a conforming implementation
> > could use the CN when looking for a hostname even if a
> > subjectAltName of type iPAddress is present.
> 
> Right. But I don't think that is consistent with your proposed text.

Confusing wording, sorry. The above cited sentence refers to the
current I-D. My proposal was meant to change that so a conforming
implentation must not fall back to CN checking if any subjectAltName
is present.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 09 Apr 2010 10:40:08 -0600

Regarding inclusion of iPAddress identifiers, Ludwig Nussel and I had
the following exchange...

>> On 3/23/10 8:44 AM, Ludwig Nussel wrote:

<snip/>

> Software that implements the I-D isn't used exclusively on the

Good point.

However, here again I'm not saying that it's bad to include or check
iPAddress in a cert, only that we're not trying to tackle *that* problem
in *this* spec.

> That RFC you are drafting is such a wonderful chance to have this

Well, since you've asked so nicely... :)

I'd like more feedback on this issue. I'm open to adding text about
iPAddress because Ludwig is probably right that certificates (e.g.,
certs issued by private CAs) sometimes include iPAddress, but on the
other hand I've never seen a public CA do that.

Peter

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

---

From: Michael Ströder <[email-masked]>
Date: Mon, 19 Apr 2010 07:20:49 +0200

> lots of systems, and the difference trips up a lot of people.

Like it or not DNs are used in X.509 certs. And therefore the DN matching
rules honoring the order of the DN components have to be applied. Period.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Mon, 19 Apr 2010 07:51:02 +0200

> other hand I've never seen a public CA do that.

I would not distinguish between whether certs are issued by a "public" or
"private" CA at all because the distinction is somewhat blurry and it won't
help deciding on whether to add something to the draft or not.

Personally I'd like to see guidance about iPAddress and the order of checking
iPAddress and dNSName (or CN) in the document.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Mon, 19 Apr 2010 07:38:12 +0200

RL 'Bob' Morgan wrote:
> out, but if you do it you should put the element in a CN that is the
> leaf RDN.

+1

Ciao, Michael.