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

[Benjamin Kaduk <[e-mail]>]

On Thu, Oct 03, 2019 at 12:59:47PM +0000, Thomas Fossati wrote:
> 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.)

So, it turns out that I was confused on this (probably a remnant of my
confusion on the related issues during the processing of RFC 8555) --
https://tools.ietf.org/html/rfc8555#section-9.7.2 is clear that the
"configurable" column refers only to "included in a newOrder request".  The
usage here is not in the newOrder request, and thus is not inherently
problematic, if my (new) understanding is correct.  But hopefully we can
get some more input, e.g., from people who better remember the discussions
around the time of draft-ietf-acme-acme's processing.

-Ben

> > 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.