Subject: [Cbor] Review of draft-ietf-cose-cbor-encoded-cert-02

From: Russ Housley <[email-masked]>
Date: Wed, 15 Dec 2021 18:08:23 -0500

I agreed to review this document during the session at IETF 112.

Russ

= = = = = = = =

Document: draft-ietf-cose-cbor-encoded-cert-02
Reviewer: Russ Housley
Review Date: 2021-12-15

Major Concerns:

I think that the document should just define C509.  I would like to see
Sections 4, 5, and 6 moved to other documents.  If there is a desire to
include CRLs, the section needs to be expanded for CRL extensions and
CRL entry extensions.  The most important of these is CRL number.  I
really would like to see some implementation and deployment experience
to guide the specification of these other objects.

Section 3 says:

   The re-encoding does not work for BER encoded certificates.

This is not quite correct.  One can always convert a BER-encoded
certificate to a DER-encoded certificate.  Then, the DER-encoded
certificate can be converted to C509.

Section 3.1 says:

   o  signature.  The 'signature' field is always the same as the
      'signatureAlgorithm' field and therefore omitted from the CBOR
      encoding.

Does this mean that the signature algorithm identifier is not covered
by the signature for natively signed C509 certificates?  There needs
to be some way to provide integrity protection for this identifier.
RFC 6211 talks about the reasons for the integrity protection in a
different context.
 
Section 3.3 includes a bullet for subjectAltName, and in that part of
the document it talks about hardwareModuleName from RFC 4108.  I think
that the AcpNodeName from RFC 8994 probably needs a similar encoding.
Also, if EAI is successful, then SmtpUTF8Mailbox from RFC 8398 will
also benefit from a shorter encoding.

Minor Concerns:

In Section 1, the text says:

   ... Two variants are defined using the same CBOR
   encoding and differing only in what is being signed:

Yes, this is true, but this is the place to say that the two variants
are not interchangeable or interoperable.  As a result, I wonder if
giving names to the two variants would be useful.  Which one is C509?
The phrase "natively signed C509 certificates" seems to suggest that
a short name for the variant is needed.

Section 3: please add a reference for ASN.1.

Nits:

Throughout: s/DER encoded/DER-encoded/

The Abstract includes:

   ... The CBOR
   encoding supports a large subset of RFC 5280 and all certificates
   compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA
   eUICC, and CA/Browser Forum Baseline Requirements profiles. ...
   
I suggest this text be dropped.  It is already in the Introduction. In
the Abstract you cannot provide references for these profiles.

The Abstract includes:

   ... When
   used to re-encode DER encoded X.509 certificates, the CBOR encoding
   can in many cases reduce the size of RFC 7925 profiled certificates
   with over 50%. ...

I suggest rewording:

   ... A 50% reduction in size can be achieved for DER-encoded X.509
   certificates that meet the profile in RFC 7925. ...

Section 3, first para: Is there any reason to list the profiles again?
Listing them once in the Introduction seems adequate.

Section 3.2 has two mostly unrelated subsections.  I suggest that you
have two sections: 3.2 for Encoding of subjectPublicKey, and Section 3.3
for Encoding of issuerSignatureValue.

Section 3.3, bullet about Authority Key Identifier extension:
  s/certIssuer/authorityCertIssuer/
  s/certSerialNumberm/authorityCertSerialNumber/

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Dec 2021 10:25:21 -0500

> I think that the document should just define C509.  I would like to see

I think you mean, just define C509 Certificates.

    > Sections 4, 5, and 6 moved to other documents.

Which are about CSRs, CRLs and OSCP.
I agree.

    > certificate can be converted to C509.

I can't imagine a BER encoded certificate.
Could/would BER encoded certificates ever pass a signature?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide