On 2015-04-29 11:00, Songhaibin (A) wrote:
And I think at the initial stage, the WG must consider the future
> extensibility to accommodate other types of certificates (beyond
> domain name certificates used by web servers). So discussion or
> documentation about other use cases are also helpful at the initial stage.
I think that the difference between the web-server use-case and for example
networked devices (M2M)
is that the latter probably will equipped with a built-in Attestation Key +
Device Certificate
which affects both the format and process of requests. But in this case we are
probably rather
talking about client certificates.
Then you have client certificates for end-users with mobile computing devices.
That's my line of work and my scheme (FWIW) has few (if any) similarities with
ACME.
So it would indeed be a very good idea listing use-cases that are in scope!
That was BTW the problem with PKIX' EST; it was never clear what it was
intended for.
Anders
Best Regards!
-Haibin
-----Original Message-----
From: Acme [mailto:[email protected]] On Behalf Of Russ Housley
Sent: Sunday, April 26, 2015 5:46 AM
To: IETF ACME
Subject: Re: [Acme] Proposed ACME Charter Language
Here is the currrent language ...
Russ
= = = = = = = = = =
Automated Certificate Management Environment (ACME)
Historically, issuance of certificates for Internet applications (e.g., web
servers)
has involved many manual identity validation steps by the certification
authority (CA). The ACME WG will specify conventions for automated X.509
certificate management, including validation of control over an identifier,
certificate issuance, certificate renewal, and certificate revocation. The
initial
focus of the ACME WG will be on domain name certificates (as used by web
servers), but other uses of certificates can be considered as work progresses.
ACME certificate management must allow the CA to verify, in an automated
manner, that the party requesting a certificate has authority over the
requested identifiers, including the subject and subject alternative names.
The processing must also confirm that the requesting party has access to the
private key that corresponds to the public key that will appear in the
certificate.
All of the processing must be done in a manner that is compatible with common
service deployment environments, such as hosting environments.
ACME certificate management must, in an automated manner, allow a party
that has previously requested a certificate to subsequently request revocation
of that certificate.
In order to facilitate deployment by CAs, the ACME protocol must be
compatible with common industry standards for the operation of a CA, for
example the CA/Browser Forum Baseline Requirements [0].
The starting point for ACME WG discussions shall be draft-barnes-acme.
[0] https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
