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:[email protected]"? (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:[email protected]"? 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:u...@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:[email protected]. 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.
[...]
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
