Replace RsaSignature2017 by a standard JWA signature about did-spec HOT 12 CLOSED

The did-spec uses RsaSignature2017 seven times but never defines it or references a specification that specifies it.

This is a problem and we should resolve it by submitting a PR that links to the appropriate specifications in a non-normative fashion.

I suggest to use RFC7518 signatures whenever the did-spec specifies a cryptographic signature algorithm.

The group has discussed this and has chosen specifically not to reference RFC7518 directly in the DID Spec and instead specify "signature suites" instead, which then reference RFC7518.

What is the status of https://w3c-dvcg.github.io/lds-rsa2018/ ?

It's implemented and deployed but woefully under specified. We need to circle back around and update the spec after we get a little more implementation experience.

Is there a @w3c working group moving it to recommended standard?

Not yet no. There are political issues that we are currently attempting to navigate. Fundamentally, we are not going to move into any standards track until we have more deployment on the specs due to the shifting nature of the way standards bodies are now operating (they're requiring far more field testing/pilots before submitting something standards track).

from did-spec.

We should resolve this issue by submitting a PR that references the appropriate signature suites.

from did-spec.

There is a PR AxelNennker#1
I suggest to merge it and work from there. The PR makes the did-spec consistent and leverages existing standards.

The examples provide in did-spec should only then use RsaSignature2017 after it is spec'ed and likely to become a standard.

Avoiding directly referencing rfc7518 might be doable although probably convoluted and cumbersome - please send a PR.

At lease one example should use rfc7518. You could leave the signature part out in the examples when the signature is not really relevant to the example thus avoiding specifying a specific signature standard but complete example have their own value...

from did-spec.

The examples provide in did-spec should only then use RsaSignature2017 after it is spec'ed and likely to become a standard.

Avoiding directly referencing rfc7518 might be doable although probably convoluted and cumbersome - please send a PR.

At lease one example should use rfc7518. You could leave the signature part out in the examples when the signature is not really relevant to the example thus avoiding specifying a specific signature standard but complete example have their own value...

Well, the thinking here is that the DID spec should reflect what implementers have said they are actually doing -- so the examples should adhere to that. Other specs at W3C have followed this notion of "reflecting reality" vs. "specifying something no one is using". RsaSignature2018 uses PS256 from RFC 7518 and Ed25519Signature2018 uses RFC 8032, so we can reference them from those specs.

from did-spec.

Seems dangerous to base did-spec on something that is not thoroughly discussed and blessed by w3c.
If w3c security experts or others find reasons to reject RsaSignature2017 or Ed25519Signature2018 then did-spec is in trouble.

Referencing non-standards will likely hinder did-spec become a standard.
Referencing RsaSignature2017 or Ed25519Signature2018 in a non-normative way as @msporny suggested does not really help this, I think.

I think that getting did-spec approved as a w3c standard easier is easier if did-spec builds on other approved standards.

from did-spec.

There is a PR AxelNennker#1 I suggest to merge it and work from there. The PR makes the did-spec consistent and leverages existing standards.

That PR makes modifications to a section of the spec that is being taken out per community consensus. So, it won't exist in a couple of weeks. As Dave Longley said, we do reference RFC 7518 and RFC 8032 appropriately in the signature suites.

The examples provide in did-spec should only then use RsaSignature2017 after it is spec'ed and likely to become a standard.

There are multiple people in the CCG that oppose vanilla use of JOSE. We have wrapped JOSE and are using specific profiles of it (e.g. JWS). We are not inventing new crypto, we're just wrapping select parts of JOSE (such as JWS) where we need it. We're using a very slim profile of JOSE.

Avoiding directly referencing rfc7518 might be doable although probably convoluted and cumbersome - please send a PR.

We have consensus in the CCG that referencing RFC7518 through the signature suites is the proper way to go and provides the right layers of abstraction.

At lease one example should use rfc7518. You could leave the signature part out in the examples when the signature is not really relevant to the example thus avoiding specifying a specific signature standard but complete example have their own value...

No, this would break the security model and enable far too many allowable input combinations wrt. cryptographic options. We are being very careful to prevent developers from getting access to everything in JOSE as using the wrong options and the wrong times can lead to security vulnerabilities. Linked Data Proofs/Signatures attempts to protect developers from the configurability of JOSE/JWS/JWK.

from did-spec.

@AxelNennker,

I think that getting did-spec approved as a w3c standard easier is easier if did-spec builds on other approved standards.

While true, it has the opposite problem -- implementers will not use those existing standards (without caveats) for a variety of reasons. To be clear though, the DID spec does build on other standards. Implementers are just not going to use the JOSE stack without restricting it to a certain profile. The "signature suites" we're talking about build on top of JOSE and provide appropriate constraints for better security.

This means we've got to make a choice as to how to move forward. My view is on the side of getting working implementations from people and companies in the community and making the spec accurately reflect where that momentum is. I think that approach will be more likely to breed success than leaving out what people are using from the spec because it hasn't yet achieved a certain level of attention via the official W3C process. It will only lead to confusion and slow down the work, IMO.

from did-spec.

The current version of did-spec 0.9 does not mention RsaSignature2017 anymore.
Now it uses RsaVerificationKey2018, RsaSignature2018 etc without defining them.

Good for current implementers if they know what all this means. Running code has a high value and different implementations demonstrate interoperability but running code is not a spec.

from did-spec.

@msporny

There are multiple people in the CCG that oppose vanilla use of JOSE. We have wrapped JOSE and are using specific profiles of it (e.g. JWS). We are not inventing new crypto, we're just wrapping select parts of JOSE (such as JWS) where we need it. We're using a very slim profile of JOSE.

Profiling other specs is good but this profile has to be written down. Currently this is missing in did-spec.
Care must be taken with profiles though that they stay compatible to the base spec and that they don't violate the base spec's security assumptions. A discussion about signature in did-spec is difficult as long as there is nothing specified and written down.

What is the difference between RsaSignature2018 and RsaSignature2017? What does it mean?

from did-spec.

@AxelNennker,

To be clear, we're in agreement that the current shape of the signature suite specs is woefully inadequate.

https://w3c-dvcg.github.io/lds-rsa2018/
https://w3c-dvcg.github.io/lds-ed25519-2018/

We just need to find the time to update them and fix any references to them. At the moment, most people are busy at the RWoT conference.

from did-spec.

Basically both "reports" could be collapsed into did-spec if we add two short sections to did-spec that state:

"did-spec does not need double base64url encoding of JWS because we use RDF canonicalization.
did-spec avoids developer confusion and resulting security issues by restricting ourselves to these two algorithms"

Does this capture the essence of XSignature201Y? Or did I miss some difference between JWS and these two?

from did-spec.

Closing as we have adopted this issue in the new DIDWG repo.

from did-spec.