Subject: [COSE] CBOR Certificates Open Issues after -05

From: John Mattsson <[email-masked]>
Date: Wed, 2 Dec 2020 09:22:46 +0000

Hi,

- I think it would be very good with an example CBOR encoding of a IEEE 802.1AR DevID certificate. Does anyone have a spare DevID certificate lying around that could be used?

- ASN.1. Does the document need any ASN.1? Now when the document is covering a large subset of RFC 5280 it would mostly be duplication of RFC 5280, but still a lot of work. We suggest to remove ASN.1 from the document. We have pointed out to UTA and the authors of draft-ietf-uta-tls13-iot-profile that ASN.1 should be included in their document.

- What subset of the extensions are actively used? Looking at IEEE 802.1AR DevID and a lot of certificates on the Web, my current understanding is as follows:

-- AuthorityKeyIdentifier seems to typically be used only with KeyIdentifier. Is it enough to only support optimized CBOR encoding of KeyIdentifier? I.e. not optimized CBOR encoding of AuthorityKeyIdentifier with GeneralNames and CertificateSerialNumber?

-- cRLDistributionPoints seems to typically be used only with DistributionPointName of type fullName of type uniformResourceIdentifier. Is it enough to only support optimized CBOR encoding of 'reasons', 'cRLIssuer', 'nameRelativeToCRLIssuer', or general names of other types than uniformResourceIdentifier?

-- authorityInfoAccess seems to typically be used with general names of type uniformResourceIdentifier? Is it enough to only support optimized CBOR encoding of uniformResourceIdentifier?

Cheers,
John