On 08/06/2016 11:03 AM, Richard Barnes wrote: > - Less bloat I think that's not a concern for this rarely used endpoint. > - Implementations are already going to need to have a thumbprint > implementation around for the challenges.
> - Not worried about pinning a hash function because we (1) seems > unlikely we'll need to change soon and (2) we can define a new > rollover endpoint if we need to change These two aren't reasons why it's good to do a thumbprint, they're reasons why it might not be bad. If the only reason it's good is less bloat, I'm in favor of less manipulation, fewer steps, and less hardcoding of crypto primitives. > Also, why require a distinct nonce on the inner and outer JWS? I would > rather require that the nonce and URL parameters must match > between the > inner and outer JWS. > > > - Never re-use nonces The nonce is a property of the request, not the signature. These aren't like ECDSA nonces where reuse is fatal. > - ... for example, because that would require special handling in your > JWS verification method This is already going to require a separate JWS verification method, because the key to be validated is not currently associated with any account.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
