On 6/30/10 12:18 PM, Paul Hoffman wrote: > At 9:27 AM -0700 6/30/10, Love Hörnquist Åstrand wrote: >> I think that both "direct" and "indirect" SHOULD be allowed at the >> same time. >> >> The reason is that if you have a client that supports SRV lookups, >> in for example jabber, then you want to have the SRV name in there >> so the client can match the server cert with what the user typed. >> >> Of course there are jabber clients out there that don't support SRV >> lookup and want to to the normal direct mappings rules. >> >> Since the server doesn't really know what client they talk to it >> need to hand out a cert that matches both rules -> must hAve both >> for interop reasons. >> >> So the direct names are not used for intermediate values, they are >> only used with names what comes/is derived user input. > > Unfortunately, I agree with this logic. I say "unfortunately" because > it means that we then don't have a MUST, and therefore lose > interoperability. For sanity, the document needs to say why it is OK > to have both direct and indirect and what to do when they are both > there, but I agree that we can't say MUST have only one.
Upon further reflection, I think there are two dimensions here: 1. From the client's perspective, some names are direct (provided by the user = DNS-ID, CN-ID, URI-ID) and some names are indirect (resolved by the client based on the input provided by the user = SRV-ID). This dimension matters for verification. 2. From the service provider's persective, some names are unrestricted (can be used in any application = DNS-ID and CN-ID) and some names are unrestricted (can be used in only one kind of application = SRV-ID and URI-ID). This dimension matters for issuance. I'll work to formulate this distinction more carefully in text that can be included in the spec. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
