On Mon, Sep 5, 2016 at 5:46 PM Andrei Popov <andrei.po...@microsoft.com> wrote:
> Ø A CertificateExtension is a hint to the client about what kind of > certificates are acceptable. We have a registry of u16s for them. Clients > ignore extensions they don't understand, so it is ultimately on the server > to check the certificate is acceptable (as it always is). If we wish to > filter on OIDs, we define, e.g., a key_usage value whose contents have some > KeyUsage-specific meaning. > > > > Do we need to make it this flexible? The idea was to avoid adding > complexity to the certificate filtering code in the TLS stack, and instead > filter by OIDs in the PKI library. PKI libraries already inspect and match > OID values, so this should be a relatively small change for them. > But it's OID-specific how the matching works, isn't it? Or are you envisioning that everything but the two exceptions listed here is just going to be an exact contents match? That there were exceptions was what seemed off to me. My gut feeling is exceptions would be the norm and we actually want to be very precise here or we'll just implicitly standardize whatever one PKI library does. (I haven't heard of X.509 extension specs defining matchers.) Doing something TLS-style means we have much clearer semantics. We'd need to do a bit more work defining a bunch of code points for each OID matcher we want, but it's something that ought to be written down anyway. Or is my gut feeling wrong and most of them just an exact match? What is your PKI library's filter interface? (Either way I imagine our stack will just keep on ignoring it, so I don't feel about this all too strongly. But the topic came up so I thought I'd suggest this.) David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
