Subject: [COSE] C509 Certification Request (CSR)

From: John Mattsson <[email-masked]>
Date: Tue, 25 May 2021 20:32:38 +0000

Hi,

There has been several requests regarding CSR including #77 and #80 from Stefan Hristozov. Defining a CSR format seems very easy reusing existing CDDL and definition for certificates. When discussed during the interim, there seemed to be support of specifying a C509 CSR format. I made a commit with the following CDDL as a starting point for a CSR format:

~~~~~~~~~~~ CDDL
C509CertificateSigningRequest = [
   TBS CertificateSigningRequest,
   subjectProofOfPossesionValue: any,
]

; The elements of the following group are to be used in a CBOR Sequence:
TBS CertificateSigningRequest = (
   c509 CertificateSigningRequest Type: int,
   subject: Name,
   subjectPublicKeyAlgorithm: AlgorithmIdentifier,
   subjectPublicKey: any,
   attributes: [ * Attribute ],
   subjectProofOfPossesionAlgorithm: AlgorithmIdentifier,
)

Attribute = ( attributeType: int, attributeValue: any )
~~~~~~~~~~~

The format is more of less taken from RFC 2988 (PKCS #10, 1.7). Most definitions can just be reused from draft-ietf-cose-cbor-encoded-cert

Some comments:

- I don't think there is any reason to have a CBOR CSR with signature over DER like we have done with C509 certificates. But having a type int is likely good anyway even if only one is defined.

- Everybody seems to use the word "Certificate signing request" instead of the RFC 2988 wording "certification request" so probably best to just use CSR.

- The RFC 2986 name signaturealgorithm does not match the algorithms defined in RFC 6955 for DH keys. I suggest to use the name ProofOfPossesion following RFC 6955. Signature algorithms is then a special case.

- The RFC 6955 algorithm would need to get int code points in the draft. They currently do not have this as they are not used in certificates.

- RFC 2986 does not sign the signature, but there seems to be no reason to not do this, so I made the format following the C509 certificate CDDL.

- I don't know which attributes would have to registered. Which attributes are typically used? Are any attributes typically used?

Cheers,
John

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 25 May 2021 14:28:20 -0700

Any interest in CWT / JWT with the proof-of-possesion claim defined in RFC 8747 and RFC 7800? They both have a subject and a public key, the same as PKCS-10.

Seems there is some code size advantage, perhaps more so in the long run, to going with pure CBOR. You only need to have COSE signing and verifying and that COSE code can be shared between all sorts of security functions like attestation, authentication, SW update.

With the CWT/EAT format, code is also shared for decoding the token/CSR, so the net code add to be a CSR is really small.

EAT defines an intended-use claim that can indicate the use is proof-of-posssion.

What you don’t get is an issue in the format of a DN, but maybe that is a good thing.

LL

> On May 25, 2021, at 1:32 PM, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> Hi,
>  
> _______________________________________________
> COSE mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 25 May 2021 14:38:18 -0700

> On May 25, 2021, at 2:28 PM, Laurence Lundblade <[email-masked]> wrote:
> 
> ...
> 

Should have said “is a subject in the format of a DN”.

Also note that attributes just become other CWT and EAT claims, again for which there is already likely to be an implementation and for which the code can be shared.

LL

---

From: John Mattsson <[email-masked]>
Date: Wed, 26 May 2021 08:53:57 +0000

That is a very good discussion to have.

As a general CSR format for RFC 5280, CWT does however seems a bit limited. I think the general CSR format for C509 need to support all the options in the subject, subjectPublicKeyAlgorithm, and extensions of a C509 certificate. Not sure we like to extend CWT with everything in RFC 5280. The size of the CSR format does not seem as important as the size of the certificate format.

>From a client side, a CWT CSR might make things a bit easier, but if you request a C509 certificate, you likely need to process C509 anyway. From a CA side, the transformation from a CWT CSR to a C509 certificate would be much more complex.

A CSR attribute that is always used is of course extensionRequest. The only other attribute that seems to be used (have been used) is challengePassword. Maybe extensionsRequest is the only thing needed?

C509CertificateSigningRequest = [
   TBS CertificateSigningRequest,
   subjectProofOfPossessionValue: any,
]

; The elements of the following group are to be used in a CBOR Sequence:
TBS CertificateSigningRequest = (
   c509 CertificateSigningRequest Type: int,
   subject: Name,
   subjectPublicKeyAlgorithm: AlgorithmIdentifier,
   subjectPublicKey: any,
   extensionsRequest : Extensions,
   subjectProofOfPossessionAlgorithm: AlgorithmIdentifier,
)

Cheers,
John

From: Laurence Lundblade <[email-masked]>
Date: Tuesday, 25 May 2021 at 23:38
To: John Mattsson <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [COSE] C509 Certification Request (CSR)

LL

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 May 2021 12:45:17 +0200

Given all the work that has been done on C509, doing a culturally compatible CSR seems like a no-brainer to me.

This doesn’t mean that we don’t want to have signing requests for CWT, to the contrary.  But maybe we want to use the somewhat wider scope that CWTs have, to distinguish requesting different forms (and semantics!) of signed assertions.

I think it would be good to check our agreement in this group that having a C509-shaped CSR is not a replacement for or an obstacle to developing requests for CWT-shaped signed assertions.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Thu, 27 May 2021 10:45:41 -0400

John Mattsson <john.mattsson=[email-masked]> wrote:
    > There has been several requests regarding CSR including #77 and #80
    > from Stefan Hristozov. Defining a CSR format seems very easy reusing
    > existing CDDL and definition for certificates. When discussed during
    
    > ~~~~~~~~~~~ CDDL C509CertificateSigningRequest = [ TBS
    > CertificateSigningRequest, subjectProofOfPossesionValue: any, ]

So, if we aren't compressing an existing PKIX CSR, why are we using this?
Shouldn't we just put this into CWT?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Thu, 27 May 2021 10:47:36 -0400

John Mattsson <john.mattsson=[email-masked]> wrote:
    > From a client side, a CWT CSR might make things a bit easier, but if
    > you request a C509 certificate, you likely need to process C509
    > anyway. From a CA side, the transformation from a CWT CSR to a C509
    > certificate would be much more complex.

I disagree.
As long as the signature is different, there is no common code.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 27 May 2021 10:55:56 -0400

Carsten Bormann <[email-masked]> wrote:
    > Given all the work that has been done on C509, doing a culturally
    > compatible CSR seems like a no-brainer to me.

To me, that means that the attributes can be expressed in (compressed) OIDs.
Having built a CA that processes CSRs in non-trivial ways, if the signature
is not compatible, then it's a new code path.
I need a dict/map of attributes and then I have to map that into my
certificate format.

    > This doesn’t mean that we don’t want to have signing requests for CWT,
    > to the contrary.  But maybe we want to use the somewhat wider scope
    > that CWTs have, to distinguish requesting different forms (and
    > semantics!) of signed assertions.

    > I think it would be good to check our agreement in this group that
    > having a C509-shaped CSR is not a replacement for or an obstacle to
    > developing requests for CWT-shaped signed assertions.

I would agree with that, but I also see a point in creating something that
isn't RFC5280/etc. CSR and isn't a CWT.  That's an extra deadend codepath.

Or, I object to not using CWT.

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 27 May 2021 10:46:03 -0700

> On May 26, 2021, at 1:53 AM, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> I think the general CSR format for C509 need to support all the options in the subject, subjectPublicKeyAlgorithm, and extensions of a C509 certificate. Not sure we like to extend CWT with everything in RFC 5280. The size of the CSR format does not seem as important as the size of the certificate format.

My thought for the long run is that there is a CBOR/CWT-based set of protocols that replace all the ASN.1/DER-based protocols. That of course includes a pure CBOR cert (based on CWT) and a pure CBOR CSR (also based on CWT). This is of course taking CWT far beyond its original intent, but that’s good because of code re use. Think of it as a flexible set of signed attributes, not as just for authentication. We’re already extending this way with EAT 10+ claims are being added.

So the answer is, yes, we should extend CWT with stuff in RFC5280. Maybe not all of it and maybe using lessons learned, but it should give all the functionality needed.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 27 May 2021 11:01:27 -0700

> On May 26, 2021, at 3:45 AM, Carsten Bormann <[email-masked]> wrote:
> 

This is the main thing for me.

We must not close off pure CBOR CSRs and Certs. We want to eventually get to a place where some one can run a system with no ASN.1/DER.

I would write drafts for this stuff now, except I’m committed to the EAT draft and need to finish that. I’d also do implementations. My ctoken <https://github.com/laurencelundblade/ctoken> implementation of CWT and EAT is designed so this stuff can be easily added to it, but again I need to finish EAT. The implementation is also so the code is shared between CWT, EAT and eventually certs and CSRs. You could even do an (incompatible) revision of the FIDO protocol that would re use this code.

I kind of agree with Michael’s point that it is wasteful to have three formats (PKCS 10, CWT-based CSR and the thing in between proposed here). I also see any transition to a pure CBOR/CWT infrastructure as very long involved with many drafts being authored.

LL

---

From: John Mattsson <[email-masked]>
Date: Thu, 27 May 2021 20:20:54 +0000

Hi,

I am all for work continuing to improve CWT and expand their use cases, but I think CWTs are mostly useful to request other CWTs. CWTs are great, flexible, and can replace certificates in some places, but I doubt most deployments relying on PKI will ever change to anything else.

What I think C509 certificates needs is a CSR format allowing all types of C509 certificates to be requested. I don't think CWT will or should support that much of RFC 5280.

An essential part here is to enable easy implementation in an existing CA. A CA needs to be able to create a X.509 using their existing processes and code and then relatively simple transform it to C509. Similarly a CA need to relatively easily transform the C509 CSR to a DER encoded CertificationRequestInfo and process that with existing processes and code.

One could insert a CBOR encoded CertificationRequestInfo in a CWT, but I don’t think it that make much sense as it would only be good to request a C509 certificate.

Cheers,
John

From: Laurence Lundblade <[email-masked]>
Date: Thursday, 27 May 2021 at 20:01
To: Carsten Bormann <[email-masked]>
Cc: John Mattsson <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [COSE] C509 Certification Request (CSR)

On May 26, 2021, at 3:45 AM, Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote:

I would write drafts for this stuff now, except I’m committed to the EAT draft and need to finish that. I’d also do implementations. My ctoken<https://protect2.fireeye.com/v1/url?k=19dfcb87-4644f2aa-19df8b1c-8692dc8284cb-ace8aa622a18ecc1&q=1&e=647edb7b-57e5-4503-90b2-b41a3bc1d037&u=https%3A%2F%2Fgithub.com%2Flaurencelundblade%2Fctoken> implementation of CWT and EAT is designed so this stuff can be easily added to it, but again I need to finish EAT. The implementation is also so the code is shared between CWT, EAT and eventually certs and CSRs. You could even do an (incompatible) revision of the FIDO protocol that would re use this code.

LL

---

From: Michael Richardson <[email-masked]>
Date: Thu, 27 May 2021 20:17:36 -0400

John Mattsson <john.mattsson=[email-masked]> wrote:
    > What I think C509 certificates needs is a CSR format allowing all types
    > of C509 certificates to be requested. I don't think CWT will or should
    > support that much of RFC 5280.

I'm arguing against a third signature format.
I'm happy with having the key/value pairs all come from 5280.

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 28 May 2021 06:06:32 +0200

> I'm arguing against a third signature format.

So would you be happy with a PoC that transforms C509 CSR into PKCS10?

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 May 2021 10:30:05 -0400

> So would you be happy with a PoC that transforms C509 CSR into PKCS10?

i.e. we are compressing CSR, not alliterating it.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 28 May 2021 18:04:26 +0200

> i.e. we are compressing CSR, not alliterating it.

Yes, but there would be no reason to compress RFC 2986 (“CSR”) into a structure that is different from the structure we use for compressing RFC 5820 (“X.509”).

Grüße, Carsten