Comments on digital signatures and certificate profile

[c2pa-feedback]

Submission Info

Submitted by: Matthias Valvekens Email: matthias@mvalvekens.be Company:

Details

I am a (new) CAI member; Chrysanthe Tenentes told me that I should submit feedback through this channel for the time being.

Full disclosure: my experience with COSE as a container format is rather limited so far, most of my experience is with signing standards based on ASN.1 data types.

I've organised my comments by clause number below. Feel free to contact me for further information.

Thanks!

12.2: Digital signatures

We should consider including support for EdDSA signatures as well. Ed25519 and Ed448 are already listed in RFC 8152, FWIW. EdDSA is doubly relevant for the C2PA use case: ECDSA and (to a lesser degree) RSASSA-PSS both require access to a cryptographically secure RNG, which may not be available on embedded devices (e.g. cameras). Meanwhile, EdDSA is designed to produce signatures deterministically. Alternatively, we could recommend that people use a deterministic versions of ECDSA (doesn't matter for interoperability, but it is an important implementation concern).

PS: I like the fact that "legacy" RSA signing has been excluded.

13.2.1.2. Certificate Profile

For ECDSA, listing only digests is insufficient to achieve interoperability, and the specification should also spell out which curve parameters (or rather: curve names/IDs) should be recognised by all implementations. Since COSE only includes NIST P-(256|384|521) anyway, perhaps it's a good idea to (at least initially) align the certificate profile with this list.

13.2.1.3 Certificate Revocation

I believe disallowing/disregarding CRLs for revocation checks is inappropriate. Even though OCSP is in widespread use right now, that does not make CRLs obsolete, and in my opinion this also applies to the C2PA use case. Some reasons:

• CRLs being too large to handle is only an issue for large "leaf" CAs that issue many end-entity certificates.

• Generating/publishing CRLs and hosting an OCSP responder are two ways of publishing revocation status information with very different security tradeoffs: an "always online" service like OCSP is perhaps more accurate, but it does require indirectly exposing quite a bit of sensitive infrastructure to the internet (issuance database, the responder's own keying material, etc. There are still many situations where using CRLs makes perfect sense.

• The cost of (properly) operating an OCSP responder might be prohibitive for some small-time "closed" PKI systems. Since 13.2.1.1 specifically mentions allowing self-signed certificates, I don't believe it's the intention of the C2PA specification to otherwise limit itself to commercial/government-operated CAs.

• CRLs are easier to cache, which makes sense on devices that don't have internet access.

• For revocation checking for non-end-entity certs (see below), CRLs are still widely used: in a run-of-the-mill Root -> Intermediate -> Leaf kind of setup, where the root only issues a handful of intermediate certificates, it's not uncommon for the Root -> Intermediate link to use CRLs exclusively, while an OCSP service is offered for the Intermediate -> Leaf link.

I have absolutely no objections to a note calling out the fact that CRLs can get very large and that proper care should be exercised accordingly, but I'm not convinced that banning them outright is the right answer.

Regarding the note at the end of this subclause:

(a) Revocation checking of (non-exempt!) OCSP responders can only be done through CRLs, which is another reason to not disregard them completely.

(b) The sentence "We are also not currently considering potential revocation of intermediate CAs on the path from the signer's certificate to the trust anchor" is also dangerous IMO. At best, it can be interpreted as "the criteria in this clause don't apply to intermediate certificates". At worst, it reads as if the C2PA trust model doesn't care whether the implementation performs revocation checks on intermediate certs. Such revocation checks are a requirement of the validation procedure in RFC 5280, cited elsewhere in this clause. See in particular RFC 5280, § 6.1.3 (a)(3).

Assuming the former interpretation is what was intended, I suggest rewording the note accordingly. Especially if we decide to stick with the CRL ban for signer certificates, it needs to be made clear that CRLs can still be used for intermediate certificate revocation checks (which probably also means that the crlVals property needs to be reinstated either way).

[kevinmkane]

12.2: Digital signatures

We should consider including support for EdDSA signatures as well. Ed25519 and Ed448 are already listed in RFC 8152, FWIW. EdDSA is doubly relevant for the C2PA use case: ECDSA and (to a lesser degree) RSASSA-PSS both require access to a cryptographically secure RNG, which may not be available on embedded devices (e.g. cameras). Meanwhile, EdDSA is designed to produce signatures deterministically. Alternatively, we could recommend that people use a deterministic versions of ECDSA (doesn't matter for interoperability, but it is an important implementation concern).

This suggestion came up internally, and we've already decided to include Ed25519, because there has been external interest in using EdDSA.

13.2.1.2. Certificate Profile

For ECDSA, listing only digests is insufficient to achieve interoperability, and the specification should also spell out which curve parameters (or rather: curve names/IDs) should be recognised by all implementations. Since COSE only includes NIST P-(256|384|521) anyway, perhaps it's a good idea to (at least initially) align the certificate profile with this list.

This requirement is implied by the allowed list the digital signature algorithms we allow for manifests in chapter 12, since a certificate's subject public key will have to be on the appropriate curve for the chosen algorithm, but for clarity we can also add a list of supported key types for elliptic curves here, too.

13.2.1.3 Certificate Revocation

The issues you raise are more controversial, and so I won't comment yet until the Technical Working Group has had a chance to consider them, and then we'll get back to you here.

Thank you for your comments!

[kevinmkane]

Thank you again for your comments. We have taken your suggestion regarding curves for ECC keys used with ECDSA. We have also discussed the comments on revocation and have come to the following decisions.

We are removing the note about not checking the revocation status of intermediate certificates, to allow the existing standards to stand when it comes to intermediate CAs, OCSP responders, and Time Stamp Authorities. We do not intend to diverge from existing practice on these. We are also removing the prohibition on the CRL extension being present, especially given the need to comply with standards regarding validating revocation status of those three classes of certificate.

However, we have decided not to include CRLs for consideration where certificates of signers of manifests are concerned.

First, our target scenarios for version 1 of this specification have a global audience, and therefore we do expect large CAs to be the only ones participating. The inclusion of self-signed certificates was done to address a very specific but very important use case, where two participants with a direct, out-of-band trust relationship want to share assets directly between them; it was not intended to generalize into other types of PKIs. Therefore, we find it reasonable to expect CAs participating will be able to securely operate OCSP responders securely and with high availability, as they do already for the web PKI.

In future versions of the specification, if we pursue new verticals where closed PKIs exist such that expecting OCSP responders is not realistic, we will revisit this decision at that time.

Second, we intend for the common case for manifests is that revocation and time-stamp information is attached by the signer. Therefore in the common case, there should be no need to possibly make an on-line query to an OCSP responder or a CRL distribution point. Therefore, manifests without revocation information should be an edge case, and one we want to discourage. We are looking into better methods of attaching revocation information, such as something like what PDF does with the Document Security Store and Validation Related Information, that should further improve the ability for signers to add this information and so incentivize them to do so, and therefore make the need to make on-line queries even more of an edge case. Improving this fallback path to also consider CRLs for signer certificates works against this goal.

The size of CRLs would become a concern, as it would be the CRL from an intermediate CA that issues signer certificates that would need to be attached.

Thank you again for your comments. Please look for these changes in the next public draft, and let us know if you have any further comments.