Deterministic Encoding of an Extension

[xipki]

To encode an extension of an X.509 certificate deterministically, I suggestion to follow one of the following methods to produce a distinct encoded C.509 certificate (of type 3).

• Method 1

  1. If the extensionID has an int assignment,
     1. If the extentionValue can be encoded as the syntax specified in "Figure 8: C509 Extensions and CSR Attributes", then the extension is encoded as (extensionID:int, extensionValue:any),
     2. otherwise if the syntax specified in "Figure 8" does not contain bstr choice, then the extension is encoded as (extensionID:int, extensionValue:bstr) where extensionValue is the DER-encoded extension value. (This applies to all extensions except subjectKeyIdentifier and authorityKeyIdentifier).
     3. otherwise the extension is encoded as (extensionID:~oid/pen, extensionValue:bstr) where extensionValue is the DER-encoded extension value. (This applies to the extensions subjectKeyIdentifier and authorityKeyIdentifier).
  2. otherweise the extension is encoded as in case i.c

• Method 2 The same as Method 1, except there are no case i.b.

Method 1 needs less storage capability, but Method 2 is simpler to implement.

[highlunder]

Based on joint discussions, we are leaning towards Metod 2, but we will reach out and ask the COSE list for comments!

[highlunder]

Have mailed the COSE list with the following content:

Regarding the ongoing work with draft-ietf-cose-cbor-encoded-cert, we hope to get your opinions on some alternatives regarding non-determinism and compactness. Our overall stance is that non-determinism in the c509 encoding cannot be fully avoided, if we at all want the draft to evolve and cover more relevant use cases in the future. But we need to both clarify and, as far as possible, reduce the cases where non-determinism could happen. A main area to clarify is the handling of certificate extensions:

*Previously we have allowed the registration of certificate extensions in our c509 extension table(^1), without requiring a full accomplishing specification of the cbor encoding of the extension value. Instead allowing the value to be a cbor byte string wrapping of the der-encoded value. This is a clear source of non-determinism, as the expectation is that later additions to the draft will further specify a cbor encoding of the value. The result would be that the receiver of a certificate cannot know beforehand if an extension value is cbor fully encoded or just a der endoced value with byte string wrapping.

We think it would be a useful restriction to only keep extensions with defined cbor encodings of the value, and add this as a requirement for new entries into the table of supported extensions.  For encoded X.509 certificates, any extension would still supported through the more lengthy wrapping of the oid and bstr-wrapped extension value. *We are leaning towards proposing that native c509 must only use cbor encoded extensions. This means that an X.509 extension, which is not covered in the C509 Extensions registry, must be added before being allowed in a native C509 certificate. 

Does this seem like reasonable restrictions and limitations? Comments and opinions here or directly to our github issue tracker(^2) are most welcome.

In addition, there has been an ongoing discussion on adding options for using PENs instead of OID. Since the the cbor encoding of the PENs would need a tag, the savings compared with unwrapped OIDs are only two bytes per PEN. At the same time, support for PEN adds complexity both in the specification and in implementations. To not increase the non-determinism, any OID which can be PEN encoded must be PEN encoded, requiring strict checking. This makes us question whether the savings are worth the drawbacks, and we are interested in hearing any supporting voices from either side of the issue.

1) Ref, C509 Extensions registry: https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-09#name-c509-extensions-registry

2) The main github issue regarding the non-determinism issue https://github.com/cose-wg/CBOR-certificates/issues/197

[gselander]

Having not received any comments, we make the same change for extension as for attributes #198.

Pending input from John, we are in favor of requiring CBOR encoded extensions for native C509 certificates.