Re: [OAUTH-WG] .well-known/jwks.json and constrained-voucher and RFC7517

[Warren Parad <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>