Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11

[Ben Campbell <[e-mail]>]

On Dec 7, 2010, at 11:02 PM, Peter Saint-Andre wrote:

> Thanks, Ben.
> 
> In general, I think this document is describing the tools available to
> protocol designers, not telling protocol designers which tools to use.

Okay, then :-)

On re-reading the thread, I realize I did a lot of dead-horse beating. Further comments below, with the areas I think we are in agreement elided. 

> 
> More comments inline.
> 
> On 12/7/10 5:10 PM, Ben Campbell wrote:
>> I'm jumping in a bit late with some review followup. It's not
>> entirely clear to me where in the thread I should re-insert myself,
>> so I apologize if I bring up stuff that would have been resolved or
>> otherwise obvious at other points in the thread--I'll dig back
>> through and respond further as appropriate.
>> 
>> (And I realize I'm doing lots of arm-waving around
>> whats-really-going-on with URI-IDs and SIP. If we need a higher
>> bandwidth communication, I can be available.)
>> 
>> Comments inline:
>> 
>> On Dec 7, 2010, at 4:14 PM, Peter Saint-Andre wrote:
>> 

[...]

>> 
>> Understood. It may be that the answer is that the use of URI-ID is
>> not sufficiently understood to offer general guidance. OTOH, in the
>> case of SIP, the URI-ID appears to be solely for the purpose of
>> binding a domain name to the service. Otherwise, the use as defined
>> in RFC5922 would be substantially identical to using a DNS-ID. More
>> to the point, RFC5922 does not use URI-ID to specify a user identity,
>> only a host identity. Would you recommend designers of a new protocol
>> to follow that pattern? 
> 
> Well, this document is about host ("application service") identity, so
> user identity is conveniently out of scope.
> 

Okay


>> I note that (unless I missed it) the 5922
>> doesn't seem to allow for falling back to a dNSName. Is that a
>> reasonable choice for a new protocol to make? 
> 
> I think not. IMHO the fallback is a good idea.

But, from previous comments, such guidance does not belong in this draft, right?

[...]

>> Given the previous conversation about how SIP seems to be the only
>> protocol with the equivalent scheme issue that actually uses URI-IDs,
>> and that it doesn't seem to need to worry about which scheme its
>> using at the moment, I no longer think this draft needs to worry
>> about it. If it were to say anything at all along those lines, it
>> would probably need to be along the lines of KISS. For example, I
>> don't think you want designers trying to assert security properties
>> by which scheme they include in a cert (i.e. "foo" vs "foos")
> 
> Well, I do think a using protocol does need to specify which URI scheme
> names are acceptable for the application protocol. You wouldn't want a
> client to think that fubar://example.com identifies a SIP service. The
> tel: URI scheme is an interesting counter-example in some ways.
> 

Not to mention "im:" and "pres:" :-)

Am I correct in assuming you mean that in the context of what schemes they will put in a certificate, or match to a certificate, right? As opposed to what schemes are legal in the application protocol as a whole--since these are probably somewhat separate dimensions of extensibility. (If the second, then I'm in over my depth in meta-protocol design, and would certainly defer to an apps area expert if one were handy ;-)  )

[...]

>>>> -- 4.2.2:
>>>> 
>>>> Can we have a URI-ID example?
>>> 
>>> How's this?
>>> 
>>> A voice-over-IP (VoIP) user agent that is connecting via SIP to
>>> the voice service at "voice.example.edu" might have only one
>>> reference identifier: a URI-ID of "sip:voice.example.edu" (see
>>> [SIP-CERTS]).
>>> 
>> 
>> Would it make sense to say something to indicate this is true, even
>> though the connection may have been opened based on a URI of
>> "sip:[e-mail]"? (I'm trying to figure out the best way
>> to word that without trying to invoke SIP request-URI vs route set
>> complexities, but my brain is tired. I will think further about it.)
> 
> What do you mean by "the connection was opened based on a URI of
> sip:[e-mail]"? Yes, the client might know that it is
> configured for an account with that URI, but in order to communicate
> with the application service it will need to resolve the DNS domain name
> (and application type) to an IP address. So that's the reference
> identifier. The presented identifier in the certificate will also be of
> the form sip:domain, not sip:user@domain.
> 

Sure, and I guess what I am talking about is how one derives a reference identifier of sip:voice.example.edu from an address of record (AoR) of sip:[e-mail]. For example, I click on the AoR on a web page, or I type it from Mr. User's business card. I guess my point is it would be useful for the example to show that, given the URI of a _resource_, you derive (extract?) a URI of a _service_ to be the reference entry. You've mentioned that in text, but it would be useful for the example to show it as well.


[...]

> 
>>> I suggest the following tweaks:
>>> 
>>> 3.  If the service using the certificate deploys a technology in 
>>> which a server is programatically associated with a URI for 
>>> security purposes (e.g., this is true of [SIP] as specified by 
>>> [SIP-CERTS]), but not true of [HTTP] since [HTTP-TLS] does not 
>>> describe usage of a URI-ID for HTTP services), then the certificate
>>> SHOULD include a URI-ID; the scheme SHALL be that of the protocol
>>> associated with the service type and the "authority" component
>>> SHALL be the fully-qualified DNS domain name of the service.  A
>>> specification that re-uses this one MUST specify whether particular
>>> URI schemes are to be considered equivalent (e.g., http and https,
>>> or sip and sips as described in [SIP-SIPS]).
>> 
>> I think this is pretty close, modulo previous comments above. I
>> wonder if the fact that SIP appears to abstract the scheme rather
>> than use the scheme of any particular URI is relevant here, or just
>> adds too much complexity to the language.
> 
> My first thought it that it adds too much complexity, but I'll consider
> it further tomorrow.
> 

Okay. I can't off-hand think of a simple way to put it, so you are probably right. 

[...]