Leverage RFC7518 to specify cryptographic algorithms

[brentzundel]

@AxelNennker moved from CCG (w3c-ccg/did-spec#38)

[selfissued]

I agree that we should use algorithm identifiers from the IANA "JSON Web Signature and Encryption Algorithms" registry at https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms. And when new algorithm identifiers are needed, we should proactively register the additional ones needed. Note that only a public specification is needed to do this - not an RFC.

[msporny]

The DID spec doesn't specify things at the RFC7518 level... but the cryptographic suites do, and yes, they should reference RFC7518 when possible.

That said, there is nothing for us to do w/ the spec currently. If the spec starts doing things at the RFC7518 level, then we should reconsider. Closing unless there are objections in the next 7 days. If there are objections, concrete spec text should be proposed.

[selfissued]

The spec needs to specify things at this level if we're to achieve interop. I object to closing this issue.

Note this may also be related to #169.

[msporny]

The spec needs to specify things at this level if we're to achieve interop. I object to closing this issue.

Ok, then this will need to be discussed in the group. We had previously (at the 2019 DID WG meeting at W3C TPAC) agreed that we were not going to put normative statements like this into the specification as how a DID Document is secured was out of scope. It sounds like you're now wanting to revisit that decision.

[burnburn]

Chairs will schedule a call to discuss.

[selfissued]

Per #169, while we should embrace use of pertinent external registries, such as those administered by IANA, any normative definitions not in stable documents, such as W3C Recommendations, IETF RFCs, or IANA registries, so that the whole of what is needed by implementers is either in stable references or in this specification.

[selfissued]

JWK key representations can include an "alg" value specifying use of an algorithm from the IANA JSON Web Signature and Encryption Algorithms registry.

[selfissued]

I would suggest that at least some the JWK Examples requested in #171 include an "alg" field.

[OR13]

You need an external description if its not a JWK... so adding a property that only works for JWK does not help.

[OR13]

and JWK can have arbitrary JSON... so in general, it's not enforceable.

[msporny]

I'm suggesting that this issue has been overtaken by events. Yes, we use JWA and we use the Linked Data Security stuff to specify algorithms... so we use both. What action needs to be taken? If there is no action, then there is nothing to do, and we should close this issue.

[OR13]

but if specifying alg is a best practice... I suppose we could add support for that here: https://github.com/w3c-ccg/lds-jws2020

The reason we didn't do this, is that a best algorithm is knowable from the kty and crv... in other words, we didn't like the idea of allowing people to specifically request old md5 / rsa crypto that is not safe....

technically, you can use a base58 encoded public key, convert it to JWK, and guess that ES256K should be used... because thats literally the only registered alg for secp256k1... for RSA keys, its a little harder.... but for NIST curves, there are similarly only 1 choice... so I'm not sure we would be doing much other than increasing attack surface by adding alg to JWKs... because you can do that right now... they are of type @json... which means arbitrary JSON is supported.

If we want to restrict JWKs further, and add a requirement that if publicKeyJwk is used then it MUST have an alg field.... I suppose we could do that.

[OR13]

Related Issues:

decentralized-identity/didcomm-messaging#52
w3c-ccg/lds-jws2020#12

I think the same concern applies for JWE as JWA... in other words... does DID Core make recommendations regarding expressing support for JWA and JWE inside a publicKeyJwk... or does it rely on the suite to make that recommendation.

[OR13]

I think its related to the special call, we do recommend algorithms for jose like so: https://github.com/w3c-ccg/lds-jws2020#supported-jose-algorithms to be discussed on the call.

[OR13]

We don't need to rely on RFC7518, we need to rely on suite authors to define the relationship between suite "type" and external registries. DID Core does not require us to import a registry, see the JWS example I provided... that suite relies on IANA... other suites don't.

[OR13]

@msporny noted on call... the discussion we had on the special topic call, and naming... the group said the job was someone else job... we are discussing naming, and what those specs say... we believe thats outside the scope of the DID WG... its up to the crypto suites to link to JWK, and we are doing that elsewhere....the group has decided that this is (now) not in our purview... and i think it will result in what you want, and some suites will refer to...

[selfissued]

To the extent that we have PublicKeyJwk key representations, we should include algorithms registered in the IANA JOSE Algorithms registry as "alg" values in the JWKs.

[OR13]

why, JWK alg values are registered here: https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms

suites that support them are responsible for saying so....
DID Core does not define suites, and per our last special topic call, has no opinion regarding their names....

Case in point:

• https://github.com/w3c-ccg/lds-jws2020#supported-jose-algorithms=
• https://w3c-ccg.github.io/ldp-bbs2020/

[selfissued]

DID Core doesn't define crypto suites but does define key representations, which use crypto suites.

[OR13]

@selfissued DID Core does not define JWK, which links those 2 things in one way, how they are linked in other ways would require controlling those suites... In the last special topic call, you and @jricher made it clear you did not care how that linkage was defined for Linked Data.

I wish we could have done that work here, because there are opinions about binding of the linkage between the concept of kty / crv and alg....

For example, I prefer to not bind the"verification method type" to the "signature type"... I like the style of JWK / JWS.

However, others don't agree, they prefer something that looks more like this:

EcdsaSecp256k1VerificationKey2019 + EcdsaSecp256k1Signature2019
SchnorrSecp256k1VerificationKey2019 + SchnorrSecp256k1Signature2019

vs

JsonWebKey2020 => [EcdsaSecp256k1Signature2019, SchnorrSecp256k1Signature2019, JsonWebSignature2020]

[selfissued]

@OR13 - this is the second time that you've asserted that @jricher and I don't care about naming, where at least for me, that is far from true. There must have been some misunderstanding on the special topic call that you're referring to. We should try to get to the bottom of it and correct it.

I would certainly prefer that we go with the simpler algorithm naming scheme that you cite:

JsonWebKey2020 => [EcdsaSecp256k1Signature2019, SchnorrSecp256k1Signature2019, JsonWebSignature2020]
What do we need to do to accomplish that?

Finally, I'll assert that issue #169 pertains to the set of decisions you're referring to. We want the DID WG to be in control of its own destiny in terms of the names used in DIDs. DIDs and DID methods should not need to refer to registries administered by community groups to have complete solutions.

[OR13]

@selfissued @msporny @dlongley @tplooker Agreed #169 is relevant.

We are talking about https://w3c-ccg.github.io/ld-proofs/#linked-data-signatures

JsonWebKey2020 and JsonWebSignature2020 are defined here: https://github.com/w3c-ccg/lds-jws2020
Bls12381G2Key2020 and BbsBlsSignature2020 are defined here: https://github.com/w3c-ccg/ldp-bbs2020

Both of these suites were discussed on the special topic call... recall the objection was to the naming convention of the "verification method type" side of them (some folks want the word "Verification" in all the names)....

verification methods are defined (by did core) here: https://w3c.github.io/did-core/#dfn-verificationmethod

this is where the linkage to linked data suites exists... the values for type in a DID Core verification method are expected to be defined by a linked data suite.... linked data suites are defined anywhere, just like JOSE alg's can be defined anywhere and registered with IANA.... concrete example:

https://github.com/decentralized-identity/SchnorrSecp256k1Signature2019

^ i created this suite, and I defined a new JOSE alg SS256K based on your feedback over email :) (thanks btw)

I then used that alg to created a linked data signature suite SchnorrSecp256k1Signature2019 that relies on JWS and secp256k1 JWKs, which can also be used for ES256K and EcdsaSecp256k1Signature2019.

SS256K is not registered anywhere, SchnorrSecp256k1Signature2019 is not registered anywhere... but we might try and register the verification method type in did spec registries, as I did for JsonWebKey2020...

@msporny and others objected to the name I chose for the suite verification method type "JsonWebKey2020" because it supported algorithmic agility, and when against an undocumented ccg naming convention.... we needed to document the convention somewhere to provide guidance on naming.

We then voted on whether DID Core should have spec text about naming suite verification method types, or if a ccg group should. You, Justin and Dan all suggested the CCG should handle it... in other words... the CCG gets to decide what conventions we should be using for "verification method type" names... because they control the linked data signature spec.... This was not the outcome I wanted :)

I wanted DID Core to control the conventions for verification method type naming....

In order for DID Core to control the naming conventions associated with a verification method type, that might be defined in a spec maintained by the CCG, we would need to write spec text, addressing linked data suites... in much the same way you are proposing we write spec text addressing JWS/JWE/JWK.... my preferred solution to this problem was to just create a linked data suite that supported JOSE, and then use that suite to power the needs of JOSE users... thats where we ended the special topic call, but with the caveat that some folks don't like the names we chose: JsonWebKey2020 and JsonWebSignature2020... and we might change them later.

Per the WG Charter: https://www.w3.org/2019/09/did-wg-charter.html

The following is out of scope:

Defining specific authentication, signing, or cryptography mechanisms. Scope is limited to defining extension points for these mechanisms. (See "Scope".)

I believe this is consistent with not registering the JWA alg or proof type values, but registering kty/crv / verificationMethod.type... when we registered JsonWebKey2020 we defined an extension point whereby JOSE developers could leverage JWKs to work with JWS/JWE with various alg values defined here: https://github.com/w3c-ccg/lds-jws2020#supported-jose-algorithms

Put another way... I don't think the DID WG needs to (or is chartered to) address "signatures" or "proofs" at all... I think we only need to describe the representations of verificationMethods... and while I would have liked to provide guidance on naming... I am also happy to let the CCG, DIF, IETF, OIDF or others do that.

I do agree this is a bit awkward... and it stems from the following issue:

some folks in the linked data community want to name verification methods according the "key type + cryptographic operation type + interface combo".... which hard couples them all together... others want to name the method more generically "PublicKey", and use other object members to describe that it is meant to only work with a single signature type, or supports key agreement.... (like how usage is defined in web crypto)..

The current convention taken by linked data signature suites is intentionally different then the way that IANA JOSE registries are configured... and the reason given has been "security / cryptographic agility is considered harmful...". See https://github.com/w3c-ccg/lds-jws2020/issues/4

As a developer who works with lib sodium (non agile), jose and gpg and ssh (agile)... i find this "SignatureVerificationKey/KeyAgreeementKey style".... confusing... and... one might argue that the DID WG cannot write spec text hard coupling a public key representation to a cryptographic function due to the language in the charter... since it forces the key representation to define exclusive support for a single cryptographic interface... when we all know that secp256k1 can be used for ECDSA, ECDH or Schnorr....

I personally would love to see JsonWebKey2020 next to Ed25519Key2020 and leave the supported alg JWA / JWE / signature / proof representation requirements to the CCG or the spec author... I'd rather not define anything related to "specific signatures or encryptions"... especially if we can't get agreement on how the cryptographic material should be represented independently of them.... but that is where the contention is... some folks think that verification material should never be represented independently of signature type and key use.

My hope is that through open dialog, we will develop some language for both did core and ccg specs, which is respectful of JOSE, GPG and SSH and also new cryptographic aesthetics like lib sodium / linked data proofs which some feel have superior security characteristics due to different naming conventions / object structure.

[selfissued]

I spoke with @OR13 about the details of this and I now believe that since we have JsonWebKey2020 registered in the DID Core Registries, that de-facto means that people can use algorithms from the IANA JSON Web Signature and Encryption Algorithms registry https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms with DIDs, which was the point of this issue.

I'm willing to declare victory and close this issue on that basis. Thanks all for the good discussion.

[brentzundel]

No comments since marked pending close, closing.