I would rather see new challenges defined with a new hash function than introduce orthogonal hash negotiation.
On 8 March 2017 at 09:40, Logan Widick <[email protected]> wrote: > I noticed that the challenges in the draft seem to be tied to the same > hash algorithm (SHA-256). Would it be possible to have the the server > include an array of supported hash algorithms, and then have the > client specify which one of the server's supported algorithms is used > in the response? This way, the hash algorithms can be changed when > needed without changing the challenges themselves. > > For example, consider the following directory, modified to include the > server's supported hash algorithms: > { > "new-nonce": "https://example.com/acme/new-nonce", > //other standard URIs here > "meta": { > "terms-of-service": "https://example.com/acme/terms", > "website": "https://www.example.com/", > "caa-identities": ["example.com"], > "hash-algorithms": ["SHA-256", "SHA-512"] > }, > > Alternatively, the server's hash algorithms could be included in the > challenges, like this: > { > "type": "http-01", > "url": "https://example.com/authz/1234/0", > "token": "DGyRejmCefe7v4NfDGDKfA", > "hash-algorithms":["SHA-256", "SHA-512"] > } > > Then, the client indicates the preferred hash algorithm (from the > server's list) in the response: > { > "protected": base64url({ > "alg": "ES256", > "kid": "https://example.com/acme/acct/1", > "nonce": "Q_s3MWoqT05TrdkM2MTDcw", > "url": "https://example.com/acme/authz/asdf/0" > }), > "payload": base64url({ > "type": "http-01", > "keyAuthorization": "IlirfxKKXA...vb29HhjjLPSggwiE", > "hash-algorithm": "SHA-256" > }), > "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" > } > > For compatibility with existing implementations, the default hash > algorithm if none is specified could be SHA-256. > > Sincerely, > > Logan Widick > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
