[Acme] draft-ietf-acme-acme-02 review, a few more nits

[Ron <[e-mail]>]

Hi,

So folding in all the changes that landed for the -02 draft yesterday
to my code was fairly painless, though there's a few things I still
can't actually test until there's a server which supports them.

I have a few more nits from going through the changes more carefully
though, easy ones first this time (:


 - More typos.

 "using JWS to provide som additional security properties"

 "which protects against an intermediary changing the request URI
 to anothe ACME URI"


In "Deleting an authorization" it says:

 "If the server deletes the account then it MUST send a response with a
 200 (OK) status code and an empty body"
 
Which should probably be s/account/authorization/ (it's otherwise the
same text copied from the Deleting an account section).



 - tls-sni-02

Says: "Open a TLS connection to the domain name being validated on the
       requested port"

Which is unchanged from tls-sni-01 - but we don't actually specify a
way to request a non-default port anywhere.

Unless someone has a good argument for why we should support that, we
should probably just fix the text to not say that.



 - 6.3 Registration

There's no explicit description of what the server is expected to return
if registration is updated or queried, aside from that it MUST contain
the link headers as per new registration.

That should probably be fleshed out a little more.



 - 6.1.1 Registration Objects

This ...  probably needs to be restructured somewhat for clarity.

In the changes for -02, authorizations and certificates were marked as
being 'required' now.  And I think I understand what is intended there,
that a server should be required to always include them ...

But:

 a) I'm not sure why that should be a hard requirement.
    What should those URIs return/do if there are not yet any
    authorizations or certificates for a registration?

    It did make sense to me to not include them in that case.

 b) This is now somewhat confusing and misleading with all the other
    uses of 'registration objects' documented later in the text, where
    when a client sends one as a request it shouldn't include those
    "required" fields and a server MUST ignore them if it does.

    We also add yet another field, 'delete' in 6.3.2, which isn't
    documented in that set in the initial description.


I'd like to see all of the possible fields, including 'delete'
documented in the introduction to the Registration Object, and we
probably need something a bit more nuanced than "required", when
what is really meant there is "required (except when it's not)".

Maybe the right answer to that is the request objects need some
different name than "stub Registration Object" to distinguish
them - or maybe it's enough to just document a bit more thoroughly
when each field is used/required/must not be included in the
introduction text.

I don't have a particularly strong preference for either of those
options, I'd just like the definitions of those fields to not be
contradicted by later text in the document, with no cross references
between the separate sections that must all be read together to
put together the complete picture of what is a valid Registration
Object in any given context.


  Cheers,
  Ron