Subject: Re: [certid] Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standard

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 23 Jul 2010 09:25:43 -0600

Sorry, I haven't yet had a chance to review the feedback that's been
provided during this Last Call. I'll do that en route to Maastricht
today. Next week Jeff and I will discuss in person the points that have
been raised, and then we'll post further regarding our proposed changes
to the spec.

Peter

On 7/15/10 5:08 PM, The IESG wrote:
> The IESG has received a request from an individual submitter to consider 
> the following document:
> 
> - 'Representation and Verification of Domain-Based Application Service 
>    Identity in Certificates Used with Transport Layer Security '
>    <draft-saintandre-tls-server-id-check-08.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2010-08-12. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-08.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18634&rfc_flag=0
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Shumon Huque <[email-masked]>
Date: Thu, 29 Jul 2010 23:44:16 -0400

Peter,

I'm not sure if this one is already on your list or not, but I
didn't see it addressed in -08:

I don't think the characterization of SRV-ID as an "indirect"
(ie. DNS resolved) identifier is correct.

Whether a subject name is indirect or not, depends on the content
of the identifier field and how that content was obtained, rather 
than on the identifier type itself.

In most cases, indirect identifiers will be found in DNS-ID or CN-ID, 
as a result of DNS resolution of SRV, CNAME, or other records. If an 
application is trying to authenticate such identities, then the 
document needs to clearly state under what conditions it is safe to 
do so (DNSSEC, or a static mapping rule in the client). The document
does touch on safe derivation rules later (currently in 4.2). But the
direct/indirect classification of identity types needs to be 
corrected (or just eliminated).

I said some more here:

    http://www.ietf.org/mail-archive/web/certid/current/msg00220.html

-- 
Shumon Huque
University of Pennsylvania.

On Fri, Jul 23, 2010 at 09:25:43AM -0600, Peter Saint-Andre wrote:
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

-- 
Shumon Huque
University of Pennsylvania.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 30 Jul 2010 07:49:51 +0200

On 07/30/2010 05:44 AM, Shumon Huque wrote:
>   But the
+1
>      http://www.ietf.org/mail-archive/web/certid/current/msg00220.html

You seems to say there that the text basically nails down to two
different id types, the dns based one (which is used in a very
prominent uri using application, i.e. https), and URI-id types.

It is a little bit difficult to have several certificates with
different URI ids sharing the same ipaddress+port.
tls servername indication has not provision for this.
If one cannot have ids with different paths, what's the
beef having a path in an identifier?.

What also seems missing is a paragraph on what
happens before the server presents its certificate, i.e.
what means does have the client to direct the server,
ip-address:port to connect and fqdn in the servername
indication at least.

ah, I forgot dtls?

/P

---

From: Shumon Huque <[email-masked]>
Date: Fri, 30 Jul 2010 12:20:31 -0400

> prominent uri using application, i.e. https), and URI-id types.

Well that, and SRVName. There are many other custom types
defined by specific applications but those aren't the focus
of this document.

> different URI ids sharing the same ipaddress+port.

I agree ..

> tls servername indication has not provision for this.

Yeah, it's too bad the current SNI spec only supports "hostnames".
Maybe we should look into updating that to support alternative
name forms.

> beef having a path in an identifier?.

One can't have them in SNI extensions (actually they can't
even have URIs at all, with or without paths). But if they
appear in a URI SAN, what should be done, as a general rule?
That was my question. If we're intending to only focus on
authenticating an application server rather than a specific
resource located at that server, then it would be simpler
to declare this topic out of scope.

> ip-address:port to connect and fqdn in the servername

I'm not sure that we have to deal with differences between 
DTLS and TLS. The certificate identity matching rules 
described in this document apply equally to both. The 
connection establishment details differ, but that's currently
not a subject of this document. Do you disagree?

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Fri, 30 Jul 2010 12:24:51 -0400

Certs (and issues related to them) probably is the one area where there should be absolutely no difference between TLS and DTLS, rule-wise.
--
Regards,
Uri          [email-masked]

On Jul 30, 2010, at 12:20 PM, Shumon Huque wrote:

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

---

From: Shumon Huque <[email-masked]>
Date: Fri, 30 Jul 2010 12:30:03 -0400

Yup, agreed. I think that's what I tried to say.

--Shumon.