Subject: [certid] What DNS-ID if also using a DNS-SRV?

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Jun 2010 17:07:50 -0700

1.  The certificate MUST include a "DNS-ID" (i.e., a subjectAltName
       identifier of type dNSName).

   2.  If the service using the certificate deploys a technology in
       which a server is discovered by means of DNS SRV records
       [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate
       SHOULD include an "SRV-ID" (i.e., an instance of the SRVName form
       of otherName from the GeneralName structure in the subjectAltName
       as specified in [SRVNAME]).

If 2 is true, what is the value of the required DNS-ID?

--Paul Hoffman, Director
--VPN Consortium

---

From: Shumon Huque <[email-masked]>
Date: Fri, 11 Jun 2010 21:32:49 -0400

> If 2 is true, what is the value of the required DNS-ID?

I don't think (1) is correct. If someone intends to deploy a 
certificate with an application specific name form such as SRV-ID 
or URI-ID, then they typically would not want to have a dNSName 
in the certificate, to make sure that the cert can't be (mis)used 
for unrelated application services at that domain name. 

Of course one might decide to include dNSName too for transition
or backwards compatibility reasons. But I don't think that saying 
the certificate MUST include a dNSName is correct.

--Shumon.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 19 Jun 2010 12:36:01 +0100

Hi Paul,

>If 2 is true, what is the value of the required DNS-ID?
One or more hostname for machines that would provide the specified 
service. I.e. most likely some/all hostnames from the output of DNS SRV 
lookup, but I can think of some examples where other hostnames can be 
used in addition to or instead of these. E.g. a machine on internal 
network, hostname of a NAT box, etc.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Jun 2010 07:04:45 -0700

At 12:36 PM +0100 6/19/10, Alexey Melnikov wrote:
>One or more hostname for machines that would provide the specified service. I.e. most likely some/all hostnames from the output of DNS SRV lookup, but I can think of some examples where other hostnames can be used in addition to or instead of these. E.g. a machine on internal network, hostname of a NAT box, etc.

So a cert says "the hostname of this server is www.example.com, and you can look up the hostname for the server using SRV"? What does that mean in a security context? If I get back one name of yyy.example.com, does that mean that the host has both names, or that there was a lookup error?

--Paul Hoffman, Director
--VPN Consortium

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Jun 2010 20:01:47 +0100

Hi Paul,

Paul Hoffman wrote:

>So a cert says "the hostname of this server is www.example.com, and you can look up the hostname for the server using SRV"? What does that mean in a security context?
>
This is a good question and it took me some time to gather thoughts on 
how to reply to it.

>If I get back one name of yyy.example.com, does that mean that the host has both names, or that there was a lookup error?
>  
>
In general it can be either, or neither. I don't think one can draw any 
conclusion. Let me try to do a more detailed explanation on how this is 
supposed to work (at least with the current version of the document):

Let's say we have a certificate with (I might be getting the syntax 
wrong, but you should get the idea of what I mean)

dNSName: imap.example.com
sRVName: _imap._tcp.example.com

I've change www.example.com to imap.isode.com, as there is now a 
specification about how to use DNS SRV for locating IMAP servers. But 
the idea applies to other services.

So the document says that a client using DNS SRV must check sRVName 
first. Only if sRVName is not found, then it can check the dNSName.
So a client doing DNS SRV lookup for service "imap" for domain 
"example.com" wouldn't care if the returned hostname is imap.example.com 
or yyy.example.com.

Another client which is explicitly configured with hostname will only 
check the dNSName value and will not check any sRVName values.

There might be several reasons why DNS SRV might return something 
different from "imap.example.com": different hostnames used on internal 
and external networks (due to NATs), clustering, etc. So clients 
shouldn't automatically check if sRVName resolves to one or more of 
dNSName values specified in the same certificate.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 29 Jun 2010 15:29:25 -0600

> the certificate MUST include a dNSName is correct.

Shumon, I think you are correct here, and that DNS-ID needs to be
"SHOULD" instead of "MUST".

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 29 Jun 2010 15:49:38 -0600

On 6/19/10 8:04 AM, Paul Hoffman wrote:
>>> 1.  The certificate MUST include a "DNS-ID" (i.e., a
>>> subjectAltName identifier of type dNSName).
>>> 
>>> SHOULD include an "SRV-ID" (i.e., an instance of the SRVName
>>> form of otherName from the GeneralName structure in the
>>> subjectAltName as specified in [SRVNAME]).
>>> 
>> service. I.e. most likely some/all hostnames from the output of DNS
>> SRV lookup, but I can think of some examples where other hostnames
>> can be used in addition to or instead of these. E.g. a machine on
>> internal network, hostname of a NAT box, etc.
> 
> So a cert says "the hostname of this server is www.example.com, and
> you can look up the hostname for the server using SRV"? What does
> that mean in a security context? If I get back one name of
> yyy.example.com, does that mean that the host has both names, or that
> there was a lookup error?

My understanding of the SRVName extension is that it is primarily
intended to restrict the use of a certificate to a particular
application type (e.g., IMAP or XMPP). This is what Shumon meant when he
said:

   If someone intends to deploy a certificate with an
   application specific name form such as SRV-ID or URI-ID,
   then they typically would not want to have a dNSName in
   the certificate, to make sure that the cert can't be
   (mis)used for unrelated application services at that
   domain name.

However, DNS SRV records have the property of enabling you to redirect
the source domain (e.g., example.com) to a target domain (e.g.,
apps.example.net) that is outside of the trust boundary of the source
domain. Thus draft-daboo-srv-email says:

   A malicious attacker with access to the DNS server data, or able to
   get spoofed answers cached in a recursive resolver, can potentially
   cause MUAs to connect to any IMAP, POP3 or submission server chosen
   by the attacker.  In the absence of a secure DNS option, MUAs SHOULD
   check that the target FQDN returned in the SRV record matches the
   original service domain that was queried.  If the target FQDN is not
   in the queried domain, MUAs SHOULD verify with the user that the SRV
   target FQDN is suitable for use before executing any connections to
   the host.

During recent discussions within the XMPP WG, we decided that we didn't
need text along those lines because a malicious attacker with access to
the DNS server data could simply return an evil IP address in a DNS
result, so why bother the user with scary warnings about a DNS SRV mismatch?

It's unfortunate that RFC 4985 glosses over the difference between (1)
the use of SRVName extensions to restrict deployment to a particular
application type and (2) the use of DNS SRV records to redirect a source
domain to a target domain that might be outside the trust boundary of
the source domain.

It might be appropriate for draft-saintandre-tls-server-id-check to have
some text about this, and I'll try to write that soon.

Peter

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 29 Jun 2010 17:18:47 -0700

At 3:29 PM -0600 6/29/10, Peter Saint-Andre wrote:
>Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030002010403050803000801"
>

This is a very significant change to the document. Please give us all a chance to see all the edits in the next round before you consider the doc read for Last Call.

Personally, no MUST but a pile of orthogonal SHOULDs seems like a bad idea if you are wanting this doc to cause more interoperability.

At 4:16 PM -0600 6/29/10, Peter Saint-Andre wrote:
>I think this list is leaning toward saying that DNS-ID is a SHOULD, not
>a MUST, so the quoted text would be appropriate.

Only "appropriate" if you want no MUSTs. Some us would prefer MUSTs to mush.

--Paul Hoffman, Director
--VPN Consortium

---

From: Shumon Huque <[email-masked]>
Date: Wed, 30 Jun 2010 00:09:35 -0400

>    (mis)used for unrelated application services at that

Yup, that's what I meant ..

> result, so why bother the user with scary warnings about a DNS SRV mismatch?

Yeah, I think I agree with that.

> domain to a target domain that might be outside the trust boundary of

I'm not sure I see a problem here. So what if the domain name of 
the SRV owner (LHS) is in a different administrative domain than 
the domain name in the rdata of the SRV record (RHS)? The TLS certificate
matching function should only be considering the first one. It
can't trust the resolved name unless the lookup was authenticated
anyway (with DNSSEC), or the resolved name was explicitly trusted by
static local configuration. I assume the use case is hosting
providers, eg.

  _imap._tcp.example.com  IN SRV 10 10 143  mail.hostingprovider.com

All the client needs to do is authenticate the certificate associated 
with the identity on the left side (eg. SRVName of _imap.example.com 
or dNSName of example.com etc). mail.hostingprovider would have to be 
configured with that certificate (with the co-operation of example.com). 
If the client gets redirected to connect to mail.evil.com by a DNS attack, 
the client will fail to authenticate the name on the left side (unless 
the attacker has also stolen the cert and key).

--Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 30 Jun 2010 00:31:58 -0400

> Only "appropriate" if you want no MUSTs. Some us would prefer MUSTs to mush.

Let's concentrate on the MUST/SHOULD applicability for the four
identity types discussed in this document:

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

      *  DNS-ID = a subjectAltName identifier of type dNSName

      *  SRV-ID = the SRVName form of otherName from the GeneralName
         structure in SubjectAltName

      *  URI-ID = a subjectAltName identifier of type
         uniformResourceName

I don't think any of them are a MUST. It depends upon the details
of the application service.

If a service deployer is using SRV-ID or URI-ID, then presumably
they want to restrict the use of the certificate to a specific
application at a domain name. In that case SHOULD is not appropriate 
for DNS-ID or CN-ID. In fact, you can argue that they SHOULD NOT 
use either of those more generic forms (unless it is for backwards
compatibility).

For folks who are using straight domain names rather than the
application specific forms (probably the vast majority, at least
initially), and we want to deprecate CN-ID and steer them towards
DNS-ID, then I agree that DNS-ID can be a SHOULD. I don't think 
it can be a MUST today -- there are probably many certificate
issuers that can't deal with anything other than CN.

So, if we want to attach a SHOULD to DNS-ID, it should be a 
conditional one (the condition being that application specific 
name forms like SRV and URI aren't being used).

-- 
Shumon Huque
University of Pennsylvania.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 30 Jun 2010 08:13:53 -0700

>      *  URI-ID = a subjectAltName identifier of type

Agree.

>name forms like SRV and URI aren't being used).

I agree that we have to look at the details of the service. To me, there are two types of names:
- direct (CN-ID, DNS-ID, and URI-ID)
- indirect (SRV-ID)
If they are all SHOULD, and we don't say when one should not mix and match, we haven't helped interoperability. I think instead, we need something like "MUST have either one or more of (CN-ID, DNS-ID, and URI-ID), or SRV-ID". This would be followed by "if the cert has an SRV-ID, it SHOULD NOT have any of (CN-ID, DNS-ID, and URI-ID) because the meaning of combination of what is received from the SRV lookup and the given DNS names is undefined."

Does that sound reasonable?

--Paul Hoffman, Director
--VPN Consortium

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Jun 2010 17:51:58 +0200 (MEST)

> >      *  URI-ID = a subjectAltName identifier of type

Me2.

> If they are all SHOULD, and we don't say when one should not mix and
> match, we haven't helped interoperability. I think instead, we need
> something like "MUST have either one or more of (CN-ID, DNS-ID,
> and URI-ID), or SRV-ID". This would be followed by "if the cert has an
> SRV-ID, it SHOULD NOT have any of (CN-ID, DNS-ID, and URI-ID) because
> the meaning of combination of what is received from the SRV lookup
> and the given DNS names is undefined."
> 

I think this covers only part of the picture.

Describing what certs should have and should not have may be interesting
to CA-operators and admins, but seems to apply to new designs only,
and not allow for migration.

I would appreciate guidance for the implementors.  And at that point
we will have to get rid of that "is undefined" entirely -- i.e. we will
have to specify exactly what is supposed to happen if more than one
identifier is present.

While CN-ID and DNS-ID have exactly the same scope (hostname)
SRV-ID and URI-ID have a more restrictive scope.  Does a combination
make sense?  Or do we expect that to happen only during migration
from a currently used CN-ID or DNS-ID to a SRV-ID or URI-ID?
Keep in mind that "flag days" where the _entire_ installed base is taken down,
changed/updated and put back up, are difficult and rare in practice.

Should CN-ID or DNS-ID be entirely ignored when SRV-ID or URI-ID is
found and understood/used by a client for server endpoint identification?
in the sense that SRV-ID and URI-ID supersede CN-ID or DNS-ID for the
clients which understand them?

The migration scenario that worries me slightly is that were the CA
supports adding features that the installed base doesn't support yet.
It could happen that incorrect "new" stuff is added, and as long as
noone checks the new stuff, this problem is not noticed.  But as soon
as the first component is updated to understand this cert attribute,
the fact that its incorrect is likely to result in an interop problem
if the updated component is "strict" in checking of the new feature.

When adding new features with a patch to the installed base,
I therefore tend to be tolerant.

-Martin

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 30 Jun 2010 09:27:06 -0700

Paul, all

> Does that sound reasonable?

I think that both "direct" and "indirect" SHOULD be allowed at the same time.

The reason is that if you have a client that supports SRV lookups, in for example jabber, then you want to have the SRV name in there so the client can match the server cert with what the user typed.

Of course there are jabber clients out there that don't support SRV lookup and want to to the normal direct mappings rules.

Since the server doesn't really know what client they talk to it need to hand out a cert that matches both rules -> must hAve both for interop reasons.

So the direct names are not used for intermediate values, they are only used with names what comes/is derived user input.

Love

Skickat från min iPhone

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 30 Jun 2010 11:18:10 -0700

>So the direct names are not used for intermediate values, they are only used with names what comes/is derived user input.

Unfortunately, I agree with this logic. I say "unfortunately" because it means that we then don't have a MUST, and therefore lose interoperability. For sanity, the document needs to say why it is OK to have both direct and indirect and what to do when they are both there, but I agree that we can't say MUST have only one.

--Paul Hoffman, Director
--VPN Consortium

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 30 Jun 2010 19:34:43 +0100

Paul Hoffman wrote:

>Unfortunately, I agree with this logic.
>
I agree with this logic too (without "unfortunately" ;-)).

>I say "unfortunately" because it means that we then don't have a MUST, and therefore lose interoperability. For sanity, the document needs to say why it is OK to have both direct and indirect and what to do when they are both there, but I agree that we can't say MUST have only one.
>  
>
I think a document specifying how to perform TLS server identity 
verification for a particular protocol can specify if only one of them 
can be allowed (and which one), or if both can be allowed. This 
addresses interoperability for a particular protocol.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 30 Jun 2010 12:43:32 -0600

Warning: tangent.

> the attacker has also stolen the cert and key).

Correct. Here's the rub:

   mail.hostingprovider would have to be configured with that
   certificate (with the co-operation of example.com).

In most cases, the admins of example.com don't want to trust
hostingprovider.com with their private keys, and the admins of
hostingprovider.com don't want the legal liability of holding private
keys for example.com either. In the XMPP community we have been working
on a solution to this problem (see draft-ietf-xmpp-dna), but the problem
applies more generally (IMAP, etc.) and is becoming more urgent with the
spread of hosted applications. Richard Barnes has coined the term "High
Assurance Re-Direction" ("HARD") for this problem. He and I have been
planning to write an I-D that describes this "HARD problem", but it's
becoming increasingly unlikely that we'll meet the I-D cutoff before
Maastricht.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 30 Jun 2010 12:54:26 -0600

On 6/30/10 12:34 PM, Alexey Melnikov wrote:
>>> The reason is that if you have a client that supports SRV lookups, in
>>> for example jabber, then you want to have the SRV name in there so
>>> the client can match the server cert with what the user typed.
>>>
>>> Of course there are jabber clients out there that don't support SRV
>>> lookup and want to to the normal direct mappings rules.
>>>
>>> Since the server doesn't really know what client they talk to it need
>>> to hand out a cert that matches both rules -> must hAve both for
>>> interop reasons.
>>>
>>> So the direct names are not used for intermediate values, they are
>>> only used with names what comes/is derived user input.
>>>   
>> I say "unfortunately" because it means that we then don't have a MUST,
>> and therefore lose interoperability. For sanity, the document needs to
>> say why it is OK to have both direct and indirect and what to do when
>> they are both there, but I agree that we can't say MUST have only one.
>>  
>>

I would dearly like to say "MUST use DNS-ID" so that we have a baseline
for interoperability across all application protocols. However, it seems
that the best we can do is interoperability for a given application
protocol (HTTP, IMAP, SIP, XMPP, etc.). That saves the kind of
interoperability people really care about, but it does make life a bit
more complicated for certification authorities and makes this BCP less
clean. Unfortunately, reality is messy...

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 30 Jun 2010 13:53:03 -0600

On 6/30/10 12:18 PM, Paul Hoffman wrote:
>> The reason is that if you have a client that supports SRV lookups,
>> in for example jabber, then you want to have the SRV name in there
>> so the client can match the server cert with what the user typed.
>> 
>> Since the server doesn't really know what client they talk to it
>> need to hand out a cert that matches both rules -> must hAve both
>> for interop reasons.
>> 
> Unfortunately, I agree with this logic. I say "unfortunately" because
> it means that we then don't have a MUST, and therefore lose
> interoperability. For sanity, the document needs to say why it is OK
> to have both direct and indirect and what to do when they are both
> there, but I agree that we can't say MUST have only one.

Upon further reflection, I think there are two dimensions here:

1. From the client's perspective, some names are direct (provided by the
user = DNS-ID, CN-ID, URI-ID) and some names are indirect (resolved by
the client based on the input provided by the user = SRV-ID). This
dimension matters for verification.

2. From the service provider's persective, some names are unrestricted
(can be used in any application = DNS-ID and CN-ID) and some names are
unrestricted (can be used in only one kind of application = SRV-ID and
URI-ID). This dimension matters for issuance.

I'll work to formulate this distinction more carefully in text that can
be included in the spec.

Peter

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 30 Jun 2010 13:00:32 -0700

>URI-ID). This dimension matters for issuance.

That should be "...and some names are restricted (can be used in only...". But, yes, this is a good distinction.

>I'll work to formulate this distinction more carefully in text that can

That would help implementers (and hopefully CAs) a lot.

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 30 Jun 2010 16:01:05 -0600

On 6/30/10 2:00 PM, Paul Hoffman wrote:
>> 1. From the client's perspective, some names are direct (provided
>> by the user = DNS-ID, CN-ID, URI-ID) and some names are indirect
>> (resolved by the client based on the input provided by the user =
>> SRV-ID). This dimension matters for verification.
>> 
>> 2. From the service provider's persective, some names are
>> unrestricted (can be used in any application = DNS-ID and CN-ID)
>> and some names are unrestricted (can be used in only one kind of
>> application = SRV-ID and URI-ID). This dimension matters for
>> issuance.
> 
> That should be "...and some names are restricted (can be used in
> only...". 

Typing too fast here. :)

> But, yes, this is a good distinction.
> 
>> I'll work to formulate this distinction more carefully in text that
>> can be included in the spec.
> 

Here is a first draft...

###

2.1.  Naming Applications

   This specification assumes that an Internet application is named
   based on a DNS domain name (e.g., "example.com") -- supplemented in
   some circumstances by an application type (e.g., "the IMAP server at
   example.com").

   From the perspective of the application client or user, some names
   are direct because they are provided directly by the user (e.g., via
   runtime input or prior configuration) whereas other names are
   indirect because they are resolved by the client based on input
   provided by the user (e.g., a target name resolved from a source name
   using DNS SRV records).  This dimension matters for certificate
   verification.

   From the perspective of the application server or service provider,
   some names are unrestricted because they can be used in any kind of
   application (e.g., a certificate might be re-used for both the HTTP
   service and the IMAP service at example.com) whereas other names are
   restricted because they can be used in only one kind of application
   (e.g., a special-purpose certificate that can be used only for an
   IMAP service).  This dimension matters for certificate issuance.

   Therefore:

   o  A CN-ID identifier is direct (provided by a user) and unrestricted
      (can be used for any application).
   o  A DNS-ID identifier is direct (provided by a user) and
      unrestricted (can be used for any application).
   o  An SRV-ID identifier is indirect (resolved by a client) and
      restricted (can be used for only a single application).
   o  A URI-ID identifier is direct (provided by a user) and restricted
      (can be used for only a single application).

   We summarize this taxonomy in the following table.

   +-----------+-----------+---------------+
   |           |  Direct   |  Restricted   |
   +-----------+-----------+---------------+
   |  CN-ID    |  Yes      |  No           |
   +-----------+-----------+---------------+
   |  DNS-ID   |  Yes      |  No           |
   +-----------+-----------+---------------+
   |  SRV-ID   |  No       |  Yes          |
   +-----------+-----------+---------------+
   |  URI-ID   |  Yes      |  Yes          |
   +-----------+-----------+---------------+

   When implementing software, deploying services, and issuing
   certificates for secure PKIX-based authentication, it is important to
   keep these distinctions in mind.  In particular, best practices
   differ somewhat for application server implementations, application
   client implementations, service providers, and certification
   authorities.  Protocol specifications that reference this document
   MUST specify which identifiers are mandatory-to-implement by servers
   and clients, which identifiers are to be preferred by service
   providers, and which identifiers ought to be supported by certificate
   issuers.  Because these requirements differ across applications, it
   is impossible to categorically stipulate universal rules (e.g., that
   all software implementations, service providers, and certification
   authorities for all application protocols need to use or support DNS-
   IDs as a baseline for the purpose of interoperability); however, it
   is preferable that each application protocol will at least define a
   baseline that applies to the community of software developers,
   service providers, and CAs actively using or supporting that
   technology.

###

---

From: Martin Rex <[email-masked]>
Date: Thu, 1 Jul 2010 01:29:33 +2600 (MEST)

Actually, _some_ of the PKIX-heavy APPS might want to restrict
usability of server certificates by "extendedKeyUsage" in addition
to what we define as server endpoint identification here.

The wording in rfc-5280 section 4.2.1.12 appears a self-contradictory
to me, because it conditionalizes "MUST only" with "applications MAY do
whatever they see fit", and application negligence is likely to be
the norm.  And btw. how "applications MAY" is used it refers to
individual implementations and such an interpretation aligns well
with the more easily understandable text in rfc-2459.

   If the extension is present, then the certificate MUST only be used
   for one of the purposes indicated.  If multiple purposes are
   indicated the application need not recognize all purposes indicated,
   as long as the intended purpose is present.  Certificate using
   applications MAY require that the extended key usage extension be
   present and that a particular purpose be indicated in order for the
   certificate to be acceptable to that application.

-Martin

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 30 Jun 2010 21:02:02 -0400

On 2010-06-30 14:43, Peter Saint-Andre wrote:
> keys for example.com either.
But mail.hostingprovider never needs the private keys for example.com - 
all they need is a cert signed by example.com.  The TLS client can tell 
hostingprovider which cert to present, so they can have different ones 
for each client (of course, mine doesn't do that, but they could).

---

From: Shumon Huque <[email-masked]>
Date: Thu, 1 Jul 2010 00:55:57 -0400

[...]
> - direct (CN-ID, DNS-ID, and URI-ID)

On Wed, Jun 30, 2010 at 04:01:05PM -0600, Peter Saint-Andre wrote:
[...]
>       (can be used for only a single application).

I'm not sure I buy this classification. I was trying to figure out
what Paul meant by "direct" and "indirect" - it looks like direct
means "provided by client" and indirect means "DNS resolution
was involved". In that sense I don't see any distinct category for
SRV-ID. The information in the SRV-ID *is* provided by the client.
If the client is attempting to connect to the IMAP service at
example.com, it already has all the information to construct the
SRV identity (_imap.example.com) - no DNS resolution was involved.

DNS resolution is involved in all 4 of these identity types in order
to get the network layer address of the server for connection 
establishment purposes. This should be differentiated from the identity
of the server used for TLS/PKIX authentication. CN-ID, DNS-ID, URI-ID
will involve A, AAAA DNS resolutions. And don't forget that they might
also involve aliases (CNAMEs).

The more meaningful classification to me involves the difference 
between generic domain name identities (CN-ID, DNS-ID) and application 
specific identities (SRV-ID, URI-ID).

(Actually URI-ID can be even more granular, by also specifying a
particular resource/path within an application, but I don't think
we want to deal with that in this draft -- to manage the scope of
this draft, maybe we need to constrain the format of URIs that we
are addressing).

--Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 1 Jul 2010 01:05:59 -0400

> changed/updated and put back up, are difficult and rare in practice.

My take is the combination makes sense primarily for migration
periods (which might be long in some cases).

> clients which understand them?

Yes, I think so. I think the draft already specifies a preference
order putting SRV-ID and URI-ID ahead of the DNS-ID/CN-ID.

--Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 1 Jul 2010 01:24:20 -0400

>    certificate to be acceptable to that application.

Yeah, I was actually waiting to see who brings this up first! :-)

A smaller group of us had discussions about this (via private e-mail
prior to the certid list being set up). I'm sure the others will chime
in with their thoughts. But our general impression is that KU/EKU
are very poorly understood. Some of my principal concerns with using
them for application restriction are that the current ones aren't 
defined precisely enough. Ideally you need a new EKU for every new 
application protocol for proper security compartmentalization. Also 
they depend on a more complicated set of things happening correctly 
on both the server and client side. The client has to perform an 
additional step in addition to matching the subject identity. And 
actually to ensure that the use of the cert is being constrained, the 
EKU extension has to be marked critical (which I think breaks some
modes of migration) - assuming of course that client software rejects 
the cert if they don't understand the EKU extension, which may not be
a true assumption for the deployed base of software.

--Shumon.