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

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

--Shumon.

On Fri, Jul 30, 2010 at 12:24:51PM -0400, Blumenthal, Uri - 0668 - MITLL wrote:
> 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          uri@ll.mit.edu
> 
> 
> 
> On Jul 30, 2010, at 12:20 PM, Shumon Huque wrote:
> 
> > On Fri, Jul 30, 2010 at 07:49:51AM +0200, Peter Sylvester wrote:
> >> 
> >> 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.
> > 
> > Well that, and SRVName. There are many other custom types
> > defined by specific applications but those aren't the focus
> > of this document.
> > 
> >> It is a little bit difficult to have several certificates with
> >> 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.
> > 
> >> If one cannot have ids with different paths, what's the
> >> 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.
> > 
> >> 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?
> > 
> > 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?
> > 
> > -- 
> > Shumon Huque
> > University of Pennsylvania.
> > _______________________________________________
> > certid mailing list
> > certid@ietf.org
> > https://www.ietf.org/mailman/listinfo/certid
> 
> _______________________________________________
> certid mailing list
> certid@ietf.org
> https://www.ietf.org/mailman/listinfo/certid

-- 
Shumon Huque
University of Pennsylvania.