Re: [pkix] a question of cert (and OCSP) extension syntax

[Sean Leonard <[e-mail]>]

On Mar 18, 2015, at 10:12 AM, Paul Hoffman <[e-mail]> wrote:

> There is no problem with an extension being a blob of data that does not have an ASN.1 structure. Any PKIX-y application that *needs* to read the parts of the blob can do so in the same way that a TLS-y application does, using the same decoder. To be clear: most PKIX-y applications don't descend into ASN.1 structures for extensions they don't know about, so this isn't really any different.

Another argument for ASN.1 encoding is that there are “PKIX-y applications” that are not TLS-y applications (at least, not at that level of the software stack). All TLS-y applications are PKIX-y (because TLS pretty much requires certificate validation or parsing in some form), but not all PKIX-y applications are TLS-y. Thus a TLS-oriented decoder may not be available to the PKIX processing part of the app. To the extent TLS is used, the decoder may be hidden in other layers of the software stack, rendered inaccessible to other parts of the application.

This comment comes from experience. Even in PKIX-processing code, if something (e.g., CRL, OCSP) needs to be fetched over HTTPS, usually some basic library call with the equivalent functionality of “wget https://foo” is used to fetch the data.

From a debugging/analysis perspective, using ASN.1 just makes more sense. That way wire sniffing diagnostic tools can unpack the ASN.1 extension so you can see individual values, even if they are not specifically labeled with the TRANS semantics.

Sean