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 [email protected] https://www.ietf.org/mailman/listinfo/certid
