Match changes requested in the RFC process for 1.3 signing

[jaym]

The message format has been updated. We no longer hash user id and path. Hashing these things is no longer required. The reason they were hashing in v1.0/v1.1 is because the message was directly signed. This meant that there was a limit on the size of the message. v1.3 does not have this requirement as RSASSA-PKCS#1-v1_5 signs a hash of the message.

[markan]

Generally looks good. The cleanup to eliminate the subcomponent hashing is quite worthwhile.

The one change I might make is adding RSA to signing algorithm name (RSA_SHA256or the like)

[jaym]

I'm not sure I understand. Do you mean instead of 1.3 use RSA_SHA256?

[btm]

SIGNING_ALGORITHM_RSA_SHA256 ?

[jaym]

oh i see the confusion. That constant should really just be called HASHING_ALGORITHM_x. I'm not sure I could change that as it is kind of public, so the SIGNING_ALGORITHM_SHA256 name was chosen to match SIGNING_ALGORITHM_SHA1

[stevendanna]

cc @chef/lob

[markan]

@jaym Sorry for not following up on that.
I was proposing changing

chef_authn/src/chef_authn.hrl

Line 31 in 1139c81

-define(SIGNING_ALGORITHM_SHA256, <<"sha256">>).

to
-define(SIGNING_ALGORITHM_RSA_SHA256, <<"rsa_sha256">>).
(along with the natural cascading fixups)

The idea is if in the future we needed to add ecdsa_sha256 or whatever it would be more obvious which encryption algorithm was in play.

[jaym]

@manderson26 renamed... I was worried the change wouldn't make sense, but I think it still does. Perhaps a quick glance through what changed, make sure it still reads in a sane way

[marcparadise]

Instead of proplist, can we just have call into a matched fun header in chef_authn.erl? e.g.

signing_protocols_for_version(?SIGNING_VERSION_V1_0) ->
  [?SIGNING_ALGORITHM_SHA1]; 
signing_protocols_for_version(?SIGNING_VERSION_V1_1) -> 
  [?SIGNING_ALGORITHM_SHA1]; 
% etc

[marcparadise]

This looks good, I just had the one minor comment above.

👍 once implemented