On 6/30/10 12:34 PM, Alexey Melnikov wrote: > 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 agree with this logic too (without "unfortunately" ;-)). > >> 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. >> >> > I think a document specifying how to perform TLS server identity > verification for a particular protocol can specify if only one of them > can be allowed (and which one), or if both can be allowed. This > addresses interoperability for a particular protocol.
I would dearly like to say "MUST use DNS-ID" so that we have a baseline for interoperability across all application protocols. However, it seems that the best we can do is interoperability for a given application protocol (HTTP, IMAP, SIP, XMPP, etc.). That saves the kind of interoperability people really care about, but it does make life a bit more complicated for certification authorities and makes this BCP less clean. Unfortunately, reality is messy... 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
