AW: Can I only use JsonWebKey2020 with NIST approved curves like P-256 in the specification?

Dear Brent, Orie, all,

 

could it make sense to create a generic verification method type, which

is parametrized by something like an ASN.1 AlgorithmIdentifier?

 

AlgorithmIdentifier  ::=  SEQUENCE  {

        algorithm               OBJECT IDENTIFIER,

        parameters              ANY DEFINED BY algorithm OPTIONAL  }

 

At least from an old school PKI-minded perspective it seems to be

odd to create a completely new verification method type for each and 

every signature algorithm. 

 

What do you think about creating such a generic verification method, which would

be able to handle all “standard” digital signature algorithms?

 

BR,

Detlef 

 

Von: Orie Steele <orie@transmute.industries> 
Gesendet: Samstag, 24. April 2021 04:19
An: Brent Shambaugh <brent.shambaugh@gmail.com>
Cc: Credentials Community Group <public-credentials@w3.org>
Betreff: Re: Can I only use JsonWebKey2020 with NIST approved curves like P-256 in the specification?

 

I suppose the correct thing to do here would be:

A. Allow JsonWebKey2020 to support none publicKeyJwk material expressions (not add new NIST curve key types)
B. Create P256ES256VerificationMethod2020 (etc) for all NIST Curves, and then allow them all to be used with JsonWebSignature2020

B would be in the style of EcdsaSecp256k1VerificationKey2019 and Ed25519VerificationKey2018... both of which are used to verify detached JWS.

A would be less work, but might require some explaining... luckily...

The suite could explain the history of the anti JWK holy war, and how it was ultimately made irrelevant by giving suite authors the ability to support whatever they needed to make developers happy :)

Happy to take feedback on what would make developers the most happy here.

OS



 

On Fri, Apr 23, 2021 at 8:08 PM Orie Steele <orie@transmute.industries> wrote:

Thanks for your question Brent!

TLDR I don't think there are any official suite names for multibase encoded NIST curves... UnsupportedVerificationMethod2020 is my not so subtle swipe at the strategy of requiring a unique name for every registered kty and alg in IANA :)

We created JsonWebKey2020 and JsonWebSignature2020 because we don't think you should have to have a new key and signature type for every JWS alg.

The questions you are asking are a major part of why we created these suites... in essence, we believe Linked Data should work with JOSE seamlessly.

We thought "UnsupportedVerificationMethod2020" was too snarky, so we decided to just stop saying it, and to make `JsonWebKey2020` support base58 as well.

our libraries handle key conversion for you so you don't need to worry about which side of this war you are on.

I'm actually working on updating the contexts to align the new did core structurers right now:

https://github.com/transmute-industries/ns.did.ai/blob/master/suites/jws-2020/v1/index.json#L25

We can very easily allow publicKeyJwk, publicKeyBase58, publicKeyMultibase or just publicKeyJwk.

How do folks want this to work?

OS








 

On Fri, Apr 23, 2021 at 5:05 PM Brent Shambaugh <brent.shambaugh@gmail.com <mailto:brent.shambaugh@gmail.com> > wrote:

I have this for a NIST approved curve in my DID document:

    "publicKeyJwk":  {
          "crv": "P-256",
          "kty": "EC",
          "x": "u-cNviWRiM3i9wGjUvOB-0XyPpIb5rAwmE8o8jDBte7Y",
          "y": "uHNNnF7isXk_qitI9yNB4PCMY7krXqA224AJq0LByok8",
        },
        "type": "JsonWebKey2020"

I thought that nist based keys like P-256, p-384, and p-521 did not have a supported name type so one had to use the  catch all JsonWebKey2020. I cannot remember if there is a link.

I'm trying to replicate my reasoning. I believe I looked at:
https://www.w3.org/TR/did-spec-registries/ ,
https://github.com/w3c/did-spec-registries/blob/main/cddl/verificationMethodTypes.cddl ,
 https://github.com/transmute-industries/did-key.js/blob/e0b4facde18691f914bb184dbb64e678601f0a88/packages/test-vectors/src/did-core-conformance/p-256/p-256.json#L23-L29 , and perhaps several others
and concluded that I could not match the a type property with a publicKeyBase58 encoded key .
 

The earlier Transmute commit uses "type": "UnsupportedVerificationMethod2020"  in conjunction with a publicKeyBase58 encoding. I take it that Orie is a significant driver in the specification, so he would be in the know.

For the record the new version of this file no longer contains this block of code  https://github.com/transmute-industries/did-key.js/blob/master/packages/test-vectors/src/did-core-conformance/p-256/p-256.json .

https://tools.ietf.org/html/rfc7517#section-3 told me that I could express a publicKeyJwk key as a P-256 key. This was supported by JsonWebKey2020. There may have been another place that I read that p-256 was only supported by
JsonWebKey2020.

Am I correct that I can only use JsonWebKey2020 and Json web keys? Not JsonWebKey2020  or some mystery type and publickeybase58 based on the specification?

Thanks for your time, i

 

-Brent Shambaugh

GitHub: https://github.com/bshambaugh
Website: http://bshambaugh.org/
LinkedIN: https://www.linkedin.com/in/brent-shambaugh-9b91259
Skype: brent.shambaugh
Twitter: https://twitter.com/Brent_Shambaugh
WebID: http://bshambaugh.org/foaf.rdf#me




 

-- 

ORIE STEELE

Chief Technical Officer

www.transmute.industries

 

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




 

-- 

ORIE STEELE

Chief Technical Officer

www.transmute.industries

 

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