Re: [TLS] Review of draft-saintandre-tls-server-id-check

[Peter Saint-Andre <[e-mail]>]

On 9/16/10 8:15 AM, t.petch wrote:
> ----- Original Message -----
> From: "Peter Saint-Andre" <[e-mail]>
> To: "Stefan Santesson" <[e-mail]>
> Sent: Monday, September 13, 2010 9:16 PM
> 
>> On 9/13/10 12:39 PM, Stefan Santesson wrote:
>>> On 10-09-13 6:08 PM, "Peter Saint-Andre" <[e-mail]> wrote:
>>>>
>>>> Hi Shumon,
>>>>
>>>> As I see it, this I-D is attempting to capture best current practices
>>>> regarding the issuance and checking of certificates containing
>>>> application server identities. Do we have evidence that any existing
>>>> certification authorities issue certificates containing both an SRVname
>>>> for the source domain (e.g., example.com) and dNSName for the target
>>>> domain (e.g., apphosting.example.net)? Do we have evidence that any
>>>> existing application clients perform such checks? If not, I would
>>>> consider such complications to be out of scope for this I-D.
>>>>
>>>> That said, we need to be aware that if such usage arises in the future,
>>>> someone might write a document that updates or obsoletes this I-D; in
>>>> fact the present authors very much expect that such documents will
>>>> emerge after the Internet community (specifically certification
>>>> authorities, application service providers, and application client
>>>> developers) have gained more experience with PKIX certificates in the
>>>> context of various application technologies.
>>>>
>>>> Peter
>>>
>>> I would like to turn the question around and ask why this specification need
>>> to have an opinion on whether a relying party feels he have to check both
>>> host name and service?
>>
>> Stop right there. :) I sense a possible source of confusion. What do you
>> mean by "host name" and what do you mean by "service"?
>>
>> In this I-D, we talk about "DNS domain name" and "service type", which
>> map quite well to _Service.Name from RFC 4985: the DNS domain name is
>> the "source domain" provided by the user or configured into the client
>> (e.g., "example.com") and the "service type" is a given application
>> protocol that could be serviced by the source domain (e.g., "IMAP").
>>
>> This I-D is attempting to gently nudge people in the direction of
>> checking both the DNS domain name and the service type. IMHO this is
>> consistent with considering the SRVName and uniformResourceIdentifier
>> subjectAltName entries as more tightly scoped than dNSName or CN, and
>> therefore as potentially more "secure" in some sense (the subject might
>> want to limit use of a particular certificate to only the service type
>> identified in the SRVName or uniformResourceIdentifier).
> 
> <tp>
> Ah, that explains a lot; I knew I smelt a rat, I just did not realise how big it
> was:-) It is fine if you want to nudge Certificate Authorities into issuing
> certs with SRVName but you should put that up front, in the Abstract eg
> "This memo encourages Certificate Authorities to issue certificates with SRVName
> names"
> 
> Otherwise people are likely to expend effort on this memo which will turn out to
> be unproductive; as this thread has established, SRVName do exist, but not in
> many places, which makes this memo of rather limited scope.
> 
> I wondered why the emphasis on server names had grown and grown, in the I-D and
> on this thread, an emphasis which to me seemed a distraction and irrelevance,
> and now I see why; nothing wrong, just needs making this explicit.
> 
> Tom Petch
> 
> </tp>

Thanks for your feedback. As a way of orienting the reader, Jeff and I
are discussing the possibility of adding a section to the introduction
that provides an informational overview of the recommendations contained
in the document.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/