On Sat, Aug 6, 2016 at 2:16 PM, Jacob Hoffman-Andrews <j...@eff.org> wrote:
> 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. > Actually I thought of another reason, which is more compelling: There's no specified algorithm for comparing JWKs. Do you include, e.g., "kid" or "x5t"? So we would need to specify a comparison algorithm. It seems like the most likely candidate for that would be "compare the fields that go into a thumbprint calculation", in which case it's probably less code to just compute the thumbprint. > 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. > On further thought, I think I would like to propose that we go back to not caring about the nonce. Requiring the nonce to be handled at the ACME layer seems like a huge pain, on the client side especially. Normally, nonces are just a transport-layer concept that the ACME layer doesn't need to know about, so requiring them to be the same would be a layering violation. On the server side, it's not so bad; the transport layer just needs to tell the ACME layer what nonce was used. But on the client side, the ACME layer now needs to both get a nonce from the transport layer and ensure that that nonce is used for the ultimate message. I don't think there are security risks that would arise from this decision. It would mean that the inner JWS could be used on a different key-change transaction, but only by the same new account key holder, for the same old key/account, on the same server. Within that scope, it actually seems like it's more of a feature than a bug -- if the nonces have to be equal, then you need to have a full RTT between the old and new key holders (N->O: nonce, O->N: signed object). That RTT needs to be pretty real-time, because the nonce still needs to be valid. If the inner JWS can be nonce-less (or have an ignored nonce), then the old key holder can just provide the new key holder with a signed object and the old key holder can use it at its leisure. This non-real-time aspect does have some risk. Namely, since the key-change object only identifies the registration by key, and we can now change keys, it could be possible for the new key holder to take over a unexpected account: Initial state: (keyA for acct1) and (keyB for acct2) - keyA signs key-change doc (keyA -> keyC), intending to transfer acct1 - keyB and keyA do (keyB -> keyA) for acct2, so now keyA is bound to acct2 - keyC can now claim acct2 instead of acct1 (If you reverse the order of the keys, you end up with the old key holder being able to give the new key holder an unexpected account.) I think the way to address this is just to have the inner JWS reflect the URL of the account/registration for which the transfer is being done, by adding a parameter alongside "oldKey" and "newKey. Updated the PR to reflect these considerations: https://github.com/ietf-wg-acme/acme/pull/164
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
