Richard Barnes <rlb@xxxxxx> 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
