Re: [Acme] Proposed ACME Charter Language

[Anders Rundgren <[e-mail]>]

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:[e-mail]] 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/acme
>
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>