EXEC-SUM: /.well-known/jwks.json seems in use, but not registered
with IANA. I don't know if it's appropriate for my use.
Seems to contain RFC7517 content.Hi, in draft-ietf-anima-constrained-voucher we are creating a CoAP/CBOR version of RFC8995 (BRSKI). One thing that we want to avoid is any extra keys or certificates in the constrained voucher. If we have certificate chains that *do* need to be transmitted we will use x5bag. As BRSKI has three parties: MASA (signer), Registrar (audit/owner), Pledge(relying party/verifier) In general, the Pledge is built by the same entity as runs the MASA, and so the in the simplest form, the Pledge can be built with appropriate trust anchors. (There could be PKI trust roots built-in, or self-signed EE) In the constrained situation, we can sign with a raw public key using CWT. The Registrar would ideally like to verify the signatures. The Registrar would in many cases get the right anchors to verify the signature via a supply chain integration. There are other situations where a TOFU is appropriate. In either case, we'd like to automate the transfer of the keys from MASA to Registrar. In a supply chain integration, then an operator might validate the keys before they are activated, but online transfer makes a lot of sense to reduce errors, particularly as keys get bigger in a PQ world. It was suggested that if we just knew the manufacturer's URL, that /.well-known/jwks.json would work for us. I think it would. I see "documentation" at: https://www.baeldung.com/spring-security-openid-connect (section 6) https://www.baeldung.com/spring-security-oauth2-jws-jwk which seem to refer to keys in RFC7517 format. Note: We have three anchors that we might like to deploy. 1) the key that signs the RFC8366/constrained-voucher objects. Could be a RPK. 2) the key that signs the IDevID certificates in the devices. Most likely a RFC5280 self-signed certificate, but of course, it's a trust anchor, so likely only the public key matters. 3) the manufacturer could have a CA trust anchor, and #1 and #2 might be provided via subordinate CAs, and only #3 needs to be transfered. (#1 is an EE certificate) draft-richardson-anima-masa-considerations actually discusses some of the options here. -- Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
