support did-jwt ?

[bblfish]

The current HttpSig spec proposal suggests that did:key can be used as a keyId. There is an open issue whether did:keys refer to just the cryptographic key or more.

@David-Chadwick in his response to issue 156 points to the work on did+jwt, which looks like it contains the other parameters needed for HttpSignature. (For some reason it is not called did:jwt but did:ethr) My guess is that a signature containing the key would then need to also sign the header containing the did:ethr. Such a header would look something like this:

GET /events/party HTTP/1.1
Accept: */*
Authorization: HttpSig sig="sig1"
Signature-Input: sig1=("@request-target");\
    keyid="did:ethr:0xf3beac30c498d9e26865f34fcaa57dbb935b0d74'";\
    created=1402170695
Signature: sig1=:QaVaWYfF2da6tG66Xtd0GrVFChJ0fOWUe/C6kaYESPiYYwnMH9eg\
    OgyKqgLLY9NQJFk7bQY834sHEUwjS5ByEBaO3QNwIvqEY1qAAU/2MX14tc9Yn7ELB\
    naaNHaHkV3xVO9KIuLT7V6e4OUuGb1axfbXpMgPEql6CEFrn6K95CLuuKP5/gOEcB\
    tmJp5L58gN4VvZrk2OVA6U971YiEDNuDa4CwMcQMvcGssbc/L3OULTUffD/1VcPtd\
    GImP2uvVQntpT8b2lBeBpfh8MuaV2vtzidyBYFtAUoYhRWO8+ntqA1q2OK4LMjM2X\
    gDScSVWvGdVd459A0wI9lRlnPap3zg==:

As I understand "Signing HTTP Messages" always signs the Signature-Input header, so that should make it impossible to change the did:ethr key.

But then I am not sure what the problems with adding the key parameters to the header in Signing Http Messages were, when they write for the previous rsa-256 algorithm (and all other previous ones for that matter)

Status: Deprecated; specifying signature algorithm enables attack vector.

My guess is that this means that there is a place between the end of the ssl connection and the web server where traffic could be in the open, where such headers could be replaced, the hash sum changed to something easy to forge like SHA1 and a new forged signature placed in its stead.

If this is the right guess - cryptographers seem to secretly believe in security through obscurity, as they rarely state things clearly - then this could still happen with a did-jws URL, I guess. Unless the did:jwt URL is itself signed with its own private key? Would that be possible without using SHA if the URL is short enough?

Another option would be to consider introducing pure cryptographic signatures say rsa on the HttpSig headers, where no use of hashes is made. Would that be possible? Could we suggest that to the IETF working group?

[David-Chadwick]

@bblfish wrote

(For some reason it is not called did:jwt but did:ethr)

This is not quite correct. did:jwt is our chosen did method name, but it has not been published yet in the did method's repository. We only have a draft in .txt format so far. (The reason we have not published it yet, is that we have not got to grips with the W3C draft spec publishing scripts and how to use them)

[dmitrizagidulin]

While I hope we can support most DID methods, what's the use case for focusing initially on did-jwt? (Instead of, say, did:key or did:web?)

[bblfish]

I have no idea which of did:key or did:jws is better. I'll leave it to the did community to decide.
For the moment did:jwt does perhaps have the advantage of being easy to parse and create, as base64URL encoding the jwt which is well known and easy. Are there tools to look at the did:key structure?

I could not quite work out if there was an encoding for RSA keys. It just need tools with which I can work.

An I see Dimitri left me a message on gitter:

right, did:key doesnt support rsa because the rsa key is too big

[bblfish]

The deeper problem is to work out why hs2019 is the only supported algorithm in Signing HTTP messages as pointed out above. Because if the attack it is meant to defend against is the changing of the signature algorithm, then would not both did:key and did:jwt have the same problem? The signature algorithm could also be changed on the non secured connection, no? (Unless one were to propose signing headers directly with the RSA key without going through the hash algorithm?)
Anyway I am only trying a best guess as to what the problem is. It would be really useful to know precisely what the attack was, so that we can make sure we don't reproduce the same problem differently, or if there are mitigation strategies.

[David-Chadwick]

right, did:key doesnt support rsa because the rsa key is too big

There are no such size contstraints in did:jwt

[David-Chadwick]

is meant to defend against is the changing of the signature algorithm, then would not both did:key and did:jwt have the same problem?

Not for did:jwt, because this is meant to be used for self-signing VCs or VPs using JWT. Hence the kid is inside the signature, and thus cannot be changed.

[bblfish]

Have you thought of encoding did:jwt in a binary JSON format like BSON? And then perhaps using something more efficient than base64, if that exists?

[David-Chadwick]

No, because we want to conform to both the JWT and VC standards. Thus we have "kid":"did:jwt:<base 64 encoding of public key params>" Also size is not a problem. Base64 encoding is cpu efficient and the transfer size increase is minimal.