Re: [Acme] Proposed ACME Charter Language

Haibin:

There was some language about  documenting the aspects of previous work that prevented it from being used.  After discussion, that was removed.  You seem to be asking for documentation in a different direction, going beyond subject and subject alternative names that are tied to domain names.  The mechanisms are quite different, and I'm not sure that we want to put them all in one working group.  If we discover otherwise, we can always recharter to expand the scope.

Russ

On Apr 29, 2015, at 5:00 AM, 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.
> 
> Best Regards!
> -Haibin
> 
> 
>> -----Original Message-----
>> From: Acme [mailto:acme-bounces@ietf.org] 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
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme