Draft: draft-ietf-acme-acme

Commentary: Include " processing " as a possible status for an order ( this was listed elsewhere but not consistent ) . Include a tls - sni-02 challenge in example authz . Clarify that finalizing an authorization involves modifying the expires field , not adding it . Clarify in revocation section the two types of accounts that can request a certificate revocation . Expand examples in challenge section to match format in the rest of the doc , including HTTP headers and  wrapping . Indicate for HTTP , TLS SNI , and DNS , that making multiple requests is not only supported , but RECOMMENDED . Fix a mismatch between " client configurable " in description of registries and " configurable " in the table of things to be registered .
Paragraph (version A):
The status of this order.  Possible values are: "pending",
"valid", and "invalid".
Paragraph (version B):
The status of this order.  Possible values are: "pending",
"processing", "valid", and "invalid".
Paragraph (version A):
The identifier authorization process establishes the authorization of
an account to manage certificates for a given identifier.  This
process must assure the server of two things: First, that the client
controls the private key of the account key pair, and second, that
the client holds the identifier in question.  This process may be
repeated to associate multiple identifiers to a key pair (e.g., to
request certificates with multiple identifiers), or to associate
multiple accounts with an identifier (e.g., to allow multiple
entities to manage certificates).  The server may declare that an
authorization is only valid for a specific order by setting the
"scope" field of the authorization to the URI for that order.
Paragraph (version B):
The identifier authorization process establishes the authorization of
an account to manage certificates for a given identifier.  This
process must assure the server of two things: First, that the client
controls the private key of the account key pair, and second, that
the client controls the identifier in question.  This process may be
repeated to associate multiple identifiers to a key pair (e.g., to
request certificates with multiple identifiers), or to associate
multiple accounts with an identifier (e.g., to allow multiple
entities to manage certificates).  The server may declare that an
authorization is only valid for a specific order by setting the
"scope" field of the authorization to the URI for that order.
Paragraph (version A):
The server is said to "finalize" the authorization when it has
completed one of the validations, by assigning the authorization a
status of "valid" or "invalid", corresponding to whether it considers
the account authorized for the identifier.  If the final state is
"valid", the server MUST add an "expires" field to the authorization.
When finalizing an authorization, the server MAY remove challenges
other than the one that was completed.  The server SHOULD NOT remove
challenges with status "invalid".
Paragraph (version B):
The server is said to "finalize" the authorization when it has
completed one of the validations, by assigning the authorization a
status of "valid" or "invalid", corresponding to whether it considers
the account authorized for the identifier.  If the final state is
"valid", then the server MUST include an "expires" field.  When
finalizing an authorization, the server MAY remove challenges other
than the one that was completed, and may modify the "expires" field.
The server SHOULD NOT remove challenges with status "invalid".
Paragraph (version A):
the public key in the certificate.
Paragraph (version A):
an account key that is authorized to act for all of the
identifier(s) in the certificate.
Paragraph (version B):
the account that issued the certificate.
Paragraph (version B):
an account that holds authorizations for all of the identifiers in
the certificate.
Paragraph (version B):
The server SHOULD also consider a revocation request valid if it is
signed with the private key corresponding to the public key in the
certificate.
Paragraph (version A):
Different challenges allow the server to obtain proof of different
aspects of control over an identifier.  In some challenges, like HTTP
and TLS SNI, the client directly proves its ability to do certain
things related to the identifier.  The choice of which challenges to
offer to a client under which circumstances is a matter of server
policy.
Paragraph (version B):
Different challenges allow the server to obtain proof of different
aspects of control over an identifier.  In some challenges, like
HTTP, TLS SNI, and DNS, the client directly proves its ability to do
certain things related to the identifier.  The choice of which
challenges to offer to a client under which circumstances is a matter
of server policy.
Paragraph (version A):
It is RECOMMENDED that the ACME server validation TLS connections
from multiple vantage points to reduce the risk of DNS hijacking
attacks.
Paragraph (version B):
It is RECOMMENDED that the server open multiple TLS connections from
various network perspectives, in order to make MitM attacks harder.
Paragraph (version B):
It is RECOMMENDED that the server perform multiple DNS queries from
various network perspectives, in order to make MitM attacks harder.
Paragraph (version A):
On receiving a response, the server MUST verify that the value of the
"type" field is as required.  Otherwise, the steps the server takes
to validate identifier possession are determined by the server's
local policy.
Paragraph (version B):
On receiving a response, the server MUST verify that the value of the
"type" field is "oob-01".  Otherwise, the steps the server takes to
validate identifier possession are determined by the server's local
policy.
Paragraph (version A):
This registry lists field names that are defined for use in ACME
account objects.  Fields marked as "client configurable" may be
included in a new-account request.
Paragraph (version B):
This registry lists field names that are defined for use in ACME
account objects.  Fields marked as "configurable" may be included in
a new-account request.
Paragraph (version A):
This registry lists field names that are defined for use in ACME
order objects.  Fields marked as "client configurable" may be
included in a new-order request.
Paragraph (version B):
This registry lists field names that are defined for use in ACME
order objects.  Fields marked as "configurable" may be included in a
new-order request.