I have no involvement in systems that would want this (our implementation just ignores it), but it seems a TLS-style registry would be better than using OIDs anyway. Concretely:
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. That would buy us: - More consistency with other TLS fields. - More compact encoding. (At the cost of going getting to define 2^16 rule types, but this seems to have been everywhere else.) - It is easy to look up what a CertificateExtension means and avoid conflicts. I can go to the registry and see that type 43 means "match KeyUsage in this way". For OIDs, it's not obvious whether - Relatedly, we can define multiple kinds of matching rules on the same OID. Suppose we define it one way and we realize we got it wrong. The OID scheme means we're stuck with it. The TLS-style scheme allows us to define key_usage_v2 if needed. - Less confusion about known OIDs with unknown matching rules. The text is a little funny right now. There are plenty of known extension OIDs right now with unknown matching rules. Do we fallback to exact match (which means we can never change this) or should clients ignore those? That enforcing known OIDs is a MUST-level requirement makes this messier. - More flexibility in defining future rule types. Perhaps we want to say some extension is not present. Or some rule is really a combination of two OIDs. Or not an OID at all like "your RSA key must be at least 2048 bits". What do folks think? David On Sun, Sep 4, 2016 at 6:56 AM Ilari Liusvaara <ilariliusva...@welho.com> wrote: > How are the OIDs and values in CertificateRequest extensions encoded > exactly (I can't make it out from the text)? > > > Does the OID part have the ASN.1 OID TLV tag and length (e.g. > is EKU 0x55 0x1D 0x25 or 0x06 0x03 0x55 0x1D 0x25)? > > > And how is the value encoded? Using the same encoding as > extnValue payload of respective extension in X.509 certifcates? > Or is it OID-specific (and if it is, what exactly goes to it > for EKU and KU? RFC 5280 ExtKeyUsageSyntax and KeyUsage?) > > > (Currently the text just refers to DER encoding, and in a > way that could be read to apply to just to values). > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
