At 3:29 PM -0600 6/29/10, Peter Saint-Andre wrote: >Content-Type: multipart/signed; protocol="application/pkcs7-signature"; >micalg=sha1; boundary="------------ms030002010403050803000801" > >On 6/11/10 7:32 PM, Shumon Huque wrote: >> On Fri, Jun 11, 2010 at 05:07:50PM -0700, Paul Hoffman wrote: >>> 1. The certificate MUST include a "DNS-ID" (i.e., a subjectAltName >>> identifier of type dNSName). >>> >>> 2. If the service using the certificate deploys a technology in >>> which a server is discovered by means of DNS SRV records >>> [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate >>> SHOULD include an "SRV-ID" (i.e., an instance of the SRVName form >>> of otherName from the GeneralName structure in the subjectAltName >>> as specified in [SRVNAME]). >>> >>> If 2 is true, what is the value of the required DNS-ID? >> >> I don't think (1) is correct. If someone intends to deploy a >> certificate with an application specific name form such as SRV-ID >> or URI-ID, then they typically would not want to have a dNSName >> in the certificate, to make sure that the cert can't be (mis)used >> for unrelated application services at that domain name. >> >> Of course one might decide to include dNSName too for transition >> or backwards compatibility reasons. But I don't think that saying >> the certificate MUST include a dNSName is correct. > >Shumon, I think you are correct here, and that DNS-ID needs to be >"SHOULD" instead of "MUST".
This is a very significant change to the document. Please give us all a chance to see all the edits in the next round before you consider the doc read for Last Call. Personally, no MUST but a pile of orthogonal SHOULDs seems like a bad idea if you are wanting this doc to cause more interoperability. At 4:16 PM -0600 6/29/10, Peter Saint-Andre wrote: >I think this list is leaning toward saying that DNS-ID is a SHOULD, not >a MUST, so the quoted text would be appropriate. Only "appropriate" if you want no MUSTs. Some us would prefer MUSTs to mush. --Paul Hoffman, Director --VPN Consortium _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
