keyId's do not exactly refer to keys anymore

[bblfish]

In Signing HTTP Messages 02 the only remaining algorithm is named hs2019 .
This algorithm actually covers nearly all the others, but shows a change in direction of the meaning of the keyId.
Whereas until draft-cavage-10 the keyId referred to a cryptographic key, e.g. an RSA key, and the signer then had to specify the algorithm in the signature header,

Authorization: Signature keyId="rsa-key-1",algorithm="rsa-sha256",
   headers="(request-target) host date digest content-length",
   signature="Base64(RSA-SHA256(signing string))"

The new Signing HTTP Messages states that

Derived from metadata associated with keyid. Recommend support for:...

Draft-cavage-12 has the following example

Signature: keyId="rsa-key-1",algorithm="hs2019",
     created=1402170695, expires=1402170995,
     headers="(request-target) (created) (expires)
       host date digest content-length",
     signature="Base64(RSA-SHA256(signing string))"

and the latest 02 IETF spec has

Signature-Input: sig1=("@request-target" "host" "date"
    "cache-control" "x-empty-header" "x-example"); keyid="test-key-a";
    alg="hs2019"; created=1402170695; expires=1402170995
Signature: sig1=:K2qGT5srn2OGbOIDzQ6kYT+ruaycnDAAUpKv+ePFfD0RAxn/1BUe\
    Zx/Kdrq32DrfakQ6bPsvB9aqZqognNT6be4olHROIkeV879RrsrObury8L9SCEibe\
    oHyqU/yCjphSmEdd7WD+zrchK57quskKwRefy2iEC5S2uAH0EPyOZKWlvbKmKu5q4\
    CaB8X/I5/+HLZLGvDiezqi6/7p2Gngf5hwZ0lSdy39vyNMaaAT0tKo6nuVw0S1MVg\
    1Q7MpWYZs0soHjttq0uLIA3DIbQfLiIvK6/l0BdWTU7+2uQj7lBkQAsFZHoA96ZZg\
    FquQrXRlmYOh+Hx5D9fJkXcXe5tmAg==:

So essentially the type of key used and the hashing function data have been removed, and are meant to be stored with the key.

This seems to have been introduced to remove some attack vectors related I guess to the signature being replaced with a another valid one on a easier to crack hash function.

Consequence

In the HttpSig document I have the keyId as a URL which dereferences to the following description:

@prefix cert: <http://www.w3.org/ns/auth/cert#> .

<#k1>  a cert:RSAPublicKey;
     cert:modulus "00cb24ed85d64d794b..."^^xsd:hexBinary;
     cert:exponent 65537 .

It should I think be something closer to this:

@prefix cert: <http://www.w3.org/ns/auth/cert#> .

<#k1> uses [  a cert:RSAPublicKey;
         cert:modulus "00cb24ed85d64d794b..."^^xsd:hexBinary;
         cert:exponent 65537 ];
    :with Sha256 .

This may mean that did:key no longer quite fit - if that is they only refer to keys (but let us what the did:key folks give as answer to my question).

Is there a name for such an cryptoKey × hashingAlgo pair?

[bblfish]

It think that the problem I described above is no longer valid with the April release of Signing HTTP Messages v03. See @jricher's mail to the HTTP Bis WG.

[jricher]

@bblfish Sorry for the confusion between the versions, we (the HTTPSig editors) are tackling the biggest changes a piece at a time and that can lead to confusion like this! The changes in -03 signal the intended direction of the spec: separate specification of the key identifier and algorithm, for implementations that need to specify that. If you can get both from just the key, that's also allowed. (this is the "hs2019" style behavior)

Also, previously the algorithm and other content was not covered under the signature which lead to some possible substitution attacks, but this has all been addressed in -02 so the old motivation for deprecating all the specified algorithms has also gone away.

We welcome any additional feedback on the HTTP Sig spec to make sure that it's applicable across a wide variety of use cases like this.

[bblfish]

Ah great, to hear that.
I understand why moving the signature to its own separate header was such an important move.
I should be able to provide some feedback on the draft pretty soon, now that I have implemented RFC8941.

[bblfish]

I think I found a bug in "Signing HTTP Messages", and reported it here: httpwg/http-extensions#1456

But I think this issue can be closed, as the new spec allows the algorithms to be specified again.