Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-star-09: (with DISCUSS and COMMENT)

[Thomas Fossati <[e-mail]>]

Hi Ben,

First of all thank you very much for this excellent review.

On your DISCUSS points:

On 02/10/2019, 19:06, "Benjamin Kaduk via Datatracker" <[e-mail]> wrote:
> RFC 8555 (and the IANA registry) list the 'status' field of the order
> object as not configurable, yet we propose to configure it (in
> Sections 3.1.1 and 3.1.2).  It would perhaps be possible to make this
> work procedurally, by updating the registry entry and maybe an
> Updates: header, but it may be worth a broader rethink.  Specifically,
> if we add a new field to the order instead, for the cancellation URL,
> then we do not modify the order directly (but instead request the
> server to take an action that does so as a side effect), and we also
> can avoid state-machine concerns about attempting to enter "canceled"
> state from a state other than "valid" by simply not making the
> cancellation URL visible until the order is "valid".

This is a great catch -- I wonder how we failed to notice it.  I don't
think tweaking the registry would be a good way to tackle this and I
agree with your proposal to remove the canceled state and add a
cancellation URL instead.  I am going to work on an update and have it
ready ASAP (though I'm on leave starting tomorrow, so it might take a
bit more than just a couple of days.)

> A more minor concern, but when we consider the examples in this
> document in conjunction with the examples in RFC 8555 itself, we find
> several protocol invariants violated: we reuse a nonce for different
> requests, but nonces are single-use; we use the same Order URL for two
> different order contents, the same certificate URL for two different
> (star-)certificates, and (not quite a protocol invariant, but "with
> very high probability" so) the signature on a request is duplicated.
> I also note that we reuse an account URL from RFC 8555, which is not
> inherently problematic, but my suggestion would be to generate a new
> one to make a clean break.

OK, no problems.

Cheers!


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.