Re: DID Web, OpenSSL and Certificate Authorities

Thanks for your comments!

On Tue, Feb 22, 2022 at 1:58 AM David Waite <dwaite@pingidentity.com> wrote:

> On Thu, Feb 17, 2022 at 7:34 AM Orie Steele <orie@transmute.industries>
> wrote:
>
>> Hey Folks,
>>
>> What is the best way to combine DIDs with Certificate Authorities?
>>
>> The use case is simple: As a verifier, I want to know that a credential
>> was issued from a public key that is in a certificate chain I trust.
>>
>
> Do you only care about the key being in a certificate being under the
> umbrella of a trust chain, or that the key was actually issued to the
> issuer? I suspect the latter.
>
> For the second, you would be checking that the DID URI was one of the
> subject alternative names on the issuer's certificate. You could either
> include the chain or use the Certificate Authority Information extension to
> resolve the signing certificate.
>
> When I verify this credential, I not only check its signature, but I can
>> also check the CA chain from the key that signed in back to the root.
>>
>> @Mike Prorock <mprorock@mesur.io> and I have been working on a
>> simple example of this using DID Web, but I think it generalizes to any DID
>> Method that supports `publicKeyJwk` and `x5c`.
>>
>
> For DIDs which are HTTPS-backed, you might define a domain mapping rule,
> aka did:web:example.com will also match against a SAN of just example.com.
> This would allow you to use existing DV certs like letsencrypt.
>

This would be a good thing for us to explore next. I have tested this kind
of thing before with ngrok and lets encrypt... I can imagine wiring ngrok
and lets encrypt into the current openssl demo, and getting a full
integration test in place.


>
> 1. Is it possible to use JOSE to automate this further?
>>
>
> JOSE (and JWT) are really more about defining algorithms, primitives and
> formats and not about the processing steps for a particular message. As
> such, there is a gap between a comprehensive JOSE implementation and say
> tooling to handle signed id_token JWTs, with far more implementations of
> the latter.
>
> For a comprehensive library, you typically will have extension points to
> add format, trust and context information for your particular use case. The
> documentation for JOSE4J at
> https://bitbucket.org/b_c/jose4j/wiki/JWT%20Examples illustrates some of
> this extensibility in one such comprehensive implementation.
>
> 2. Is there a better way of accomplishing this?
>> 3. Should the CA chain be pushed into the JWT?
>>
>
> I suspect the proper place would be in the DID as a publicKeyJwk's x5c or
> x5u. DIDs don't really have a first-class place for trust or authority
> relationships, so I suspect this belongs in the verificationMethod today.
>

Agreed this is the solution we have shown to date. It seems likely that its
the right place for this go today, and the cert side can possibly be
improved further based on your comments regarding SAN + Lets Encrypt.



>
> -DW
>
>>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*



-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>
ᐧ