Paul Hoffman wrote: > > At 12:31 AM -0400 6/30/10, Shumon Huque wrote: > >Let's concentrate on the MUST/SHOULD applicability for the four > >identity types discussed in this document: > > > > * CN-ID = a Relative Distinguished Name (RDN) of type Common Name > > (CN) > > > > * DNS-ID = a subjectAltName identifier of type dNSName > > > > * SRV-ID = the SRVName form of otherName from the GeneralName > > structure in SubjectAltName > > > > * URI-ID = a subjectAltName identifier of type > > uniformResourceName > > > > Agree.
Me2. > > I agree that we have to look at the details of the service. To me, > there are two types of names: > - direct (CN-ID, DNS-ID, and URI-ID) > - indirect (SRV-ID) > If they are all SHOULD, and we don't say when one should not mix and > match, we haven't helped interoperability. I think instead, we need > something like "MUST have either one or more of (CN-ID, DNS-ID, > and URI-ID), or SRV-ID". This would be followed by "if the cert has an > SRV-ID, it SHOULD NOT have any of (CN-ID, DNS-ID, and URI-ID) because > the meaning of combination of what is received from the SRV lookup > and the given DNS names is undefined." > > Does that sound reasonable? I think this covers only part of the picture. Describing what certs should have and should not have may be interesting to CA-operators and admins, but seems to apply to new designs only, and not allow for migration. I would appreciate guidance for the implementors. And at that point we will have to get rid of that "is undefined" entirely -- i.e. we will have to specify exactly what is supposed to happen if more than one identifier is present. While CN-ID and DNS-ID have exactly the same scope (hostname) SRV-ID and URI-ID have a more restrictive scope. Does a combination make sense? Or do we expect that to happen only during migration from a currently used CN-ID or DNS-ID to a SRV-ID or URI-ID? Keep in mind that "flag days" where the _entire_ installed base is taken down, changed/updated and put back up, are difficult and rare in practice. Should CN-ID or DNS-ID be entirely ignored when SRV-ID or URI-ID is found and understood/used by a client for server endpoint identification? in the sense that SRV-ID and URI-ID supersede CN-ID or DNS-ID for the clients which understand them? The migration scenario that worries me slightly is that were the CA supports adding features that the installed base doesn't support yet. It could happen that incorrect "new" stuff is added, and as long as noone checks the new stuff, this problem is not noticed. But as soon as the first component is updated to understand this cert attribute, the fact that its incorrect is likely to result in an interop problem if the updated component is "strict" in checking of the new feature. When adding new features with a patch to the installed base, I therefore tend to be tolerant. -Martin _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
