On 9/16/10 8:15 AM, t.petch wrote:
----- Original Message -----
From: "Peter Saint-Andre" <stpeter(_at_)stpeter(_dot_)im>
To: "Stefan Santesson" <stefan(_at_)aaa-sec(_dot_)com>
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" <stpeter(_at_)stpeter(_dot_)im>
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/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf