Draft: draft-ietf-acme-acme

Commentary: Several places talked about account key pairs as being the primary notion of an account , while the account is now primary and has a public key associated with it . Updated to clarify that . Clarified that the account request can contain more than just contact information . Fixed the order of operations in protocol summary to reflect new - order flow .
Paragraph (version A):
ACME allows a client to request certificate management actions using
a set of JSON messages carried over HTTPS.  In some ways, ACME
functions much like a traditional CA, in which a user creates an
account, adds identifiers to that account (proving control of the
domains), and requests certificate issuance for those domains while
logged in to the account.
Paragraph (version A):
In ACME, the account is represented by an account key pair.  The "add
a domain" function is accomplished by authorizing the key pair for a
given domain.  Certificate issuance and revocation are authorized by
a signature with the key pair.
Paragraph (version A):
The first phase of ACME is for the client to register with the ACME
server.  The client generates an asymmetric key pair and associates
this key pair with a set of contact information by signing the
contact information.  The server acknowledges the registration by
replying with a account object echoing the client's input.
Paragraph (version B):
ACME allows a client to request certificate management actions using
a set of JSON messages carried over HTTPS.  In many ways, ACME
functions much like a traditional CA, in which a user creates an
account, requests a certificate, and proves control of the domains in
that certificate in order for the CA to sign the requested
certificate.
Paragraph (version B):
The first phase of ACME is for the client to request an account with
the ACME server.  The client generates an asymmetric key pair and
requests a new account, optionally providing contact information,
agreeing to terms of service, and/or associating the account with an
existing account in another system.  The creation request is signed
with the generated private key to prove that the client controls it.
Paragraph (version A):
To revoke a certificate, the client simply sends a revocation request
indicating the certificate to be revoked, signed with an authorized
key pair.  The server indicates whether the request has succeeded.
Paragraph (version A):
All ACME requests with a non-empty body MUST encapsulate the body in
a JWS object, signed using the account key pair.  The server MUST
verify the JWS before processing the request.  (For readability,
however, the examples below omit this encapsulation.)  Encapsulating
request bodies in JWS provides a simple authentication of requests by
way of key continuity.
Paragraph (version B):
All ACME requests with a non-empty body MUST encapsulate their
payload in a JWS object, signed (in most cases) using the account's
private key.  The server MUST verify the JWS before processing the
request.  Encapsulating request bodies in JWS provides a simple
authentication of requests.
Paragraph (version A):
Note that authentication via signed POST implies that GET requests
are not authenticated.  Servers MUST NOT respond to GET requests for
resources that might be considered sensitive.
Paragraph (version B):
Note that authentication via signed JWS request bodies implies that
GET requests are not authenticated.  Servers MUST NOT respond to GET
requests for resources that might be considered sensitive.