Missing the extensionValue's syntax for several extensions

[xipki]

Syntax for the following extensions needs to be added:

• code 36, Biometric Information (RFC 3739)
• code 37, Precertificate Signing Certificate (RFC 6962)
• code 38, OCSP No Check (RFC 6960)
• code 39, Qualified Certificate Statements (RFC 3739)
• code 40, S/MIME Capabilities (RFC 8551)
• code 41, TLS Features (RFC 7633)

[highlunder]

Indeed I see that we haven't specified "raw bytes" as the intended extension value! Our intention as authors is to have raw byte encodings for the extension values, for the recently added extension types. But if someone is proposing a new CDDL encoding, together with representative example X.509 certificates we are open for further discussions.

[xipki]

For Precertificate Signing Certificate (code) and OCSP No Check (code 38), I will suggest to use nullfor the extensionValue.

[xipki]

For TLS Feature, the ASN.1 syntax is defined in RFC 7633 as follows:

   id-pe-tlsfeature OBJECT IDENTIFIER ::=  { id-pe 24 }

   Features ::= SEQUENCE OF INTEGER

The feature contains the TLS extension which are between [0, 65535] (see https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1), and can be encoded in CBOR uint.

Thus I suggest to use following C509 syntax:

  TLSFeatures = [* feature: uint]

[xipki]

For the Biometric Information (code 36):

The ASN.1 definition in RFC 3739 is as follows:

      BiometricSyntax ::= SEQUENCE OF BiometricData

      BiometricData ::= SEQUENCE {
          typeOfBiometricData  TypeOfBiometricData,
          hashAlgorithm        AlgorithmIdentifier,
          biometricDataHash    OCTET STRING,
          sourceDataUri        IA5String OPTIONAL }

      TypeOfBiometricData ::= CHOICE {
          predefinedBiometricType    PredefinedBiometricType,
          biometricDataID            OBJECT IDENTIFIER }

      PredefinedBiometricType ::= INTEGER { picture(0),
          handwritten-signature(1)} (picture|handwritten-signature,...)

I suggest to use the following CDDL in C509:

BiometricSyntax = [ * BiometricData ] 
BiometricData = (
 typeOfBiometricData: int / ~oid / pen,
 hashAlgorithm: int / ~oid / pen,
 biometricDataHash: bstr,
 ? sourceDataUri: tstr
)

For the hashAlgorithm, we may define new constants or use the constants defined in RFC 9054 (https://datatracker.ietf.org/doc/rfc9054/).

The int choice of typeOfBiometricData has then two groups:

• Non-Negative value: the value specified in RFC 3739

      PredefinedBiometricType ::= INTEGER { picture(0),
          handwritten-signature(1)} (picture|handwritten-signature,...)

• Negative value: mapping from OBJECT IDENTNFIER to an int, managed in the C.509 specification.

[xipki]

Suggestion to encode SMIMECapabilities in CBOR:

If all capabilities do not contain parameters or the parameters field is of ASN.1 type INTEGERand its value is in the range [0, 0xFFFFFFFFFFFFFFFF] (64 bit unsigned integer), then the SMIME extension can be CBOR encoded. Below is the syntax:

SMIMECapability = (capabilityID: ~oid/pen, ? parameters : uint)

SMIMECapabilities = [ * SMIMECapability ]

[xipki]

Related to the QCStatements, it is quite difficult to define a CBOR syntax.

Here are some examples of QC statements:

• ETSI EN 319 412-5: Part 5: QCStatements (https://www.etsi.org/deliver/etsi_en/319400_319499/31941205/02.04.01_60/en_31941205v020401p.pdf)
• ETSI TS 119 495: Certificate Profiles and TSP Policy Requirements for Open Banking (https://www.etsi.org/deliver/etsi_ts/119400_119499/119495/01.06.01_60/ts_119495v010601p.pdf)

I created a new issue #193 to cover the extension QCStatements.

[highlunder]

For now we keep 38 & 41 as relevant, and wait for a PR/PRs from Lijun