On Wed, Oct 10, 2018 at 6:47 PM Benjamin Kaduk <[email protected]> wrote:
> On Wed, Oct 10, 2018 at 06:42:33PM -0400, Richard Barnes wrote: > > On Wed, Oct 3, 2018 at 11:54 AM Benjamin Kaduk <[email protected]> wrote: > > > > > On Sat, Sep 15, 2018 at 08:51:55PM -0500, Benjamin Kaduk wrote: > > > > On Fri, Sep 14, 2018 at 03:59:07PM -0400, Daniel McCarney wrote: > > > > > > My co-author Daniel McCarney is working on the COMMENT comments. > > > > > > > > > > > IMPORTANT: I don't think I understand why "nonce" MUST NOT be > > > present in > > > > > > the external-binding JWS object, though I think I understand why > one > > > is > > > > > not > > > > > > needed in order to bind the MAC to the current transaction. > (That > > > is, > > > > > this > > > > > > is in effect a "triply nested" construct, where a standalone MAC > that > > > > > > certifies an ACME account (public) key as being authorized by the > > > > > > external-account holder to act on behal of that external account. > > > But > > > > > this > > > > > > standalone MAC will only be accepted by the ACME server in the > > > context of > > > > > > the outer JWS POST, that must be signed by the ACME account key, > > > which is > > > > > > assumed to be kept secure by the ACME client, ensuring that both > > > > > > key-holding entities agree to the account linkage.) Proof of > > > freshness of > > > > > > the commitment from the external account holder to authorize the > ACME > > > > > > account key would only be needed if there was a scenario where > the > > > > > external > > > > > > account holder would revoke that association, which does not > seem to > > > be a > > > > > > workflow supported by this document. Any need to effectuate > such a > > > > > > revocation seems like it would involve issuing a new MAC key for > the > > > > > > external account (and invalidating the old one), and > > > revoking/deactivating > > > > > > the ACME account, which is a somewhat heavy hammer but perhaps > > > reasonable > > > > > > for such a scenario. > > > > > > Account key rollover just says that the nonce is NOT REQUIRED, > and > > > also > > > > > > uses some nicer (to me) language about "outer JWS" and "inner > JWS". > > > It > > > > > > might be nice to synchronize these two sections. > > > > > > > > > > I defer on this to the other authors/people that want > > > > > externalAccountBinding to > > > > > be a thing. > > > > > > > > Okay. I would like to avoid having needless normative requirements > if > > > > there is in fact no reason for this requirement. > > > > > > My apologies if I missed it when it went by, but did we ever hear more > > > about this requirement from the proponents of externalAccountBinding? > > > > > > > Picking this up... > > > > I actually have the opposite inclination to you here -- if a field is not > > used by the protocol, then it should be forbidden, in the spirit of [1]. > > By that logic, we should also forbid the use of the "nonce" field in > > roll-over. I think it was just an oversight that we didn't. The > security > > analysis that Bhargavan et al. did long ago did not presume any use of > > it. I've made a PR making it a MUST NOT: > > > > https://github.com/ietf-wg-acme/acme/pull/464 > > > > [1] https://tools.ietf.org/html/draft-iab-protocol-maintenance-00 > > Okay, a "MUST NOT" because anything not needed should be forbidden is a > fine reason to me; thanks for putting together the PR to bring the two > cases into consistency. > Thanks for the review!
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
