Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 13 Sep 2010 10:08:11 -0600

On 9/9/10 12:22 PM, Shumon Huque wrote:
> On Wed, Sep 08, 2010 at 11:08:29PM +0200, Stefan Santesson wrote:
>>
>> On 10-09-08 9:53 PM, "Shumon Huque" <[email-masked]> wrote:
>>> The output of the SRV record lookup contains a target hostname,
>>> not a service name, so it's not applicable to the SRVName name
>>> form. The target could be used in another name form (dNSName)
>>> as the reference identifier, but then the client needs to convince
>>> itself that the lookup was done securely (DNSSEC or some other
>>> means) otherwise there's a security problem.
>>
>> I disagree,
>>
>> A client can use the output from the DNS lookup also from a normal insecure
>> DNS server.
>>
>> The only thing the client need to do is to verify that the domain name
>> provided in the input to the lookup matches the host names provided in the
>> output. It can then safely use the host names in the SRV record as reference
>> identifiers IF the SRV-ID in the server certificate matches the the
>> reference identifier.
> 
> This only works if the certificate matching rules say something 
> like "match the SRVName AND also match the DNS resolved target
> hostname in dNSName". If a client attempts to match _only_ the DNS 
> resolved hostname without DNSSEC, there is a security problem.
> 
> The question is: what should the certificate matching rules say
> when encountering a certificate with multiple identity types?
> Right now the draft approximately says "find a match" (ie. find
> ANY match), rather than match some logically AND'ed combination of 
> identity types.
> 
>   http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-09#section-4

Hi Shumon,

As I see it, this I-D is attempting to capture best current practices
regarding the issuance and checking of certificates containing
application server identities. Do we have evidence that any existing
certification authorities issue certificates containing both an SRVname
for the source domain (e.g., example.com) and dNSName for the target
domain (e.g., apphosting.example.net)? Do we have evidence that any
existing application clients perform such checks? If not, I would
consider such complications to be out of scope for this I-D.

That said, we need to be aware that if such usage arises in the future,
someone might write a document that updates or obsoletes this I-D; in
fact the present authors very much expect that such documents will
emerge after the Internet community (specifically certification
authorities, application service providers, and application client
developers) have gained more experience with PKIX certificates in the
context of various application technologies.

Peter

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Sep 2010 09:17:01 -0700

>consider such complications to be out of scope for this I-D.

A big +1 here. It is a Good Thing that people are starting to look at the interaction between SRV and security (it's also happening on the keyassure list), but it definitely seems like "starting to look at". Please do not instantiate anything until this has been discussed more widely.

--Paul Hoffman, Director
--VPN Consortium

---

From: Shumon Huque <[email-masked]>
Date: Mon, 13 Sep 2010 12:52:59 -0400

On Mon, Sep 13, 2010 at 10:08:11AM -0600, Peter Saint-Andre wrote:
> application server identities.

Yes, but whether they are actually "current" best practices is 
debatable. I certainly would like them to become best practices.
For example I don't believe any existing commercial CAs issue 
certificates with the SRVName or URI SAN name forms.

> Do we have evidence that any existing

I think the question is whether we have examples of applications 
that need to verify "combinations" of subjectaltname name forms in 
certificates. Stefan says there are, but so far no-one has offered
up any public specifications of such apps. So, I think until we 
have them, I agree we can defer considerations of them to future 
documents.

I think it's reasonable for this draft to consider multiple identity
types in certificates (eg. common name, dNSName, SRVName) with the
current matching rules of ANY. This might be needed to gradually
transition an app from validating a host specific identity to an
application specific identity. The current draft allows this.

> context of various application technologies.

Sounds reasonable.

-- 
Shumon Huque
University of Pennsylvania.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 13 Sep 2010 11:03:24 -0600

> certificates with the SRVName or URI SAN name forms.

As far as I know, at least one CA will issue certificates with the
SRVName form (for XMPP certificates). We could ask some folks in the SIP
community if any CAs issue certificates with the URI form (see
draft-ietf-sip-certs).

> have them, I agree we can defer considerations of them to future 

Agreed. I've never seen this I-D as the final word, but instead as the
beginning of a longer-term conversation, both about the limited topic
that's covered in the I-D as well as all the topics we deemed out of scope.

> application specific identity. The current draft allows this.

Correct.

>> context of various application technologies.

I'm looking forward to further work in this area.

Peter

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

---

From: Dave Cridland <[email-masked]>
Date: Mon, 13 Sep 2010 18:05:11 +0100

> certificates with the SRVName or URI SAN name forms.
They do, I've seen sRVName SANs in some XMPP server certificates.

> application specific identity. The current draft allows this.
Isode M-Link will check xmppAddr and dNSName (and I'll add in sRVName  
soonish, and possibly URI). If no SANs of a supported type exist,  
then it will fall back to a CN match.

It will not check the dNSName against the result of a SRV DNS lookup,  
ever, nor will it check a dNSName if it has already found a matching  
xmppAddr (nor vice-versa). As such it's not checking combinations of  
SANs.

Looking at the draft, it seems to read that I should check dNSName  
first, and then, only if this matches, check xmppAddr or sRVName.  
This seems odd - sRVName and xmppAddr (and URI) all contain a  
superset of the data contained, so why look at dNSName if a more  
specific match exists?

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Martin Rex <[email-masked]>
Date: Thu, 9 Sep 2010 23:10:35 +0200 (MEST)

Shumon Huque wrote:
> 
> On Wed, Sep 08, 2010 at 08:44:56AM -0700, Bernard Aboba wrote:
> > 
> > If the "reference identifier" is  _Service.Name then the match is being done
> > on the *input* to the SRV lookup process, not the output, and prohibition on
> > DNS lookups would not apply (or even make any sense). 
> 
> Yes.
> 

I'm feeling very uneasy with the suggestion that a DNSSEC instead
of the DNS lookup might make it less of a security problem.

DNSSEC provides only data integrity protection and data origin
authentication of the records, and NOTHING beyond that.  In particular,
it does _NOT_ provide any trust in the conveyed information.

But in order to avoid the mentioned security problem, trust in the
transformation is an absolute prerequisite for the name transformation
in order to use the result in any kind of endpoint identity verification.

Although I personally think the trustworthiness of the rootCA certs
in web browsers is significantly overrated, there seems to be some
understanding out there that there is a huge difference between
cryptographic protection and trust, so there are browser vendors that
require CAs to apply a certain amount of scrutiny before issuing
certificates and subject themselves to an audit for a non-negligable
amount of cost before the browser vendors are going to include the
CAs self-signed rootCA cert as pre-trusted with their browser.

Are DNS domain admins going to be required to apply as much scrutiny
for each and every DNS record in their zone and have to succeed a
comparable audit of their DNS record maintenance procedures before
their parent domain will sign their zone signing keys?

DNS is an important an vital part of the internet, and it needs to
remain fast, efficient and free in order to remain useful.
Besides, even if DNSSEC signed records are being made available
in increasing numbers, that information is not visible to >90% of
the end users of the internet (like DSL subscribers) and is going to
remain invisible for most of them for many years to come.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 13 Sep 2010 20:39:43 +0200

Peter,

> context of various application technologies.

I would like to turn the question around and ask why this specification need
to have an opinion on whether a relying party feels he have to check both
host name and service?

I'm not against describing the typical case, as long as this specification
does not imply that a relying party that has a reason to check two name
types is doing something wrong.

I have no extremely good examples of practical implementation here but
checking both host name and service seems like both extremely easy and good
practice.

/Stefan

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 13 Sep 2010 12:48:56 -0600

On 9/13/10 11:05 AM, Dave Cridland wrote:
> soonish, and possibly URI). If no SANs of a supported type exist, then
> it will fall back to a CN match.
> 
> xmppAddr (nor vice-versa). As such it's not checking combinations of SANs.
> 
> first, and then, only if this matches, check xmppAddr or sRVName. This
> seems odd - sRVName and xmppAddr (and URI) all contain a superset of the
> data contained, so why look at dNSName if a more specific match exists?

Earlier versions of this draft had somewhat elaborate rules about
ordering of reference identifiers. Those rules were removed in -09
because folks on the [email-masked] list argued persuasively that they
were not necessary because "first match wins" is good enough. Naturally,
an implementation might have a preference order of reference
identifiers, but such an order is not mandated by this I-D.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 13 Sep 2010 13:16:57 -0600

> to have an opinion on whether a relying party feels he have to check both

Stop right there. :) I sense a possible source of confusion. What do you
mean by "host name" and what do you mean by "service"?

In this I-D, we talk about "DNS domain name" and "service type", which
map quite well to _Service.Name from RFC 4985: the DNS domain name is
the "source domain" provided by the user or configured into the client
(e.g., "example.com") and the "service type" is a given application
protocol that could be serviced by the source domain (e.g., "IMAP").

This I-D is attempting to gently nudge people in the direction of
checking both the DNS domain name and the service type. IMHO this is
consistent with considering the SRVName and uniformResourceIdentifier
subjectAltName entries as more tightly scoped than dNSName or CN, and
therefore as potentially more "secure" in some sense (the subject might
want to limit use of a particular certificate to only the service type
identified in the SRVName or uniformResourceIdentifier).

If by "host name" you mean "target domain" as defined in the I-D (and
mapping to "Target" from RFC 2782) then we have more to discuss.

> types is doing something wrong.

That is not the intent of this I-D, however that would be functionality
over and above what this I-D defines.

> checking both host name and service seems like both extremely easy and good

With respect to revisions to this I-D, the lack of good examples
troubles me because we have been trying to abstract from common usage,
not to define guidelines for use cases that have not yet been defined,
implemented, and deployed.

Given that you would prefer to leave the door open to more advanced
checking rules, I think you would object to this text in Section 4.3:

   Once the client has constructed its list of reference identifiers and
   has received the server's presented identifiers in the form of a PKIX
   certificate, the client checks its reference identifiers against the
   presented identifiers for the purpose of finding a match.  It does so
   by seeking a match and stopping the search if any presented
   identifier matches one of its reference identifiers.  The search
   fails if the client exhausts its list of reference identifiers
   without finding a match.

You are saying that it is not necessarily appropriate to stop the search
once a single match is found, because the client might be configured to
look for multiple matches (e.g., a match against both the source domain
and the target domain). Would you like to suggest text that covers such
a case? Here is a possible rewrite of Section 4.3 that might address
your concern.

###

4.3.  Seeking a Match

   Once the client has constructed its list of reference identifiers and
   has received the server's presented identifiers in the form of a PKIX
   certificate, the client checks its reference identifiers against the
   presented identifiers for the purpose of finding a match.  The search
   fails if the client exhausts its list of reference identifiers
   without finding a match.  The search succeeds if any presented
   identifier matches one of the reference identifiers, at which point
   the client SHOULD stop the search.

      Implementation Note: A client might be configured to perform
      multiple searches, i.e., to match more than one reference
      identifier; although such behavior is not forbidden by this
      document, rules for matching multiple reference identifiers are a
      matter for implementation or future specification.

      Security Note: A client MUST NOT seek a match for a reference
      identifier of CN-ID if the presented identifiers include an
      SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName
      entry types supported by the client.

   Detailed comparison rules for finding a match are provided in the
   following sections.

###

Peter

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

---

From: Dave Cridland <[email-masked]>
Date: Mon, 13 Sep 2010 20:18:13 +0100

On Mon Sep 13 19:48:56 2010, Peter Saint-Andre wrote:
> This

Ah, I see my confusion. §4.4 says:

4.4. Verifying a Domain Name

   The client MUST match the source domain of a reference identifier
   according to the following rules

And §4.5 says:

4.5. Verifying an Application Type

   A client SHOULD check not only the domain name but also the service
   type of the service to which it connects.

Now, I misconstrued that to mean "MUST use dNSName, SHOULD use  
sRVName", which is purely me misreading.

Up to you whether you think other people will be as silly as me, and  
what to do about it if so.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 13 Sep 2010 13:21:59 -0600

On 9/13/10 1:18 PM, Dave Cridland wrote:
> Now, I misconstrued that to mean "MUST use dNSName, SHOULD use sRVName",
> which is purely me misreading.
> 

A forward reference seem appropriate:

   The client MUST match the source domain of a reference identifier
   according to the following rules (and SHOULD also check the service
   type as described under Section 4.5).

Peter

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

---

From: Dave Cridland <[email-masked]>
Date: Mon, 13 Sep 2010 20:29:48 +0100

>    type as described under Section 4.5).

Spot on.

Dave.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 14 Sep 2010 02:03:39 +0200

Peter,
Comments in line;

> mean by "host name" and what do you mean by "service"?
Sorry for sloppy use of words.

With host name I mean here the actual DNS name of the host, which might be
host1.example.com (dNSName)

By service I mean the service under a given domain, which for the same host
might be _xmpp.example.com (SRVName)

Under the current rules, using this example I read it that the following
apply:

- If you are just checking the SRVName you will not learn the legitimate
host DNS name. So a certificate issued to host2.example.com will be accepted
even if you intended to contact host1.example.com (even if that information
is in the cert).

- If you just check the dNSName, you will miss the fact that you talk to the
desiganted ldap server and not the xmpp server (even if that information is
in the cert).

>    Detailed comparison rules for finding a match are provided in the

This sounds better to me.

If I'm not totally wrong in my example above I also think it would be good
with a security note stating that an SRVName may not provide the full host
DNS name, and if it is important to verify the host DNS name, you must
verify the dNSName in addition to what else you are checking.

/Stefan

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 13 Sep 2010 21:32:42 -0600

> Comments in line;

Ditto.

> host1.example.com (dNSName)

Or which might be apphost37.example.net or whatever...

> might be _xmpp.example.com (SRVName)

OK.

But what does dNSName=host1.example.com + SRVName=_xmpp.example.com
actually mean? I see three possibilities:

1. "Connect to example.com's XMPP service only if it's hosted on
host1.example.com"

2. "Don't connect to host1.example.com if you are looking for something
other than example.com's XMPP service" (i.e., if you want the IMAP
service or anything else at example.com, terminate the connection)

3. "The connection is fine if you're looking for (a) any service at
host1.example.com, *or* (b) example.com's XMPP service"

In my experience running the XMPP ICA for a few years, I found that our
root CA would issue dNSName=example.com + SRVName=_xmpp.example.com but
not dNSName=host1.example.com + SRVName=_xmpp.example.com (i.e., the
name in both dNSName and SRVName was the same). Yes, that is anecdotal,
but I think it makes some sense, because IMHO a CA is not going to "get
involved" with the particular machine that hosts a service (i.e., to
differentiate between the DNS domain name of the application service and
the DNS domain name of the hosting machine / provider).

> host DNS name. 

Are there any application clients today that would check only the SRVName?

> So a certificate issued to host2.example.com will be accepted

In what sense does the application client "intend" to contact
host1.example.com? The user controlling a client (a browser or an email
client or an IM client or whatever) intends to contact example.com, not
host1.example.com or apphost37.example.net or whatever.

> desiganted ldap server and not the xmpp server (even if that information is

Correct. If that is a problem in your user community or operating
environment, then you need to find a better client.

IMHO it is almost a best practice for the DNS domain names in the
various presented identifiers of the certificate (dNSName, SRVName,
uniformResourceIdentifier, etc.) to be the same. I think we in the
Internet community don't yet have enough experience to say that with
high confidence, which is why I'm not ready to push on the point in this
I-D. However, let us consider the example of a delegated domain, such as
dNSName=apphost37.example.net + SRVName=_xmpp.example.com, which might mean:

1. "Connect to example.com's XMPP service only if it's hosted on
apphost37.example.com"

2. "Don't connect to apphost37.example.com if you are looking for
something other than example.com's XMPP service" (i.e., if you want the
IMAP service or anything else at example.com, terminate the connection)

3. "The connection is fine if you're looking for (a) any service at
apphost37.example.com, *or* (b) example.com's XMPP service"

In this case, I think #3 is clearly wrong because the user doesn't know
anything about apphost37.example.net and doesn't intend to connect to
that host.

#1 and #2 are close to equivalent, because they attempt to establish a
firm association between a host name (apphost37.example.net) and an
application service (example.com's XMPP service). Is that association
desirable? I'm not convinced (mainly because, to reiterate, I think that
end users don't know or care about the hosting provider or machine).
However, for such an association to be helpful, we'd need (i) clients
that consistently check both identifier types and (ii) CAs that certify
both the application service and the hosting provider. Further, I think
we'd also need (iii) a well-defined semantic that says dNSName is used
to represent the DNS domain name of the hosting provider or machine --
and as far as I can see dNSName does not have that meaning. Given that
we don't have (i), (ii), or (iii), I question the need for this line of
thinking.

> verify the dNSName in addition to what else you are checking.

See above. You and I seem to continually run aground on a disagreement
over whether it makes any sense for an application client (or the user
thereof) to know of, care about, or verify the DNS domain name of the
hosting machine / service / provider. That's the basis for our previous
discussion about RFC 4985 and it's the basis for our current discussion
about dNSName vs. SRVName. I simply don't understand why a normal human
user of an application client would ever want or need to be aware of the
hosting provider for a given application service, why a CA would want to
certify an association between a hosting provider and a given
application service, or why we would ever assume that the dNSName is
meant to identify the hosting provider whereas the SRVName is meant to
identify the application service. Cementing such an association in those
three ways is outside the scope of this I-D, even if one accepts the
premise that such an association is a good idea (which I don't). Can we
agree to disagree here and, rather than add a note about the security
features of such an association, instead add a note to Section 1.3.2
("Out of Scope") explaining why any possible association between the
application service and the hosting machine / service / provider is out
of scope for this I-D? Perhaps in the future we will have advanced far
enough to define best practices for such associations, but right now it
seems to me that we lack a firm basis for doing so.

Peter

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

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 14 Sep 2010 08:41:11 +0200

Peter,

I'm not driven by any desire to mandate more complex name comparison than is
called for. I just tend to think that it is better leave name comparison
requirement up to local policy.

However I think your argumentation is reasonable here and you convinced me.
I agree that in the general cases you are not interested in the host DNS
name.

I've decided that I'm perfectly fine with your proposed wording.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 14 Sep 2010 08:51:27 +0200

Peter,

After the past discussions, the remaining things on my review list are:

General:
consider substituting ³PKIX-based systems² and ³PKIX Certificates² with ³PKI
systems based on RFC 5280² and ³RFC 5280 Certificates², alternatively
include [PKIX] brackets to clarify that it references RFC 5280.

General: 
I would consider stating that server certificates according to this profile
either MUST or SHOULD have the serverAuth EKU set since it is allways
related to the use of TSL and server authentication. At least it MUST be set
when allowing checks of the CN-ID (see 2.3 below).

1.3.2 and section 3
SRVName is described as an extension in 1.3.2, but is in fact a Subject Alt
Name (otherName form) RFC 4985.
This error is repeated in section 3, bullet 4, on page 16.
 
1.1. 
s/an application services/an application service
 
1.2
I find the following text is hard to understand:
³(this document addresses only the DNS domain name of the application
service itself, not the entire trust chain)²
I¹m not sure what the DNS domain name has to do with checking the entire
trust chain. Further, this document discuss more name forms than the DNS
domain name.
Perhaps this sentence was meant to say:
"(this document only addresses name forms in the leaf server certificate,
not any name forms in the chain of certificate used to validate the server
certificate)"

2.3
It would be good if we could restrict the use of CN-ID for storing a domain
name to the case when the serverAuth EKU is set. Requiring the EKU reduce
the probability that the CN-ID appears to be a domain name by accident or is
a domain name in the wrong context.
 
In many deployments, this also affects the name constraints processing to
perform domain name constraints also on the CN attribute.
 
There should at least be a rule stating that any client that accepts the CN
attribute to carry the domain name MUST also perform name constraints on
this attribute using the domain name logic if name constraints is applied to
the path. Failing this requirement poses a security threat if the claimed
domain name in CN-ID violated the name constraints set for domain names.

4.4.3 checking wildcard labels
The restriction to match against only one subdomain seems to not be
compatible with FRC 4592. RFC 4592 states:
 
   A wildcard domain name can have subdomains.  There is no need to
   inspect the subdomains to see if there is another asterisk label in
   any subdomain.
 
Further, I'm pretty sure that the rule of this draft is incompatible with
many deployments of wildcard matching. I recall in Microsoft we allowed any
number of subdomains when I was involved with the CAPI team.

4.6.2 
States:
 
   In this case, the
   client MUSTverify that the presented certificate matches the cached
   certificate and (if it is an interactive client) MUST notify the
   user if the certificate has changed since the last time a secure
   connection was successfully negotiated
 
How does the client know if the certificate has changed or whether it just
obtained an unauthorized certificate?
 
I guess in some cases it would work but I feel sure there are exception
cases where the client just has a configured certificate but no knowledge of
what it obtained the last time it talked to the server.

/Stefan

---

From: Dave Cridland <[email-masked]>
Date: Tue, 14 Sep 2010 08:58:49 +0100

> even if you intended to contact host1.example.com (even if that  
But I don't care about the legitimate hostname. All I care about is  
that my TLS endpoints are me, and the service I wanted. What hostname  
that service happens to be delivered on is entirely immaterial. If I  
*did* care about that, I'd surely also want to verify the IP address,  
and then I'd want to verify the MAC address, and then the CPUID, and  
then...

Surely if an sRVName (or equivalent) fully matches, this is  
sufficient to verify that the contacted host is authorized to provide  
that service for that domain?

> desiganted ldap server and not the xmpp server (even if that  
Kind of. The rules effectively mean that dNSName is treated as a  
sRVName with a wildcard service type, as I understand it.

> verify the dNSName in addition to what else you are checking.

I don't see any time when it's desirable, from a security  
perspective, to check the host name in addition to the service domain  
name.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 14 Sep 2010 16:17:16 -0600

On 9/14/10 1:58 AM, Dave Cridland wrote:
> Kind of. The rules effectively mean that dNSName is treated as a sRVName
> with a wildcard service type, as I understand it.

That's a good way to put it.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2010 10:21:38 -0600

> After the past discussions, the remaining things on my review list are:

Jeff and I would like to thank you for sticking with us as we slowly
work through the feedback we've received. Comments inline.

> include [PKIX] brackets to clarify that it references RFC 5280.

Jeff and I would prefer to define "PKIX" in the terminology section and
then use that definition as the basis for the terms "PKIX-based system"
and "PKIX certificate".

We propose to define "PKIX" as follows:

   PKIX is a short name for RFC 5280 [PKIX], which comprises a
   profile of the X.509v3 certificate specifications and X.509v2
   certificate revocation list (CRL) specifications for use in the
   Internet.

> when allowing checks of the CN-ID (see 2.3 below).

Jeff and I are still discussing this topic and do not yet have editorial
agreement about how to proceed.

> This error is repeated in section 3, bullet 4, on page 16.

Fixed.

> s/an application services/an application service

Fixed.

> not any name forms in the chain of certificate used to validate the server

That's better. Thanks for the text.

> domain name in CN-ID violated the name constraints set for domain names.

See above; Jeff and I are still discussing this topic.

>    inspect the subdomains to see if there is another asterisk label in

Speaking for myself, not for Jeff, I think the entire notion of a
subdomain is suspect and very poorly defined, which is why the XMPP WG
did away with it in rfc3920bis. For example, is foo.co.uk a subdomain of
co.uk? No. And I think we really don't want to pull in a normative
reference to the public suffix list in this specification!

> number of subdomains when I was involved with the CAPI team.

It also seems to me that allowing recursive wildcards (e.g., allowing
*.*.example.com via *.example.com) is a major expansion beyond RFC 2818
or current verification methods.

Jeff would like to check the relevant specifications (all of the specs
in the "Prior Art" appendix) and the previous discussion threads on the
[email-masked] list before coming to a conclusion on this matter.

> obtained an unauthorized certificate?

If the client has lost its cache then it simply needs to proceed as
described under "Case #3: No Match Found, Uncached Certificate".

> what it obtained the last time it talked to the server.

Is your concern about caching the certificate or keeping track of what
the client received the actual "last time" it connected? The mention of
"last time" is meant to ensure continuity of checking, not to force the
client to keep track of particular connection attempts. Therefore in our
working copy we have changed that paragraph to read:

   If the client finds no presented identifier that matches any of the
   reference identifiers but a human user has permanently accepted the
   certificate during a previous connection attempt or via configured
   preferences, the certificate has already been cached.  In this case,
   the client MUST verify that the presented certificate matches the
   cached certificate; if the presented certificate does not match the
   cached certificate then the client MUST proceed as described under
   Case #3 below.

Thanks again for your feedback.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2010 10:33:03 -0600

On 9/16/10 8:15 AM, t.petch wrote:
> ----- Original Message -----
> From: "Peter Saint-Andre" <[email-masked]>
> To: "Stefan Santesson" <[email-masked]>
> Sent: Monday, September 13, 2010 9:16 PM
> 
> <tp>
> Ah, that explains a lot; I knew I smelt a rat, I just did not realise how big it
> was:-) It is fine if you want to nudge Certificate Authorities into issuing
> certs with SRVName but you should put that up front, in the Abstract eg
> "This memo encourages Certificate Authorities to issue certificates with SRVName
> names"
> 
> Otherwise people are likely to expend effort on this memo which will turn out to
> be unproductive; as this thread has established, SRVName do exist, but not in
> many places, which makes this memo of rather limited scope.
> 
> I wondered why the emphasis on server names had grown and grown, in the I-D and
> on this thread, an emphasis which to me seemed a distraction and irrelevance,
> and now I see why; nothing wrong, just needs making this explicit.
> 
> Tom Petch
> 
> </tp>

Thanks for your feedback. As a way of orienting the reader, Jeff and I
are discussing the possibility of adding a section to the introduction
that provides an informational overview of the recommendations contained
in the document.

Peter

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Sep 2010 09:44:13 -0700

>agreement about how to proceed.

This is not editorial, this is definitely technical. What possible advantage is there to making certificates that do not have this flag set be excluded from the practices you are defining? That is, if a TLS client gets a certificate from a TLS server that the TLS server says is its authentication certificate, why should the client care whether or not that flag is set? That flag is an assertion from the CA, not from the server who is authenticating.

> > a domain name in the wrong context.

That makes no sense from an operational standpoint. The inclusion of an EKU has nothing to do with the decision-making for the domain name location.

>> perform domain name constraints also on the CN attribute.

True, and irrelevant.

>> domain name in CN-ID violated the name constraints set for domain names.

Fully disagree.

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2010 11:58:49 -0600

On 9/22/10 10:44 AM, Paul Hoffman wrote:
>>> General: I would consider stating that server certificates
>>> according to this profile either MUST or SHOULD have the
>>> serverAuth EKU set since it is allways related to the use of TSL
>>> and server authentication. At least it MUST be set when allowing
>>> checks of the CN-ID (see 2.3 below).
>> 
>> Jeff and I are still discussing this topic and do not yet have
>> editorial agreement about how to proceed.
> 
> This is not editorial, this is definitely technical. 

Sorry, by "editorial agreement" I meant consensus between the document
editors about how we think it's best to address the issue that Stefan
raised. Jeff and I have discussed many of the issues that have been
raised, but haven't yet had a chance to discuss this one.

> What possible
> advantage is there to making certificates that do not have this flag
> set be excluded from the practices you are defining? That is, if a
> TLS client gets a certificate from a TLS server that the TLS server
> says is its authentication certificate, why should the client care
> whether or not that flag is set? That flag is an assertion from the
> CA, not from the server who is authenticating.
> 
>>> 2.3 It would be good if we could restrict the use of CN-ID for
>>> storing a domain name to the case when the serverAuth EKU is set.
>>> Requiring the EKU reduce the probability that the CN-ID appears
>>> to be a domain name by accident or is a domain name in the wrong
>>> context.
> 
> That makes no sense from an operational standpoint. The inclusion of
> an EKU has nothing to do with the decision-making for the domain name
> location.
> 
>>> In many deployments, this also affects the name constraints
>>> processing to perform domain name constraints also on the CN
>>> attribute.
> 
> True, and irrelevant.
> 
>>> There should at least be a rule stating that any client that
>>> accepts the CN attribute to carry the domain name MUST also
>>> perform name constraints on this attribute using the domain name
>>> logic if name constraints is applied to the path. Failing this
>>> requirement poses a security threat if the claimed domain name in
>>> CN-ID violated the name constraints set for domain names.
> 
> Fully disagree.

Thanks for your input. Our little editors team will take your comments
under advisement during our discussion of this open issue. :)

Peter

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

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 22 Sep 2010 19:36:20 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
> Hoffman
> Sent: Wednesday, September 22, 2010 9:44 AM
> To: Peter Saint-Andre; Stefan Santesson
> Cc: IETF cert-based identity; [email-masked]; [email-masked]
> Subject: [TLS] Why require EKU for certid?
> 
> >> I would consider stating that server certificates according to this
> >> profile either MUST or SHOULD have the serverAuth EKU set since it is
> >> allways related to the use of TSL and server authentication. At least
> >> it MUST be set when allowing checks of the CN-ID (see 2.3 below).
> >
> This is not editorial, this is definitely technical. What possible
advantage is
> there to making certificates that do not have this flag set be excluded
from the
> practices you are defining? That is, if a TLS client gets a certificate
from a TLS
> server that the TLS server says is its authentication certificate, why
should the
> client care whether or not that flag is set? That flag is an assertion
from the CA,
> not from the server who is authenticating.
> 
> > > 2.3
> > > It would be good if we could restrict the use of CN-ID for storing a
> > > domain name to the case when the serverAuth EKU is set. Requiring
> > > the EKU reduce the probability that the CN-ID appears to be a domain
> > > name by accident or is a domain name in the wrong context.
> 
> That makes no sense from an operational standpoint. The inclusion of an
EKU
> has nothing to do with the decision-making for the domain name location.
> 
> > > processing to
> >> attribute to carry the domain name MUST also perform name constraints
> >> on this attribute using the domain name logic if name constraints is
> >> applied to the path. Failing this requirement poses a security threat
> >> if the claimed domain name in CN-ID violated the name constraints set
for
> domain names.

I also agree that this is not something that I would ever like to see as a
required element.  Applying name constraint logic in places that it should
not be performed is something that is very hard on any certificate
evaluation logic.

I think it would be much more an issue of "asking" CAs not to issue
certificates that have this characteristic.

Jim

> 
> 
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Rex <[email-masked]>
Date: Thu, 23 Sep 2010 18:13:44 +0200 (MEST)

>>> domain name in CN-ID violated the name constraints set for domain names.

I do agree with Paul that something is very wrong about this paragraph.

What it seems to request is that dNSName SAN name constraints ought
to be performed on CN-ID if server endpoint identification is
performed with CN-ID.

Since there is a requirement to use (issue) DNS-IDs in server certs,
and a requirement to ignore CN-ID when DNS-ID is present, such a
name constraints processing scheme looks awkward to me.

Name Constraints (and its processing) is something that is specified
in PKIX Internet Certificate and CRL profile (rfc-5280 and its
predecessor rfc-3280) plus some ISO-specs (btw. are these publicly
available anywhere), and that is normally implemented entirely within
the certificate path validation of the PKI software.

The BCP for server endpoint identification with TLS is something,
that according to the last sentence of section 1 of all TLS specs
is a matter of the application on top of TLS.

A CA with name constraints for DNSName SANs (required critical according
to rfc5280, mind you) in its own CA certificate that issues TLS server
certificates without dNSName SANs yields "fubar" on my scorecard.

The support of CN-IDs is "legacy" and retained for backwards
compatibility with the installed base.

Those that need the backwards compatibility will _not_ disable
the matching fallback if DNSName SANs are present, and they're
even more unlikely to adopt such a weird name constraints
processing of a fallback they shouldn't be doing in the 
first place and keep doing only to not interfere with
installed base.

-Martin

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 23 Sep 2010 10:43:50 -0700

On Sep 22, 2010, at 9:44 AM, Paul Hoffman wrote:

>> [..snip..]

> What possible advantage is there to making certificates that do not have this flag set be excluded from the practices you are defining? That is, if a TLS client gets a certificate from a TLS server that the TLS server says is its authentication certificate, why should the client care whether or not that flag is set? That flag is an assertion from the CA, not from the server who is authenticating.

Does this point need discussion?  Without checking, I suspect that 5280 says you obey the EKU, period.  OTOH I think Paul raises a valid point.

OTOH (again) one could argue that the EKU provides a way to prevent a stolen cert/key issued to the machine for a different function from being repurposed to support a fake server.  (I'm not convinced this is significant, but it's something.)

Absent discussion and consensus, I vote for whatever 5280 says, which I suppose is what the current silence on the topic equates to.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 23 Sep 2010 21:10:22 -0400

> name constraints processing scheme looks awkward to me.

[...]

> certificates without dNSName SANs yields "fubar" on my scorecard.

But if by doing that they can issue certificates that clients will
accept for server names the superior CA did not intend, that's a big
security problem.

> the matching fallback if DNSName SANs are present,

NSS doesn't:

https://mxr.mozilla.org/mozilla/ident?i=CERT_VerifyCertName

The idea is that by including a dNSName SAN, the CA opts out of the
backward compatibility.  I don't think anyone issues certificates with
both dNSName SAN and CN with the intent that the CN be honored as a
server name.

> and they're

Those that need backwards compatibility, name constraints, and security
need to do something about this issue.

Some previous discussion:

http://www.ietf.org/mail-archive/web/pkix/current/msg27619.html

-- 
Matt

---

From: Martin Rex <[email-masked]>
Date: Fri, 24 Sep 2010 04:39:29 +0200 (MEST)

> accept for server names the superior CA did not intend, that's a big

No, there is absolutely no security problem involved.

This is a plain and simple liability issue.  If the superior CA
can not manage the risk appropriately so that the issuing CA will
not do this, then either the superior CA MUST NOT certify that
issuing CA, or the clients MUST NOT trust the superior CA.

It is really as simple as that.

Btw. is it completely ridiculous to put Constraints into
certificates for a resource that is managed aribraritly on a
first-come, first-served basis such as DNS hostnames and
think of it as a security feature.

What some entirely fail to understand is that this is about
a backwards compatibility issue with the installed base,
and no amount of praying, cursing and issuing of new Specs with
MUST NOTs in them will change the behaviour of the installed base
in any way or form.

New specs affect only new stuff (implementations and CAs),
and to a very limited amount patches into the installed base,
under the condition that the change DOES NOT BREAK existing
productive usage scenarios.

NameConstraints are ill-designed to support what some people
intend to do with them.  They're specify to constrain only
name components that are present, not name components that
are absent.

Go kick the PKIX folks if you don't like how it is spec'ed,
but leave the apps folks alone.  I believe that asking the apps
folks to regurgitate and re-chew stuff that the PKIX part didn't
process to someone's satisfaction is an _extremely_ bad idea.

As far as Joe Average User is concerned, which of the CAs shipping
in current Browsers does have the alleged security problem anyway?
The way they're specified, NameConstraints are not a security feature,
but rather a means to enforce a business model, because NameConstraints
can no longer securely if there is more than one trust anchor.
TLS as used on the internet is approaching 100 seperate trust anchors...

> both dNSName SAN and CN with the intent that the CN be honored as a

Well no, this is another absolute nonsense, because again it
completely ignores the (behaviour of) the installed base.
The only way to opt out of CN-ID matching is to issue server
certs entirely without CN AVAs in the subject name.
Anything else than CN=f.q.d.n or NO CN AVA is non-sensical.

The only problem with CN-less subject names is, that
it might create serious usability issues with a number of
existing certificate maintenance UIs...

> need to do something about this issue.

I'm not aware of a reasonable justification for the existance
of PolicyConstraints and NameConstraints in certificates other
than governmental agencies and military would like to use it
eventually and still be able to procure on the commodity market.

The situation for ECC crypto is similar.  Although there may
be some usefulness in having alternative algorithm to RSA at some
point in the future when all of the annoying patents have expired.

-Martin

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 24 Sep 2010 01:01:54 -0400

> issuing CA, or the clients MUST NOT trust the superior CA.

Name constraints are designed to support secure delegation of the
ability to issue certificates for a portion of the namespace.  Why
wouldn't CAs use them for that purpose?  Just because you said so?

A certificate that violates a name constraint is invalid, and under any
sane contract or legal system, the superior CA will not be liable to
anyone who relies on an invalid certificate.

> think of it as a security feature.

What exact use case do you speak of?  The typical use case is to give
the owner of a DNS zone the ability to issue certificates for names
within that zone that will validate for the duration of the ownership.

> productive usage scenarios.

Matching a reference server name against a CN-ID that violates a dNSName
constraint defeats the purpose of name constraints.  With respect to
clients willing to do this, a name constraint is a security no-op.

In general, IETF seeks to make the features that it introduces work as
intended.  So it makes complete sense to me that secure handling of name
constraints would be a condition of conformance to the server-id-check
standard.  Old clients that take a useless interpretation of name
constraints can continue to exist, they just can't claim conformance to
the standard, and that's their problem.

NSS now enforces name constraints on the CN-ID
(https://bugzilla.mozilla.org/show_bug.cgi?id=394919) and remains
backward compatible with the web by virtue of the fact that the public
CAs aren't using name constraints yet.  If the CAs start doing so, all
an inferior CA has to do for things to work is to include a dNSName SAN,
which is a SHOULD anyway.

> intend to do with them.

In what way are they ill-designed to support secure delegation of the
ability to issue certificates for a portion of the namespace?

> They're specify to constrain only

What do you mean?

> process to someone's satisfaction is an _extremely_ bad idea.

server-id-check is built on PKIX, not vice versa, so server-id-check is
responsible for the security consequences of the CN-ID that it defines
for the name constraints defined by PKIX.  It has the option to solve
the problem or say "this breaks the security of name constraints and we
know it", which would be laughable for a standard.

> in current Browsers does have the alleged security problem anyway?

None; obviously the CAs won't use a feature that presents a security
problem.  The relevant question is whether they would start using it if
the problem were solved, and that I can't answer.  Those that charge for
each end-entity certificate would certainly charge through the roof to
delegate an entire domain.

> TLS as used on the internet is approaching 100 seperate trust anchors...

No.  All name constraints do is constrain sub-CAs, and they are secure
for that purpose.  PKIX assumes you trust your trust anchors.  If you
don't, that's a problem that has to be solved by other means.
 
> Anything else than CN=f.q.d.n or NO CN AVA is non-sensical.

I'm not sure what installed base you are talking about, but the
interpretation I described is stated in RFC 2818 and followed by all
major browsers.  server-id-check is right to choose it.  But this is a
separate issue from name constraints on the CN-ID.

> eventually and still be able to procure on the commodity market.

I gave one above.  A public CAs can give a DNS zone owner the ability to
issue certificates within the zone without posing a risk to anyone else.

-- 
Matt

---

From: Martin Rex <[email-masked]>
Date: Sat, 25 Sep 2010 05:09:28 +0200 (MEST)

> wouldn't CAs use them for that purpose?  Just because you said so?

Terminology confusion.

Name constraints do not delegate anything.  They authorize
subordinate CA to issuer certs within specific constraints.
And delegation in DNS is represented by DNS "NS" records
and managed by domain registrars.

> anyone who relies on an invalid certificate.

99.999% of TLS server certs are accepted by TLS clients
is absence of contracts between TLS client and issuing CA.

~50% of the installed base of TLS (Windows XP&2003) does not
check vor TLS server cert revocation, although there is probably
no CAs left among those ~100 valid pre-trusted RootCAs that do
not offer CRLs distribution points or OCSP responders.

If there are any relevant contracts involving meaningful liabilities,
it is likely among superior and subordinate CAs.  Even server cert
customers are kept at bay with fancy "Certificate Practice Statements".

> clients willing to do this, a name constraint is a security no-op.

No, it is not.  If there is anything wrong, then it is the
server endpoint identification algorithm that is abusing X.509.

Name Constraints processing, as specified by PKIX, is NONE of the
apps business.  Processing of name constraints is exclusively
the task of the certificate path validation implementation
within the PKI software, and the app doesn't need to know or
care whether and which subtrees were collected while
building the certification path and later processed during
certificate path validation.

> know it", which would be laughable for a standard.

10 years ago, the use of CN-ID has been deprecated by rfc-2818 and
been specified to not be used when DNSName SAN is present.

It seems like a bad idea to massively increase the complexity
of a long deprecated server identification scheme, and in a
fashion that is not only a magnitude more complex, but
also amounts to a gruesome breach of the PKIX architecture.

I'm sorry for having totally missed the TLS&IETF consenus to abandon
subjectAltNames for server-id-check and to resurrect CN-IDs.

There may not be an API in the PKI software for returning to
the app the hierarchy of dNSName name constraints collected while
composing the cert path and processed during cert path validation,
which the app would need for a seconds constraints check
when it decides to try a CN-ID matching fallback.

If doing DNSName constraints checking proactively during cert path
validation should be allowed, then a REALLY big warning label
would be necessary that CN AVAs must either contain a valid f.q.d.n
or be ABSENT from the server cert subject DName to prevent false
negatives (i.e. name constraints violation errors) in those
new TLS implementations that adopt this fancy logic.

> which is a SHOULD anyway.

I think it would be more sensible to let CN-IDs rest in peace and
simply skip the CN-ID matching fallback entirely if the CA cert,
which signed the server cert, contains a name constraints extension.

-Martin

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 25 Sep 2010 16:31:22 -0400

> certificate path validation.

I was making an observation, not discussing blame or design.  Do you
deny the truth of the observation?

> been specified to not be used when DNSName SAN is present.

Unfortunately, CN-IDs are still widely used, and the browser vendors
have little power to push for their eradication.  See:

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

> new TLS implementations that adopt this fancy logic.

Or the server cert can include a dNSName SAN.  In that case, the CN is
not constrained because it is not used for matching anyway.

> which signed the server cert, contains a name constraints extension.

That's another fine option, though it has the same problem 

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 25 Sep 2010 16:33:22 -0400

On Sat, 2010-09-25 at 16:31 -0400, Matt McCutchen wrote:
> [...] That's another fine option, though it has the same problem 

Please disregard this unfinished message.  I am having a problem with
unintentionally hitting my mail client's Send keybinding.  I will send a
corrected version.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 25 Sep 2010 17:32:21 -0400

Unfortunately, CN-IDs are still widely used, and the browser vendors
have little power to push for their eradication.  See
https://bugzilla.mozilla.org/show_bug.cgi?id=552346 .

> also amounts to a gruesome breach of the PKIX architecture.

Yes, this is a really ugly situation, but I think making name
constraints secure should be the first priority.

> subjectAltNames for server-id-check and to resurrect CN-IDs.

That is not what is happening.  SANs have not been abandoned, and CN-IDs
have not been resurrected (they have been carried over from RFC 2818).

> which signed the server cert, contains a name constraints extension.

That's another fine approach, though the NSS behavior has the advantage
of making it possible to cross-certify an existing CA that uses CN-IDs
and apply name constraints, which is a huge win for me.  I deal with
several organizational CAs that I don't want to trust for the entire web
but would gladly cross-certify for their own domains, and currently I am
adding a certificate exception for each server after manual
verification, which is a huge PITA.

So there are four viable approaches:

0. Don't use the CN-ID.
1. Use the CN-ID only if there are no name constraints.
2. Use the CN-ID only if it satisfies the name constraints (if any).
3. Have certificate validation apply name constraints to the CN unless
there are dNSName SANs or it has some other reason to believe that the
CN will not be used as a CN-ID.  (Implemented in NSS.)

#0 is incompatible with much of today's web.  #1 and #2 require the
server ID check to know about name constraints.  #3 risks rejecting
certificates that contain no dNSName SAN and a CN that was not intended
as a CN-ID.

I propose that section 4.4.4 be changed as follows:

Old: "...the client MAY as a fallback check for a string whose form
matches that of a fully-qualified DNS domain name in the CN-ID."

New: "...the client MAY as a fallback check for a string whose form
matches that of a fully-qualified DNS domain name in the CN-ID, provided
that this domain name satisfies any name constraints on the
certification path as defined by [PKIX] section 4.2.1.10."

On a tangent, I'm unhappy with the idea that the server ID check should
be separate from certificate validation, or even implemented in the
application rather than the TLS library.  Applications will screw it up;
I'd rather the TLS library get it right once and provide an API that
accepts the list of reference identifiers and any other flags necessary
to address the needs of applications.  And combining the server ID check
with certificate validation makes it possible (if desired) to apply name
constraints only to the presented identifier that is actually used,
which could be useful in some cross-certification scenarios.

-- 
Matt

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 Sep 2010 14:03:20 -0600

[trimming tls@ and ietf@ from cc list]

On 9/23/10 11:43 AM, Henry B. Hotz wrote:
>>>> serverAuth EKU set since it is allways related to the use of
>>>> TSL and server authentication. At least it MUST be set when
>>>> allowing checks of the CN-ID (see 2.3 below).
>>> 
>>> [..snip..]
>> 
> 
>> What possible advantage is there to making certificates that do not
>> have this flag set be excluded from the practices you are defining?
>> That is, if a TLS client gets a certificate from a TLS server that
>> the TLS server says is its authentication certificate, why should
>> the client care whether or not that flag is set? That flag is an
>> assertion from the CA, not from the server who is authenticating.
> 
> 
> Does this point need discussion?  Without checking, I suspect that
> 5280 says you obey the EKU, period.  OTOH I think Paul raises a valid
> point.
> 
> OTOH (again) one could argue that the EKU provides a way to prevent a
> stolen cert/key issued to the machine for a different function from
> being repurposed to support a fake server.  (I'm not convinced this
> is significant, but it's something.)
> 
> Absent discussion and consensus, I vote for whatever 5280 says, which
> I suppose is what the current silence on the topic equates to. 

This I-D shall never be taken to override anything in RFC 5280 or any
other normatively-referenced specification on which it depends. If folks
think we need a blanket statement to that effect, please let us know.
Version -10 will have a new section containing an applicability
statement, which starts as follows:

   This document does not supersede the rules for certificate validation
   provided in [RFC5280].

But we can always add a stronger statement if need be.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 Sep 2010 15:37:52 -0600

On 9/25/10 3:32 PM, Matt McCutchen wrote:

Cutting to the chase...

> certification path as defined by [PKIX] section 4.2.1.10."

Thank you for proposing text.

Given that the server-id-check document is downstream from RFC 5280,
it's not clear to me why we need to mention that name constraints apply.
I'm especially wondering why this spec would mention name constraints
with respect to CN-IDs but not with respect to DNS-IDs, URI-IDs, or
SRV-IDs, given that Section 4.2.1.10 of RFC 5280 states in part:

   The name constraints extension, which MUST be used only in a CA
   certificate, indicates a name space within which all subject names in
   subsequent certificates in a certification path MUST be located.
   Restrictions apply to the subject distinguished name and apply to
   subject alternative names.

RFC 4985 explicitly mentions name constraints with respect to SRVNames,
but that makes sense because it is defining a new name form for the
subjectAltName extension of type otherName, which is not mentioned in
RFC 3280 / RFC 5280, as mentioned in RFC 5280:

   The syntax and semantics for name constraints for otherName,
   ediPartyName, and registeredID are not defined by this specification,
   however, syntax and semantics for name constraints for other name
   forms may be specified in other documents.

Thus I think this is out of scope for the server-id-check document, but
I'm open to being convinced otherwise (and I'm not yet sure whether my
co-author agrees with me).

Peter

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

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 29 Sep 2010 15:20:58 -0700

Peter,

It was my understanding of this that the request was that the DNS name
constraints be applied to a CN-ID that is being treated as a DN.  This would
not be standard 5280 behavior.

Jim

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Peter Saint-Andre
> Sent: Wednesday, September 29, 2010 2:38 PM
> To: Matt McCutchen
> Cc: [email-masked]
> Subject: Re: [certid] CN-ID and name constraints
> 
> > matches that of a fully-qualified DNS domain name in the CN-ID,
> > provided that this domain name satisfies any name constraints on the
> Given that the server-id-check document is downstream from RFC 5280, it's
not
> clear to me why we need to mention that name constraints apply.
> I'm especially wondering why this spec would mention name constraints with
> respect to CN-IDs but not with respect to DNS-IDs, URI-IDs, or SRV-IDs,
given
> that Section 4.2.1.10 of RFC 5280 states in part:
> 
but
> that makes sense because it is defining a new name form for the
> subjectAltName extension of type otherName, which is not mentioned in RFC
> 3280 / RFC 5280, as mentioned in RFC 5280:
> 
I'm open
> to being convinced otherwise (and I'm not yet sure whether my co-author
> agrees with me).
> 
> Peter
> 
> --
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> certid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/certid

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 Sep 2010 16:24:59 -0600

On 9/29/10 4:20 PM, Paul Hoffman wrote:
> At 2:03 PM -0600 9/29/10, Peter Saint-Andre wrote:
>>>>>> serverAuth EKU set since it is allways related to the use
>>>>>> of TSL and server authentication. At least it MUST be set
>>>> What possible advantage is there to making certificates that do
>>>> not have this flag set be excluded from the practices you are
>>>> defining? That is, if a TLS client gets a certificate from a
>>>> TLS server that the TLS server says is its authentication
>>>> certificate, why should the client care whether or not that
>>>> flag is set? That flag is an assertion from the CA, not from
>>>> the server who is authenticating.
>>> 
>>> 
>>> Does this point need discussion?  Without checking, I suspect
>>> that 5280 says you obey the EKU, period.  OTOH I think Paul
>>> raises a valid point.
>>> 
>>> OTOH (again) one could argue that the EKU provides a way to
>>> prevent a stolen cert/key issued to the machine for a different
>>> function from being repurposed to support a fake server.  (I'm
>>> not convinced this is significant, but it's something.)
>>> 
>>> Absent discussion and consensus, I vote for whatever 5280 says,
>>> which I suppose is what the current silence on the topic equates
>>> to.
>> 
>> This I-D shall never be taken to override anything in RFC 5280 or
>> any other normatively-referenced specification on which it depends.
>> If folks think we need a blanket statement to that effect, please
>> let us know. Version -10 will have a new section containing an
>> applicability statement, which starts as follows:
>> 
>> This document does not supersede the rules for certificate
>> validation provided in [RFC5280].
>> 
> This misses the point I made when I started this thread. 

That's because I was replying only to the small item of whether the
server-id-check can be taken to override RFC 5280.

> Stefan
> proposed a change that would require that only certs that included
> this EKU be considered, you said you would consider that, 

I think I said only that Jeff and I hadn't discussed it yet. It's still
on our todo list.

> and I said
> that would be a bad change. Henry's point did not negate or support
> my proposal.

My sense of the discussion so far is that there's no strong agreement to
accept the proposal that Stefan made.

Peter

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Sep 2010 15:20:54 -0700

>But we can always add a stronger statement if need be.

This misses the point I made when I started this thread. Stefan proposed a change that would require that only certs that included this EKU be considered, you said you would consider that, and I said that would be a bad change. Henry's point did not negate or support my proposal.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 30 Sep 2010 01:20:15 +0200

> accept the proposal that Stefan made.

My point is more that it is good practice to have serverAuth set when the CN
attribute is allowed to carry a DN.

Absent the serverAuth EKU it is hard to programmatically be sure that the CN
actually contains a DNS name. Yes you can probably be pretty sure but there
is just a slight chance for problems due to overloaded semantics.

ServerAuth provides a much cleaner indication than parsing the CN attribute
only. I see potential security problems if a CA allows you to for example
set your CN as a friendly name while other attributes such as givenName and
SureName are checked against your registered name. The friendly name may be
hard to check as it may differ from your registered name (ex Tim Polk).
Thus some not so careful implementation may have poor checks and allow you
to choose a domain name as your friendly name. This certificate may never be
intended to be used for server authentication, but following the rules of
the draft this certificate now allows spoofing and you would never detect
that.

More importantly it has to do with name constraints processing. If you
accept the CN attribute as a domain name you need to make sure that it also
matches any name constraints set for the dNSName of the path. It is much
cleaner again to use the serverAuth as a mechanism for switching in this
logic.

Absent this check, the domain name may violate name constraints and you
would never know. This is the most important point.

/Stefan

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Sep 2010 17:13:01 -0700

>attribute is allowed to carry a DN.

Yes it is. However, that is irrelevant to this document. It would be relevant to a document saying how to create a well-formed server certificate for TLS.

>is just a slight chance for problems due to overloaded semantics.

Even if the serverAuth EKU is set, you cannot be sure the CN actually contains a DNS name. The two are orthogonal.

>the draft this certificate now allows spoofing and you would never detect

See both points above.

>cleaner again to use the serverAuth as a mechanism for switching in this

Then there should be a PKIX document saying this. It is not relevant to a document that tells how to match a domain name the client has in its left hand against the identities in the cert it holds in its right hand.

>would never know. This is the most important point.

If the TLS client is doing full certificate path validation, the certificate cannot violate name constraints. That is quite different than what you just said.

--Paul Hoffman, Director
--VPN Consortium

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Sep 2010 05:24:34 +0200 (MEST)

Paul Hoffman wrote:
> Yes it is. However, that is irrelevant to this document. It would be
> relevant to a document saying how to create a well-formed server
> certificate for TLS.

It is my understanding that the target audience of this document
includes CAs, WebServer Admins, Sysadmins and applications on top of TLS
... however it is a little weak in clarifying to which particular
audience which particular recommendation/imperative applies.

> Even if the serverAuth EKU is set, you cannot be sure the CN actually
> contains a DNS name. The two are orthogonal.

They are independent, correct.  Server endpoint identification has been
performed by SSLv3 clients and TLS v1.0 (rfc-2246) clients based on
CN-IDs exclusively for many years.  rfc-2459 defines an EKU / KeyPurposeId
for TLS Servers and TLS clients http://tools.ietf.org/html/rfc2459#page-39
while the server endpoint identification by dNSName SANs instead of CN-IDs
appears to be first documented in rfc-2818.

Conceptually, every extension that is added to an X.509v3 certificate
further constraints its purpose/applicability (compared to not carrying
the extension).  There are small deviations for the BasicConstraints
defined in PKIX, but basically, that's it.

So a server cert with the TLS id-kp-serverAuth EKU is "limited" to
TLS server auth, not "extended" to it.  AFAIK there are also two
private OIDs from Netscape and two from Microsoft with the same
meaning as id-kp-serverAuth and id-kp-clientAuth.  And I would not
rely on clients being strict in checking TLS server EKUs...

> >cleaner again to use the serverAuth as a mechanism for switching in this

EKUs primarily affect usage scenarios that are born with EKU requirements,
rather than SSL&TLS clients and servers, where the EKU situation
started as a big mess and the current status is fairly undetermined.

> If the TLS client is doing full certificate path validation, the
> certificate cannot violate name constraints. That is quite different
> than what you just said.

As defined by PKIX, name constraints defined for dNSName SANs do not
apply to directoryNames such as a certificate subject.

Some people are trying to artificially redefine the semantics of
name constraints to ensure business models of CAs coming preconfigured
as trusted with the software.  They're asking TLS clients for a gruesome
breach of the PKIX name constraints architecture to "protect" against
CAs from evading "dNSName SAN name constraints" imposed by their
superiorCAs by issuing server certs without dNSName SANs
(and CN-IDs instead, to which dNSName SAN name constraints do no apply).

I think it is an extremely bad idea to increase the complexity of
CN-ID server-id-check semantics, which have been deprecated 10 years ago,
by the order of a magnitude -- in particular in a BCP document,
because most of the installed base does not work that way and
a huge part of them is quite unlikely to ever adopt such weird
CN-ID semantics.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 30 Sep 2010 08:36:58 +0200

On 10-09-30 2:13 AM, "Paul Hoffman" <[email-masked]> wrote:

> Yes it is. However, that is irrelevant to this document. It would be relevant
> to a document saying how to create a well-formed server certificate for TLS.
> 

You are correct. But IF you accept the domain name from the CN attribute and
the serverAuth, you do at least know that the certificate is issued to a TLS
server endpoint. It thus holds the name of a TLS server.

>> the draft this certificate now allows spoofing and you would never detect
See point above.

You can't possibly mean that the risk of spoofing is the same regardless of
whether serverAuth is checked.

> Then there should be a PKIX document saying this. It is not relevant to a
> document that tells how to match a domain name the client has in its left hand
> against the identities in the cert it holds in its right hand.
> 

AFAIK there is no PKIX document supporting the use of CN to carry a domain
name. This is a non standard practice.

> If the TLS client is doing full certificate path validation, the certificate
> cannot violate name constraints. That is quite different than what you just
> said.
> 

That is just a game with words Paul. Of course the certificate does not
violate name constraints. It is the USE of the certificate that violates the
name constraints of the path.

CA-X in the path has stated "You can only rely on this CA certificate to
validate claims about domain names within the example.com namespace"

If the end certificate holds the domain name "foo.com" in the CN, But no
dNSName SAN, and you accept this claim then you are in fact trusting the
CA-X certificate beyond its declared scope.

This document is about best current practice right?

I'm not an advocate for hopelessly rigid requirements and I do respect
legacy. But I think it is reasonable to at least recommend clients to check
any domain name against dNSName name constraints regardless of what
attribute they pulled that information from. I also think it would be good
practice to not blindly accept domain names from any attribute unless you
have some indication that it is likely to hold a domain name.

A large percentage of installed TLS clients perform these checks, so it is
not taken from nowhere.

I don't think we can create perfect, but we could limit the risks with
reasonable recommendations.

/Stefan

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 30 Sep 2010 12:59:07 -0600

> a huge part of them is quite unlikely to ever adopt such weird

Agreed.

As I see it, the Common Name is just a series of characters. Sometimes
that series happens to contain one or more instances of the "."
character, arrayed in a way that leads people to interpret the series of
characters as a DNS domain name. That doesn't mean that it's sensible to
take the PKIX name constraints that have been defined for the dNSName
SAN and apply those constraints to a series of characters that happens
to look like and be interpreted as a DNS domain name.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 30 Sep 2010 13:12:59 -0600

> server endpoint. It thus holds the name of a TLS server.

Right, you are interpreting the contents of the CN as a domain name. The
question is: should the name constraints that apply to dNSName also
apply to the contents of the CN (which are conventionally interpreted as
a domain name if they have a "." somewhere in the middle)?

Agreed.

> reasonable recommendations.

In current practice, people are treating certain kinds of strings from
the CN as domain names. Whether that is *best* current practice is
another matter. :)

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 30 Sep 2010 13:28:22 -0600

> not be standard 5280 behavior.

That's a nice short summary of the issue. It seems to me that defining
such behavior might be within scope for an update to RFC 5280, but not
for the server-id-check document (since it is by no means intended to
update RFC 5280!).

Peter

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

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 30 Sep 2010 12:56:36 -0700

I would consider this to be an application specific behavior and not part of the general validity processing that would be part of 5280.  If it was to happen anyplace I think this is where it should be recommended.

I don't however believe that it should necessarily be recommended anywhere as a practice.

jim

> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Thursday, September 30, 2010 12:28 PM
> To: Jim Schaad
> Cc: 'Matt McCutchen'; [email-masked]
> > constraints be applied to a CN-ID that is being treated as a DN.  This
> > would not be standard 5280 behavior.
> 
> That's a nice short summary of the issue. It seems to me that defining such
> behavior might be within scope for an update to RFC 5280, but not for the
> server-id-check document (since it is by no means intended to update RFC
> 5280!).
> 
> Peter
> 
> --
> Peter Saint-Andre
> https://stpeter.im/

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 30 Sep 2010 15:52:52 -0400

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jim Schaad
> Sent: Thursday, September 30, 2010 3:57 PM
> To: 'Peter Saint-Andre'
> Cc: [email-masked]
> I would consider this to be an application specific behavior and not
> part of the general validity processing that would be part of 5280.
If
> it was to happen anyplace I think this is where it should be
> recommended.

As a means of enabling this type of processing, RFC 5280 could be
amended to output name constraints state similar to the way policy state
is output now.