On 9/16/10 8:15 AM, t.petch wrote: > ----- Original Message ----- > From: "Peter Saint-Andre" <stpeter@xxxxxxxxxx> > To: "Stefan Santesson" <stefan@xxxxxxxxxxx> > 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@xxxxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf