Re: [Gen-art] Genart last call review of draft-ietf-acme-acme-11

[[e-mail] (Dale R. Worley)]

Richard Barnes <[e-mail]> writes:
> [...]
> In other words, there's no need for version negotiation in-band to the
> protocol.

Yeah, that makes sense.

>> The handling of "terms of service agreement" seems to be insufficient,
>> [...]
>
> This mechanism has been reviewed by multiple CAs and found to be sufficient
> for their needs.  A prior version had an explicit URL, and it was found to
> cause interop problems.

I'll take their word for it.  Personally, I wouldn't consider it
particularly sufficient for *my* needs to have an alleged assent to
terms of service without any clear record of what I'm assenting *to*.
OTOH, given that there's no such record, it'd be difficult for a CA to
refute my claim of what the agreement was...

>> 6.6.1.  Subproblems
>>
>> What error type should be used in a problem document when there are
>> subproblem documents?  It seems that in this situation, the intention
>> is that the top-level problem document is not intended to carry error
>> information itself, so you want to define a "subproblems" error type,
>> to use when there is no natural overall error type.

Any comments here?

> I don't think it's all that useful to parse close semantics into this
> diagram.  "newNonce" is different, in that it serves an underlying
> transport purpose, rather than a certificate management purpose.

I'd say that if two things are shown differently in a diagram, then they
ought to *be* different, and if they're the same, they should be shown
the same way.  Certainly, when I looks at a diagram and one thing is not
shown the same way as the others, I want to know what the semantics of
that is.

>> 7.3.5.  External Account Binding
>> [...]
> You seem to be envisioning a scenario where a CA relies on accounts
> established with some third party service, which AFAIK no CA actually does.

The title of the section is "External Account Binding", and I
reflexively take "external" to mean "external to the relationship
between the CA and the client".  I think what you want to do is revise
the first paragraph

   The server MAY require a value for the "externalAccountBinding" field
   to be present in "newAccount" requests.  This can be used to
   associate an ACME account with an existing account >>that the user has
   with the CA<< in a non-ACME system, such as a CA customer database.

And perhaps change the section title to "Binding to a non-ACME Account".

Dale