Did-core: Remove publicKeyPem from did core and did spec tests

[OR13]

[kdenhartog]

I'm a +1 to removing PEM format. It gets us closer to our goals of consolidating key formats and types.

[msporny]

+1 to close.

[OR13]

https://github.com/w3c/did-spec-registries/issues/126

We can't close this until publicKeyPem from did core and did spec registries.

[kdenhartog]

publicKeyPem is no longer defined in did-core spec and PR ^ removes from registries spec and context (Should I create a v2 context instead of just deleting?)

[peacekeeper]

Even though personally I don't have a strong opinion here, I do want to mention that the WG had several dedicated calls that discussed key formats. As far as I remember there was broad support for allowing publicKeyPem for RSA keys, in order to be compatible with OpenSSL and other widely used tools. This was then removed in https://github.com/w3c/did-core/pull/407, and I am not sure if everyone who cares about this has noticed the removal, given the innocent-sounding title of that PR ("cleanup").

There are definitely existing DIDs out there that use publicKeyPem.

[msporny]

publicKeyPem is no longer defined in did-core spec and PR ^ removes from registries spec and context (Should I create a v2 context instead of just deleting?)

No need to create a v2 context -- v1 is still considered unstable.

As far as I remember there was broad support for allowing publicKeyPem for RSA keys, in order to be compatible with OpenSSL and other widely used tools.

This is correct. The thing that changed was the creation of the JsonWebSignature2020 cryptosuite, which allows the expression of PEM-encoded keys for RSA. publicKeyPem is therefore no longer needed... the RSA legacy key format is expected to be expressed using the JsonWebSignature2020 cryptosuite. publicKeyPem comes from a time /before/ JOSE was standardized -- it's over 8 years old, IIRC and given the deployment of JOSE and that it's a legacy format that's being phased out, we don't need to carry the PEM mechanism forward since we'd end up having two different cryptosuites that both supported PEM.

What we really should be doing is NOT talking about the cryptosuites in the DID Core specification in any sort of normative way. I'll try to submit a PR for that (which I expect will fail because for some reason, a subset of us can't seem to get their mind wrapped around the fact of deferring the normative cryptosuite stuff to other specifications).

[OR13]

There are definitely existing DIDs out there that use publicKeyPem.

There are probably DIDs out there using MD5 and SHA1... I wouldn't recommend that continue...

The more key representations in the did core, the worse the spec, same thing for did document representations, its painful complexity, and requires lots of checking and conversion logic to retain interop.

Best case for did core v1 would be 1 representation, 1 key format.

Worst thing for did core v1 would be 3+ representations, 3+ key formats...

we currently have JWK and Base58... if we add PEM we will add more burden on developers.... there are lots of registered did methods in the spec registries that use publicKeyHex... we could add support for that too, where does it end?... our job is to reduce optionality... we need a future facing key representation (my preference is mulitcodec / multibase) and a legacy facing one (my preference is JWK)....

Any other key representations should be added as "extensions" to the did spec registries.

[kdenhartog]

I may be looking at this from a slightly different perspective, but because we've got a registry that allows the registration of any crypto suite and cryptosuites define which key representation is used, I'm tend to agree that DID Core should not be defining these properties for similar reasons that @msporny alludes to in the comment above. Ideally instead this should be left up to ld-proofs spec which will set constraints on defining suites and then we would go that route.

In my mind, the only reason we're defining these at core properties and having this discussion at this time was so we could give practical examples of how the ld proofs suites integrate into a did document and to set some base patterns and structures that can be adhered to through any representation of a DID Document.

[peacekeeper]

Agree with explanations above about removing publicKeyPem, thanks.

I also agree that theoretically it would be nice to just reference LD proof and cryptosuite things, rather than (re-)defining them in DID Core, but not sure if that's achievable in the short term..

[kdenhartog]

I think this can be closed right away now that @OR13 has merged https://github.com/w3c/did-spec-registries/pull/155

however, just to be conservative I'll just label and this will be closed in 7 days.

[TallTed]

Given that the only reason to include specific discussion of any crypto suite is so that we can offer "practical examples of how the ld proofs suites integrate into a did document and to set some base patterns and structures that can be adhered to through any representation of a DID Document", I would actually suggest consideration of one _known-terrible_ crypto suite (e.g., MD5, SHA1) as the only one specifically mentioned/discussed/exemplified.

Along with strong language indicating that choosing this one would be Very Very Bad for someone's deployment, and suggesting they go explore the registry.

Rather than including any "reasonably good" suite of today, which might well be exposed as being TERRIBLE tomorrow....

This comment should not block removing publicKeyPem and closing this today.

[brentzundel]

No objections raised to closing since marked pending close, closing.