I don't know if this is relevant, but jwks.json isn't registered, because it doesn't have to be at that location. The /.well-known/openid-configuration discovery document, which is registered, uses the jwks_uri property to specify the location of the jwks. For instance, our product doesn't have the jwks at /.well-known/jwks.json for a lot of different reasons. Having a discovery document that points to your jwks makes sense, ideally you would be able to use the known discovery document at /openid-configuration, but I don't know if that is viable or makes sense for your context.
On Tue, Jul 12, 2022 at 9:26 PM Michael Richardson <mcr+i...@sandelman.ca> wrote: > > 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 > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
