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

[Stephen Kent <[e-mail]>]

Folks,

Stephen Farrell suggested that I pose a question to this list based on 
an ongoing  debate in another WG.

A certificate and OCSP extension has been proposed in TRANS. The 
extension consists of a few data items, principally:

version number (an integer)

a log ID (an octet string)

a time stamp

a certificate or TBS certificate

a hash value (a bit or octet string)

an optional set of TBD protocol-specific extensions

The authors of the proposed extension elected to encode all of these 
data items as one big OCTET STRING, rather than using the existing, base 
ASN.1 data types. They elected to not use an ASN.1 structure here 
because one of the three ways to communicate this data to a client is 
via a TLS handshake. They believe that the TLS handshake will eventually 
become the predominant means of transporting this data. (I didn’t find 
the argument for this prediction compelling, but ...). Thus they chose 
to employ the syntax defined in RFC 5246.

Russ Housley and I have argued that using OCTET STRING here is 
inconsistent with the intent of 5280 (and 2594 and 3280), which defines 
an extension as:

Each extension includes an OID and an ASN.1 structure.When an extension 
appears in a certificate, the OID appears as the field extnID and the 
corresponding ASN.1 DER encoded structure is the value of the octet 
string extnValue.

Since the bulk of the data items have an obvious ASN.1 representation, 
and the certificate or TBS certificate are native ASN.1 structures, we 
feel that the decision to stuff all of the data items into an OCTET 
STRING is inappropriate, and that it sets a bad precedent for others 
developing certificate (and OCSP) extensions in the future

I’m soliciting feedback from this list on this topic, to pass on to 
Stephen, Kathleen, and the TRANS WG.

Thanks,

Steve