On Wed, Oct 25, 2023 at 02:12:44PM -0500, Orie Steele wrote: > On Wed, Oct 25, 2023 at 1:54 PM Emil Lundberg <e...@yubico.com> wrote: > > > There is the COSE header parameter 33, "x5chain: An ordered chain of > > X.509 certificates". Is that what you're looking for? > > I am looking for a matching entry in COSE Key, similar to: > > https://datatracker.ietf.org/doc/html/rfc7517#section-4.7
I think x5c in JWK is an anti-pattern. > I'm also not exactly sure what the verifier API should look like for cose > sign1's that contain x5c in protected headers. > > normally it would be: > > verified = verify(message, signature, publicKey) I presume there is also parameter for encoded protected headers? > But when x5c is present in the protected header, we expect the last cert to > verify the signature always (right?): > > https://www.rfc-editor.org/rfc/rfc7515.html#section-4.1.6 > > So what reference value should be supplied to such a verifier API? Could there be second API of type: publicKey = x509ChainVerify(trust_anchors, x509chain, reference_name) That verifies the chain, and if successful, dumps the public key to pass to the signature verify function? > Some background in case it's helpful, I'm trying to implement an identity > based verification scheme for SCITT, > where the issuer can use a regular cose key or a certificate chain > terminating in some trusted reference value. > > I can imagine supplying a list of certificate thumbprints that are trusted, > and checking that each cert in the chain matched the thumbprint list. > > or just supplying a list of root thumbprints, and only checking that the > root is in the list... > > verified = verify(message, signature, trustedRootThumbprints) > > I'm not very familiar with building x509 related APIs, or working with both > x509 and COSE. X509 is supposed to have chainbuilding step, where a trust chain is built from bag of certificates and trust anchors. However, it is more secure to skip this and require sender to send one ordered chain. However, there still is one remaining landmine (handling explicitly sent trust anchor). I would do "chainbuilding" roughly as follows: - Check that all but first certificate are CA certificates (there are two flags for this!), that subjects and issuers (and key ids) match up, certificates are not expired, that the first certificate is issued to the right party, etc... - Scan the chain for certificates matching trust anchors. If one is found, truncate the chain just before first match. - Look up trust anchor by issuer of the last certificate. If none is found, reject chain. Otherwise append the found certificate to the chain. - Then check all chain signatures except the one on trust anchor. In reality, things could get even more complicated. I have written a TLS library, and its main X509 chain validation function has about dozen parameters... -Ilari _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
