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 > <[email protected]> wrote: > > 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 > > > _______________________________________________ > COSE mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/cose > <https://www.ietf.org/mailman/listinfo/cose>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
