headers
Peter Saint-Andre | 4 Jun 00:34
Favicon

[Fwd: I-D Action:draft-saintandre-tls-server-id-check-00.txt]


FYI. All I did was update the references, change the title slightly, and
update the authors. Feedback is welcome before we publish a version with
more significant modifications.

Peter

-------- Original Message --------
Subject: I-D Action:draft-saintandre-tls-server-id-check-00.txt
Date: Wed,  3 Jun 2009 15:30:02 -0700 (PDT)
From: Internet-Drafts <at> ietf.org
Reply-To: internet-drafts <at> ietf.org
To: i-d-announce <at> ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Best Practices for Checking of Server Identities in
the Context of Transport Layer Security (TLS)
	Author(s)       : P. Saint-Andre, et al.
	Filename        : draft-saintandre-tls-server-id-check-00.txt
	Pages           : 7
	Date            : 2009-06-03

This document specifies the how an entity establishing a TLS
connection, or other PKI-based interaction, with a server should
verify the server identity.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-00.txt
(Continue reading)

Permalink | Reply |
headers
Paul Hoffman | 4 Jun 16:24
Picon

Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

Greetings again. I would like to argue that, from a security perspective, we should not allow looking up DNS
names in the subjecName in PKIX certificates in this document. Section 3.1 says:
   The server's identity may also be verified by comparing the reference
   identity to the Common Name (CN) [LDAP-SCHEMA] value in the leaf
   Relative Distinguished Name (RDN) of the subjectName field of the
   server's certificate.  This comparison is performed using the rules
   for comparison of DNS names in Section 3.1.3.1, below, with the
   exception that no wildcard matching is allowed.  Although the use of
   the Common Name value is existing practice, it is deprecated, and
   Certification Authorities are encouraged to provide subjectAltName
   values instead.  Note that the TLS implementation may represent DNs
   in certificates according to X.500 or other conventions.  For
   example, some X.500 implementations order the RDNs in a DN using a
   left-to-right (most significant to least significant) convention
   instead of LDAP's right-to-left convention.

That ambiguity leads to a fairly trivial identity attack. There is no good reason for a CA to issue
certificates with domain names in the subjectName, and lots of reasons for it not to. This document should
prohibit checking domain names in the subjectName, and should say why.
Permalink | Reply |
headers
Alexey Melnikov | 6 Jun 00:42
Favicon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

Hi Paul,

Paul Hoffman wrote:

>Greetings again. I would like to argue that, from a security perspective, we should not allow looking up
DNS names in the subjectName in PKIX certificates in this document. Section 3.1 says:
>   The server's identity may also be verified by comparing the reference
>   identity to the Common Name (CN) [LDAP-SCHEMA] value in the leaf
>   Relative Distinguished Name (RDN) of the subjectName field of the
>   server's certificate.  This comparison is performed using the rules
>   for comparison of DNS names in Section 3.1.3.1, below, with the
>   exception that no wildcard matching is allowed.  Although the use of
>   the Common Name value is existing practice, it is deprecated, and
>   Certification Authorities are encouraged to provide subjectAltName
>   values instead.  Note that the TLS implementation may represent DNs
>   in certificates according to X.500 or other conventions.  For
>   example, some X.500 implementations order the RDNs in a DN using a
>   left-to-right (most significant to least significant) convention
>   instead of LDAP's right-to-left convention.
>
>That ambiguity leads to a fairly trivial identity attack.
>
Can you elaborate on this? (A pointer to discussion elsewhere would be 
fine as well.)

>There is no good reason for a CA to issue certificates with domain names in the subjectName, and lots of
reasons for it not to.
>
I think the current reality is that many of CAs still do that without 
supporting DNS name in the subjectAltName.
(Continue reading)

Permalink | Reply |
headers
John C Klensin | 7 Jun 20:27

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

Alexey,

I'll let Paul supply the references and details (although I'd be
happy to collaborate with him if needed and if neither of you
are in a hurry), but, fwiw, I basically agree with his reasoning
as expressed in this and other notes.  We've created
flexibilities that can, with the help (intentional or otherwise)
of top-level and root registries, render the names ambiguous and
hence subject to attack.  With the apparent ICANN intention of
treating the root zone strictly as a market-driven activity and
to exercise little or no control over the behavior of TLD
registries, the opportunity to have (to take an entirely
fanciful example) com.berlin as well as berlin.com appears to be
just a matter of time and revenue stream to ICANN... with no
processes in place to require that they be under the same
control.  

An alternative to Paul's proposal to simply deprecate domain
names in this context would be to require that they all be
explicitly root-anchored, i.e., that "com.berlin" would be
invalid, but "com.berlin." would be permitted.  But my suspicion
is that convention would be neither honored nor effective,
especially since that convention has no obvious X.500 DN
equivalent.

    john

--On Friday, June 05, 2009 23:42 +0100 Alexey Melnikov
<alexey.melnikov <at> isode.com> wrote:
(Continue reading)

Permalink | Reply |
headers
Alexey Melnikov | 7 Jun 21:32
Favicon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

John C Klensin wrote:

>Alexey,
>
>I'll let Paul supply the references and details (although I'd be
>happy to collaborate with him if needed and if neither of you
>are in a hurry), but, fwiw, I basically agree with his reasoning
>as expressed in this and other notes.  We've created
>flexibilities that can, with the help (intentional or otherwise)
>of top-level and root registries, render the names ambiguous and
>hence subject to attack.  With the apparent ICANN intention of
>treating the root zone strictly as a market-driven activity and
>to exercise little or no control over the behavior of TLD
>registries, the opportunity to have (to take an entirely
>fanciful example) com.berlin as well as berlin.com appears to be
>just a matter of time and revenue stream to ICANN... with no
>processes in place to require that they be under the same
>control.
>  
>
Right.

>An alternative to Paul's proposal to simply deprecate domain
>names in this context would be to require that they all be
>explicitly root-anchored, i.e., that "com.berlin" would be
>invalid, but "com.berlin." would be permitted.  But my suspicion
>is that convention would be neither honored nor effective,
>especially since that convention has no obvious X.500 DN
>equivalent.
>
(Continue reading)

Permalink | Reply |
headers
Paul Hoffman | 6 Jun 16:51
Picon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

At 11:42 PM +0100 6/5/09, Alexey Melnikov wrote:
>Hi Paul,
>
>Paul Hoffman wrote:
>
>>Greetings again. I would like to argue that, from a security perspective, we should not allow looking up
DNS names in the subjectName in PKIX certificates in this document. Section 3.1 says:
>>  The server's identity may also be verified by comparing the reference
>>  identity to the Common Name (CN) [LDAP-SCHEMA] value in the leaf
>>  Relative Distinguished Name (RDN) of the subjectName field of the
>>  server's certificate.  This comparison is performed using the rules
>>  for comparison of DNS names in Section 3.1.3.1, below, with the
>>  exception that no wildcard matching is allowed.  Although the use of
>>  the Common Name value is existing practice, it is deprecated, and
>>  Certification Authorities are encouraged to provide subjectAltName
>>  values instead.  Note that the TLS implementation may represent DNs
>>  in certificates according to X.500 or other conventions.  For
>>  example, some X.500 implementations order the RDNs in a DN using a
>>  left-to-right (most significant to least significant) convention
>>  instead of LDAP's right-to-left convention.
>>
>>That ambiguity leads to a fairly trivial identity attack.
>>
>Can you elaborate on this? (A pointer to discussion elsewhere would be fine as well.)

If there is a TLD that has the same name as the SLD that you want to attack, you can get a certificate that uses
the CNs. For example, if you want to attack ar.com, you could register com.ar, get a certificate for it, and
use it to fool systems that follow the rule in the last sentence above. This attack will get easier as more
TLDs with names that exist as current SLDs are created in the coming years.
(Continue reading)

Permalink | Reply |
headers
Peter Saint-Andre | 28 Aug 01:35
Favicon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check


Sorry about the very delayed reply. I'm finally revising the I-D so I
might be posting additional messages in some old threads...

On 6/6/09 8:51 AM, Paul Hoffman wrote:
> At 11:42 PM +0100 6/5/09, Alexey Melnikov wrote:
>> Hi Paul,
>> 
>> Paul Hoffman wrote:
>> 
>>> Greetings again. I would like to argue that, from a security
>>> perspective, we should not allow looking up DNS names in the
>>> subjectName in PKIX certificates in this document. Section 3.1
>>> says: The server's identity may also be verified by comparing the
>>> reference identity to the Common Name (CN) [LDAP-SCHEMA] value in
>>> the leaf Relative Distinguished Name (RDN) of the subjectName
>>> field of the server's certificate.  This comparison is performed
>>> using the rules for comparison of DNS names in Section 3.1.3.1,
>>> below, with the exception that no wildcard matching is allowed.
>>> Although the use of the Common Name value is existing practice,
>>> it is deprecated, and Certification Authorities are encouraged to
>>> provide subjectAltName values instead.  Note that the TLS
>>> implementation may represent DNs in certificates according to
>>> X.500 or other conventions.  For example, some X.500
>>> implementations order the RDNs in a DN using a left-to-right
>>> (most significant to least significant) convention instead of
>>> LDAP's right-to-left convention.
>>> 
>>> That ambiguity leads to a fairly trivial identity attack.
>>>
(Continue reading)

Permalink | Reply |
headers
Paul Hoffman | 28 Aug 02:34
Picon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

At 5:35 PM -0600 8/27/09, Peter Saint-Andre wrote:
>Paul, I agree that this document needs to codify secure authentication
>practices. However, that raises a more general issue: shall this
>document specify rules only for certificate validation or also for
>certificate generation?

Validation only.

>My understanding of the scope that Kurt and I
>inherited from JeffH and RL Bob is that the document specifies rules
>only for validation, and even there only for a particular subset of
>validation, namely matching of the server's presented identities against
>the client's expected "reference identity" (e.g., not necessarily
>mentioning anything about the fact that the certificate needs to be
>certified by a chain of certificates terminating in a trust anchor).

Correct. You might toss in a paragraph saying "of course, you need to do full PKIX checking as well, details
are in 5280", but I don't think you even need that.

>Personally I think that it would be helpful to specify rules about both
>generation and validation (and about how the client should proceed if
>validation in the broadest sense fails), but before expanding the scope
>of the document I'd like to make sure that people here are comfortable
>with doing so.

It would be useful to say what to do when validation fails; you simply don't have to list all the PKIXy ways it
can fail.
Permalink | Reply |
headers
Alexey Melnikov | 28 Aug 22:55
Favicon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

Paul Hoffman wrote:

>At 5:35 PM -0600 8/27/09, Peter Saint-Andre wrote:
>  
>
>>Paul, I agree that this document needs to codify secure authentication
>>practices. However, that raises a more general issue: shall this
>>document specify rules only for certificate validation or also for
>>certificate generation?
>>
>
>Validation only.
>  
>
I tend to agree. But generation has to match validation, so I don't see 
much practical difference. Unless I am missing some subtle point...

>>My understanding of the scope that Kurt and I
>>inherited from JeffH and RL Bob is that the document specifies rules
>>only for validation, and even there only for a particular subset of
>>validation, namely matching of the server's presented identities against
>>the client's expected "reference identity" (e.g., not necessarily
>>mentioning anything about the fact that the certificate needs to be
>>certified by a chain of certificates terminating in a trust anchor).    
>>
>
>Correct. You might toss in a paragraph saying "of course, you need to do full PKIX checking as well, details
are in 5280",
>
Agreed.
(Continue reading)

Permalink | Reply |
headers
Paul Hoffman | 28 Aug 23:10
Picon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

At 9:55 PM +0100 8/28/09, Alexey Melnikov wrote:
>Paul Hoffman wrote:
>
>>At 5:35 PM -0600 8/27/09, Peter Saint-Andre wrote:
>> 
>>
>>>Paul, I agree that this document needs to codify secure authentication
>>>practices. However, that raises a more general issue: shall this
>>>document specify rules only for certificate validation or also for
>>>certificate generation?
>>>
>>
>>Validation only.
>> 
>>
>I tend to agree. But generation has to match validation, so I don't see much practical difference. Unless I
am missing some subtle point...

Not subtle at all. Telling CAs what they should and should not put in certificates has been a complete
failure in the past. Telling CAs what conformant implementations will do with their certificates should
be / could be more effective. It also puts the onus on relying parties to actually read the certs in order to
comply with the RFC, not to assume that the CA did anything special.
Permalink | Reply |
headers
Peter Saint-Andre | 28 Aug 23:18
Favicon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check


On 8/28/09 3:10 PM, Paul Hoffman wrote:
> At 9:55 PM +0100 8/28/09, Alexey Melnikov wrote:
>> Paul Hoffman wrote:
>> 
>>> At 5:35 PM -0600 8/27/09, Peter Saint-Andre wrote:
>>> 
>>> 
>>>> Paul, I agree that this document needs to codify secure
>>>> authentication practices. However, that raises a more general
>>>> issue: shall this document specify rules only for certificate
>>>> validation or also for certificate generation?
>>>> 
>>> Validation only.
>>> 
>>> 
>> I tend to agree. But generation has to match validation, so I don't
>> see much practical difference. Unless I am missing some subtle
>> point...
> 
> Not subtle at all. Telling CAs what they should and should not put in
> certificates has been a complete failure in the past. Telling CAs
> what conformant implementations will do with their certificates
> should be / could be more effective. It also puts the onus on relying
> parties to actually read the certs in order to comply with the RFC,
> not to assume that the CA did anything special.

Yes, exactly.

Peter
(Continue reading)

Permalink | Reply |
headers
Peter Saint-Andre | 28 Aug 23:01
Favicon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check


On 8/28/09 2:55 PM, Alexey Melnikov wrote:
> Paul Hoffman wrote:
> 
>> At 5:35 PM -0600 8/27/09, Peter Saint-Andre wrote:
>>  
>>
>>> Paul, I agree that this document needs to codify secure authentication
>>> practices. However, that raises a more general issue: shall this
>>> document specify rules only for certificate validation or also for
>>> certificate generation?
>>>
>>
>> Validation only.
>>  
>>
> I tend to agree. But generation has to match validation, so I don't see
> much practical difference. Unless I am missing some subtle point...

This specification is not legislating how CAs MUST or MUST NOT generate
certificates, only how clients MUST or MUST NOT check the identities
that they find. The difference between encoding and decoding, I suppose.

Peter

--
Peter Saint-Andre
https://stpeter.im/
(Continue reading)

Permalink | Reply |
headers
Nicolas Williams | 8 Jun 19:33
Picon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

On Sat, Jun 06, 2009 at 07:51:12AM -0700, Paul Hoffman wrote:
> >>There is no good reason for a CA to issue certificates with domain
> >>names in the subjectName, and lots of reasons for it not to.
> >>
> >I think the current reality is that many of CAs still do that without
> >supporting DNS name in the subjectAltName.
> 
> Probably. Are you saying that the fact that they are doing this
> knowingly insecurely should stop us from prohibiting it in this
> profile? This profile is supposed to be a way to codify secure
> authentication practice. Saying "but there are CAs who do it wrong and
> you should validate their certificates anyway" seems
> counterproductive.

Non-interop would also be counter-productive.  And a knob wouldn't be
much help either.  A phase-out of certs with domain names in subjectName
seems in order.  Perhaps we should say that such certs issued after some
date are prohibited.

Nico
--

--
Permalink | Reply |
headers
Paul Hoffman | 8 Jun 19:59
Picon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

At 12:33 PM -0500 6/8/09, Nicolas Williams wrote:
>A phase-out of certs with domain names in subjectName
>seems in order. 

Not at all. It is fine to have a certificate with a subject with a CN of "www.example.com". That value follows
the semantics for "common name".

>Perhaps we should say that such certs issued after some
>date are prohibited.

The chance of this have any success is near zero.

The document in question is about validating systems, not CAs. I think it is quite appropriate for us to keep
that focus.
Permalink | Reply |
headers
Peter Saint-Andre | 28 Aug 18:28
Favicon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check


On 6/8/09 11:59 AM, Paul Hoffman wrote:
> At 12:33 PM -0500 6/8/09, Nicolas Williams wrote:
>> A phase-out of certs with domain names in subjectName seems in
>> order.
> 
> Not at all. It is fine to have a certificate with a subject with a CN
> of "www.example.com". That value follows the semantics for "common
> name".

Right, in this document we are not legislating what can go in a CN.
However, my understanding is that we are saying that a client would not
compare its reference identity against the string "www.example.com" as
found in the CN. Correct?

Peter

--
Peter Saint-Andre
https://stpeter.im/
Permalink | Reply |
headers
Paul Hoffman | 28 Aug 18:39
Picon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

At 10:28 AM -0600 8/28/09, Peter Saint-Andre wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 6/8/09 11:59 AM, Paul Hoffman wrote:
>> At 12:33 PM -0500 6/8/09, Nicolas Williams wrote:
>>> A phase-out of certs with domain names in subjectName seems in
>>> order.
>>
>> Not at all. It is fine to have a certificate with a subject with a CN
>> of "www.example.com". That value follows the semantics for "common
>> name".
>
>Right, in this document we are not legislating what can go in a CN.
>However, my understanding is that we are saying that a client would not
>compare its reference identity against the string "www.example.com" as
>found in the CN. Correct?

Correct. The document is about how to find the identifier in an interoperable fashion, not what CAs need to do.
Permalink | Reply |
headers
Nicolas Williams | 8 Jun 19:58
Picon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

On Mon, Jun 08, 2009 at 10:59:05AM -0700, Paul Hoffman wrote:
> At 12:33 PM -0500 6/8/09, Nicolas Williams wrote:
> >A phase-out of certs with domain names in subjectName
> >seems in order. 
> 
> Not at all. It is fine to have a certificate with a subject with a CN
> of "www.example.com". That value follows the semantics for "common
> name".

I hadn't caught up with the rest of the thread, which subsequently made
clear what the issue was.  I retract my comment.

Nico
--

--
Permalink | Reply |
headers
Alexey Melnikov | 7 Jun 21:31
Favicon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

Paul Hoffman wrote:

>At 11:42 PM +0100 6/5/09, Alexey Melnikov wrote:
>  
>
>>Hi Paul,
>>
>>Paul Hoffman wrote:
>>    
>>
>>>Greetings again. I would like to argue that, from a security perspective, we should not allow looking up
DNS names in the subjectName in PKIX certificates in this document. Section 3.1 says:
>>> The server's identity may also be verified by comparing the reference
>>> identity to the Common Name (CN) [LDAP-SCHEMA] value in the leaf
>>> Relative Distinguished Name (RDN) of the subjectName field of the
>>> server's certificate.  This comparison is performed using the rules
>>> for comparison of DNS names in Section 3.1.3.1, below, with the
>>> exception that no wildcard matching is allowed.  Although the use of
>>> the Common Name value is existing practice, it is deprecated, and
>>> Certification Authorities are encouraged to provide subjectAltName
>>> values instead.  Note that the TLS implementation may represent DNs
>>> in certificates according to X.500 or other conventions.  For
>>> example, some X.500 implementations order the RDNs in a DN using a
>>> left-to-right (most significant to least significant) convention
>>> instead of LDAP's right-to-left convention.
>>>
>>>That ambiguity leads to a fairly trivial identity attack
>>>
>>Can you elaborate on this? (A pointer to discussion elsewhere would be fine as well.)
>>
(Continue reading)

Permalink | Reply |
headers
Peter Saint-Andre | 28 Aug 22:40
Favicon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check


On 6/7/09 1:31 PM, Alexey Melnikov wrote:
> Paul Hoffman wrote:
> 
>> At 11:42 PM +0100 6/5/09, Alexey Melnikov wrote:
>>  
>>
>>> Hi Paul,
>>>
>>> Paul Hoffman wrote:
>>>   
>>>> Greetings again. I would like to argue that, from a security
>>>> perspective, we should not allow looking up DNS names in the
>>>> subjectName in PKIX certificates in this document. Section 3.1 says:
>>>> The server's identity may also be verified by comparing the reference
>>>> identity to the Common Name (CN) [LDAP-SCHEMA] value in the leaf
>>>> Relative Distinguished Name (RDN) of the subjectName field of the
>>>> server's certificate.  This comparison is performed using the rules
>>>> for comparison of DNS names in Section 3.1.3.1, below, with the
>>>> exception that no wildcard matching is allowed.  Although the use of
>>>> the Common Name value is existing practice, it is deprecated, and
>>>> Certification Authorities are encouraged to provide subjectAltName
>>>> values instead.  Note that the TLS implementation may represent DNs
>>>> in certificates according to X.500 or other conventions.  For
>>>> example, some X.500 implementations order the RDNs in a DN using a
>>>> left-to-right (most significant to least significant) convention
>>>> instead of LDAP's right-to-left convention.
>>>>
>>>> That ambiguity leads to a fairly trivial identity attack
>>>>
(Continue reading)

Permalink | Reply |
headers
Alexey Melnikov | 28 Aug 23:28
Favicon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

Peter Saint-Andre wrote:

>On 6/7/09 1:31 PM, Alexey Melnikov wrote:
>  
>
 [...]

>>However I believe the text is talking about something else entirely. It
>>is talking about order of Relative DNs (RDNs). For example, a
>>subjectName for a domain might look like:
>>
>> cn=www.example.com, ou=Web Services, c=GB
>>
>>Here c=GB is the most significant RDN. What the text is saying is that
>>some X.500 implementations would represent it as
>>
>> c=GB, ou=Web Services, cn=www.example.com
>>
>>or something like this. Kurt can probably explain this better than I can.
>>
>
>After puzzling over the text for a while, I agree that this is what it
>is trying to say (perhaps not very well). But as far as I can see, in
>the second example the client would not check the CN because it is not
>the leaf RDN. Or is the text saying that sometimes the leaf RDN might
>actually be right-most instead of left-most?
>
I think it is.

>>So there is no reordering of domains inside the CN value.
(Continue reading)

Permalink | Reply |
headers
Paul Hoffman | 7 Jun 22:35
Picon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

At 8:31 PM +0100 6/7/09, Alexey Melnikov wrote:
>[As a side note, if the document were allowing use of DC (domain components) in subjectName, the problem
you've identifier would have been relevant:
>dc=com, dc=ar, ou=Web Services, c=GB
>versa
>dc=ar, dc=com, ou=Web Services, c=GB
>]

I am assuming that the problem is reordering of DC values. None of the others affect the matching discussed
in this document. It is *completely* believable that some implementations string together the DC values
in different orders.
Permalink | Reply |
headers
Alexey Melnikov | 8 Jun 12:09
Favicon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

Paul Hoffman wrote:

>At 8:31 PM +0100 6/7/09, Alexey Melnikov wrote:
>  
>
>>[As a side note, if the document were allowing use of DC (domain components) in subjectName, the problem
you've identifier would have been relevant:
>>dc=com, dc=ar, ou=Web Services, c=GB
>>versa
>>dc=ar, dc=com, ou=Web Services, c=GB
>>]
>>    
>>
>I am assuming that the problem is reordering of DC values. None of the others affect the matching discussed
in this document. It is *completely* believable that some implementations string together the DC values
in different orders.
>  
>
Right.
Use of DC attributes is already disallowed by not being explicitly allowed.

Of course the document needs to be clear on what it means about 
left-to-right RDN ordering versa right-to-left RDN ordering. So some 
text needs to be added to clarify, or the confusing sentence needs to be 
removed.
Permalink | Reply |
headers
Kurt Zeilenga | 12 Jun 16:23
Favicon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check


On Jun 8, 2009, at 3:09 AM, Alexey Melnikov wrote:

> Use of DC attributes is already disallowed by not being explicitly  
> allowed.

Well, as subsequently clarified, DC attributes are allowed in the  
subjectName DN, just not used to verify the subject.

> Of course the document needs to be clear on what it means about left- 
> to-right RDN ordering versa right-to-left RDN ordering. So some text  
> needs to be added to clarify, or the confusing sentence needs to be  
> removed.

In DC naming, the most significant domain component belongs in the  
most significant RDN... the second most significant component in the  
second most significant RDN, ..., and these RDNs ought to be singled  
valued.

But if the document doesn't discuss verification by DC naming, it  
doesn't need to say anything about DC naming.

-- Kurt
Permalink | Reply |
headers
Paul Hoffman | 12 Jun 17:21
Picon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

At 7:23 AM -0700 6/12/09, Kurt Zeilenga wrote:
>But if the document doesn't discuss verification by DC naming, it doesn't need to say anything about DC naming.

Given that some current systems do validate on DC names, I think we *do* need to say "DC matching is not
allowed in this profile".
Permalink | Reply |
headers
Paul Hoffman | 8 Jun 16:02
Picon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

At 11:09 AM +0100 6/8/09, Alexey Melnikov wrote:
>Use of DC attributes is already disallowed by not being explicitly allowed.

It would be better if it was explicit, given that many systems still use DC.

>Of course the document needs to be clear on what it means about left-to-right RDN ordering versa
right-to-left RDN ordering. So some text needs to be added to clarify, or the confusing sentence needs to
be removed.

Fully agree. Examples of where it is and is not OK to look would be helpful here.
Permalink | Reply |
headers
Kurt Zeilenga | 12 Jun 16:15
Favicon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check


On Jun 8, 2009, at 7:02 AM, Paul Hoffman wrote:

>>
>> Of course the document needs to be clear on what it means about  
>> left-to-right RDN ordering versa right-to-left RDN ordering. So  
>> some text needs to be added to clarify, or the confusing sentence  
>> needs to be removed.
>
> Fully agree. Examples of where it is and is not OK to look would be  
> helpful here.

The document should say that when CN=domain AVA is used, this AVA  
ought be the only AVA in the RDN (not a multi-valued RDN), and the RDN  
ought to be least significant RDN of the DN.   (Avoid the left-to- 
right/right-to-left descriptions, as these terms are based upon text  
representations of DNs, what matters is placement in the abstract  
value.)   We can argue whether "ought" above translates to MUST or  
SHOULD in the document.

However, IIRC, there are CAs which place the CN=domain AVA in a multi- 
valued RDN and/or place the RDN somewhere other than the least- 
significant RDN.  Both of which are problematic, but for different  
reasons.

-- Kurt
Permalink | Reply |
headers
Paul Hoffman | 12 Jun 17:20
Picon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

At 7:15 AM -0700 6/12/09, Kurt Zeilenga wrote:
>On Jun 8, 2009, at 7:02 AM, Paul Hoffman wrote:
>
>>>
>>>Of course the document needs to be clear on what it means about left-to-right RDN ordering versa
right-to-left RDN ordering. So some text needs to be added to clarify, or the confusing sentence needs to
be removed.
>>
>>Fully agree. Examples of where it is and is not OK to look would be helpful here.
>
>The document should say that when CN=domain AVA is used,

AVA?

>this AVA ought be the only AVA in the RDN (not a multi-valued RDN), and the RDN ought to be least significant
RDN of the DN.   (Avoid the left-to-right/right-to-left descriptions, as these terms are based upon text
representations of DNs, what matters is placement in the abstract value.)   We can argue whether "ought"
above translates to MUST or SHOULD in the document.

That's an important discussion. I am pretty sure I have seen certs with DNs with multiple CNs with different
domain names in the past.

>However, IIRC, there are CAs which place the CN=domain AVA in a multi-valued RDN and/or place the RDN
somewhere other than the least-significant RDN.  Both of which are problematic, but for different reasons.

...and therefore we need to describe the problems.
Permalink | Reply |
headers
Kurt Zeilenga | 12 Jun 18:23
Favicon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check


On Jun 12, 2009, at 8:20 AM, Paul Hoffman wrote:

> At 7:15 AM -0700 6/12/09, Kurt Zeilenga wrote:
>> On Jun 8, 2009, at 7:02 AM, Paul Hoffman wrote:
>>
>>>>
>>>> Of course the document needs to be clear on what it means about  
>>>> left-to-right RDN ordering versa right-to-left RDN ordering. So  
>>>> some text needs to be added to clarify, or the confusing sentence  
>>>> needs to be removed.
>>>
>>> Fully agree. Examples of where it is and is not OK to look would  
>>> be helpful here.
>>
>> The document should say that when CN=domain AVA is used,
>
> AVA?

Attribute Value Assertion.

>
>> this AVA ought be the only AVA in the RDN (not a multi-valued RDN),  
>> and the RDN ought to be least significant RDN of the DN.   (Avoid  
>> the left-to-right/right-to-left descriptions, as these terms are  
>> based upon text representations of DNs, what matters is placement  
>> in the abstract value.)   We can argue whether "ought" above  
>> translates to MUST or SHOULD in the document.
>
> That's an important discussion. I am pretty sure I have seen certs
(Continue reading)

Permalink | Reply |
headers
Philip Guenther | 8 Jun 16:44
Favicon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

On Mon, 8 Jun 2009, Paul Hoffman wrote:
> At 11:09 AM +0100 6/8/09, Alexey Melnikov wrote:
> >Use of DC attributes is already disallowed by not being explicitly 
> >allowed.
> 
> It would be better if it was explicit, given that many systems still use 
> DC.

My understanding is that all Alexey is saying that an implementation that 
matches a cert whose subject is
	dc=example,dc=com

(expressed in LDAP-style, most-specific-leftmost) against the domain 
"example.com" is not compliant because that is not a documented method.  
Is that what you're saying many systems do, Paul?

(I don't think there's any suggestion here of deprecating the use of dc 
components in DNs; they just can't be used for the SSL hostname check.)

Philip Guenther
Permalink | Reply |
headers
Alexey Melnikov | 8 Jun 16:57
Favicon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

Philip Guenther wrote:

>On Mon, 8 Jun 2009, Paul Hoffman wrote:
>  
>
>>At 11:09 AM +0100 6/8/09, Alexey Melnikov wrote:
>>    
>>
>>>Use of DC attributes is already disallowed by not being explicitly 
>>>allowed.
>>>      
>>>
>>It would be better if it was explicit, given that many systems still use 
>>DC.
>>    
>>
>My understanding is that all Alexey is saying that an implementation that 
>matches a cert whose subject is
>	dc=example,dc=com
>
>(expressed in LDAP-style, most-specific-leftmost) against the domain 
>"example.com" is not compliant because that is not a documented method.
>  
>
Yes.

>Is that what you're saying many systems do, Paul?
>  
>
I can't say I am an expert, but this never came up for Isode's deployments.
(Continue reading)

Permalink | Reply |
headers
Paul Hoffman | 8 Jun 18:04
Picon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

At 3:57 PM +0100 6/8/09, Alexey Melnikov wrote:
>Philip Guenther wrote:
>>(I don't think there's any suggestion here of deprecating the use of dc components in DNs; they just can't
be used for the SSL hostname check.)
>Exactly.

There was a desire to make this document useful for more than TLS if other groups want to re-use it. I would
like to see this document not allow the use of DC in DNs for validating host names. That is definitely not a
prohibition on CAs issuing certificates with DCs; a CA can decide whether or not they want to continue to do
so in a world where parties follow this document.
Permalink | Reply |
headers
Patrik Fältström | 8 Jun 16:22
Picon
Favicon

Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check


On 8 jun 2009, at 16.02, Paul Hoffman wrote:

> At 11:09 AM +0100 6/8/09, Alexey Melnikov wrote:
>> Use of DC attributes is already disallowed by not being explicitly  
>> allowed.
>
> It would be better if it was explicit, given that many systems still  
> use DC.

While I tend to agree with you Paul (and specifically, I do not  
personally like DC naming), I am also nervous over words like "many",  
"few", "almost everyone" etc.

Do you have any knowledge of how bad the situation really is? Is there  
anything more to do to fix this? Do we talk about many standards, many  
vendors, many products, many deployed entities -- or all of the above?

    Patrik
Permalink | Reply |
headers
Simon Josefsson | 4 Jun 10:29
Favicon
Gravatar

Re: [Fwd: I-D Action:draft-saintandre-tls-server-id-check-00.txt]

Peter Saint-Andre <stpeter <at> stpeter.im> writes:

> FYI. All I did was update the references, change the title slightly, and
> update the authors. Feedback is welcome before we publish a version with
> more significant modifications.

Generally, I agree a document like this is needed.  Some suggestions:

1) Define all terminology in section 2.  The term "reference identity"
is defined in section 3 but used in other sections too.

2) Re 3.1, should the reference identity be considered a stored string
wrt IDNA?  As I understand what reference identity refers to, it seems
like a query string to me.

Thanks,
/Simon
Permalink | Reply |
headers
Peter Saint-Andre | 28 Aug 17:48
Favicon

Re: [Fwd: I-D Action:draft-saintandre-tls-server-id-check-00.txt]


Again, sorry about the delayed reply.

On 6/4/09 2:29 AM, Simon Josefsson wrote:
> Peter Saint-Andre <stpeter <at> stpeter.im> writes:
> 
>> FYI. All I did was update the references, change the title slightly, and
>> update the authors. Feedback is welcome before we publish a version with
>> more significant modifications.
> 
> Generally, I agree a document like this is needed.  Some suggestions:
> 
> 1) Define all terminology in section 2.  The term "reference identity"
> is defined in section 3 but used in other sections too.

Done in my working copy.

> 2) Re 3.1, should the reference identity be considered a stored string
> wrt IDNA?  As I understand what reference identity refers to, it seems
> like a query string to me.

Could you perhaps elaborate your reasons for thinking so?

JeffH and RL Bob wrote that text, so they can explain their reasoning
better than I can. However, I note the following text from RFC 3454
regarding the distinction between stored strings and queries:

   In general, "stored strings"
   are strings that are used in protocol identifiers and named entities,
   such as names in digital certificates and DNS domain name parts.
(Continue reading)

Permalink | Reply |

Gmane