did-jws, http signature was: Crypto ontology?

> On 27 Mar 2021, at 19:12, Henry Story <henry.story@gmail.com> wrote:
> 
> 
>> On 27 Mar 2021, at 18:41, David Chadwick <D.W.Chadwick@kent.ac.uk> wrote:
>> 
>> Hi Henry
>> 
>> This is very similar to the did:jwt method that I have proposed
>> 
>> On 27/03/2021 17:26, Henry Story wrote:
>>>  "publicKeyJwk": {
>>>    "kty": "RSA",
>>>    "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMstn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbISD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqbw0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
>>>    "e":"AQAB",
>>>    "alg":"PS512",
>>>    "kid":"2011-04-29"
>>>  }
>>> 
>> It would be good if we could harmonise them
> 
> Sure :-) Can you leave some pointers at
> https://github.com/solid/authentication-panel/issues/156

Thanks for posting the links. I opened an issue on whether Solid could
support did-jws here:

https://github.com/solid/authentication-panel/issues/157

I would like the wider community here to provide some feedback on this.

We seem to have the following problem (explained more at length in the issue)
namely that various protocols (defined as a key+hash type) were removed
from ”Signing HTTP Messages” the reason given being:

> Status: Deprecated; specifying signature algorithm enables attack vector.

My guess is that the attack vector can only take place between the end of the TLS
connection and the web server [1]. Insights on this would be appreciated.

Could this be solved if one required the did (jws) key to come with its own signature -
not using a checksum of course?

But then why not sign the headers just with the pure (RSA) key? The headers to sign
should be quite short, if one does not choose too long a keyid. That may depend
on each of the crypto algorithms. I think for RSA the bit length is the maxsize
that can be safely signed, so a 4096 key could contain 585 ascii characters,
which is about 7 lines of 80char length. With a 8192 key one should be able to cover
all headers we need.

Would that work with the other encryption algorithms?

Henry


[1]  I think the token binding work was trying to
solve that but the Chrome folks refused to implement it arguing
that there should not be a security problem between the end of the TLS
connection and the web server (given that that should be within a secured space).
Ie. their argument was that this was outside the browser scope, as otherwise
why not also take into considerations security holes inside the web server?
See a set of links on the topic and links to discussions here:
https://twitter.com/bblfish/status/1365603981259595780