Subject: [Acme] Proposed ACME Charter Language

From: Russ Housley <[email-masked]>
Date: Mon, 20 Apr 2015 11:23:42 -0400

At the end of the ACME BoF, it was suggested that the next step was charter language.  I took a stab at some to get the discussion going.

I did not consider milestones yet.  I think it is easier to get consensus on the charter text and then discuss milestones.

Please review and comment.

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 ACME WG will not duplicate work from previous IETF
certificate management efforts.  If it is necessary to develop a
replacement for previous effort, the ACME WG will document the aspects
of that work that prevent it from being used for the envisioned
automated tasks.

The starting point for ACME WG discussions shall be draft-barnes-acme.

[0] https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Apr 2015 16:43:39 +0100

Hi Russ,

This bit puzzles me a lot, other bits puzzle me a little:-)

On 20/04/15 16:23, Russ Housley wrote:
> certificate management efforts. 

If accepted, that would seem to me to nullify the entire
effort. Can you explain why I'm reading it wrong?

ACME absolutely will duplicate work from previous IETF
certificate management efforts that have failed to get
traction over the last decade and a half. That is entirely
fine IMO and needs no explicit justification whatsoever
since we have 15 years of crystal clear non-use, outside
of niche environments. (It is true that what is now
considered a niche was not so considered back then.)

In fact I believe anyone who claims such duplication is a
problem should be the one to provide evidence for that by
documenting exactly why and at what scale.

It is just not credible for us to pretend that CMC, CMP,
or EST are widely used for certificate management on the
public Internet. If I'm wrong there I would really love
to see the evidence but absent such, duplicating bits of
functionality present in current RFCs that are not at all
widely used is what is needed for this effort and needs
to be encouraged.

I think we really ought bottom out on this aspect before
chartering - it'd be dumb of us to charter an ACME WG that
has to fight all the CRMF battles over again, or the ASN.1
vs. whatever issues. So I hope lots of voices chime in
and say what they think.

S.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 20 Apr 2015 15:49:10 +0000

> I think we really ought bottom out on this aspect before chartering - it'd be
> dumb of us to charter an ACME WG that has to fight all the CRMF battles over
> again, or the ASN.1 vs. whatever issues. So I hope lots of voices chime in and
> say what they think.

My employer gets thousands of certs from several commercial CA's.  Each one is a separate integration effort and none of them seem to look like any of the previous IETF RFC's.  The one exception is they all want a cert request, which of course predates the RFC's as it's PKCS.

---

From: Russ Housley <[email-masked]>
Date: Mon, 20 Apr 2015 11:57:17 -0400

Stephen:

I did not see the ACME effort as trying to throw everything out.  Rather, throw out the parts that have been an impediment to the kind of automation proposed by ACME, but document the shortcoming.

Russ

On Apr 20, 2015, at 11:43 AM, Stephen Farrell wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Apr 2015 17:05:56 +0100

On 20/04/15 16:57, Russ Housley wrote:
> Stephen:
> 
> I did not see the ACME effort as trying to throw everything out.

If it is not used, then I don't think we're throwing it out:-)

> Rather, throw out the parts that have been an impediment to the kind
> of automation proposed by ACME, but document the shortcoming.

Sorry, I'm still not getting it. I don't see any need for ACME
to document why CMP etc failed or what was wrong with CMP that
may have caused it to fail. And the same for CMC etc. BTW by
"fail" here I mean: not used by the major deployed PKIs on the
public Internet.

I also see no need at all to even try to re-use ASN.1 PDU
structures that are defined in CRMF etc.

I do think that ACME ought learn from the past of course, and
am confident that there will be enough participants involved
who have that history for that to not be problematic.

But I do not think ACME ought be required to re-use any ASN.1
PDU definitions from any previous RFCs on this topic.

Do we agree or disagree on that last? (I'm trying to get to
quite specific meanings for "duplicate.")

Cheers,
S.

>> If accepted, that would seem to me to nullify the entire effort.
>> Can you explain why I'm reading it wrong?
>> 
>> ACME absolutely will duplicate work from previous IETF certificate
>> management efforts that have failed to get traction over the last
>> decade and a half. That is entirely fine IMO and needs no explicit
>> justification whatsoever since we have 15 years of crystal clear
>> non-use, outside of niche environments. (It is true that what is
>> now considered a niche was not so considered back then.)
>> 
>> In fact I believe anyone who claims such duplication is a problem
>> should be the one to provide evidence for that by documenting
>> exactly why and at what scale.
>> 
>> It is just not credible for us to pretend that CMC, CMP, or EST are
>> widely used for certificate management on the public Internet. If
>> I'm wrong there I would really love to see the evidence but absent
>> such, duplicating bits of functionality present in current RFCs
>> that are not at all widely used is what is needed for this effort
>> and needs to be encouraged.
>> 
>> I think we really ought bottom out on this aspect before chartering
>> - it'd be dumb of us to charter an ACME WG that has to fight all
>> the CRMF battles over again, or the ASN.1 vs. whatever issues. So I
>> hope lots of voices chime in and say what they think.
>> 
>> S.
>> 
>> _______________________________________________ Acme mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/acme
> 
> 
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 20 Apr 2015 12:11:25 -0400

Stephen:

If that paragraph were removed, would you be happier with the charter?  If so, consider it gone.  I'm willing to assume that an attempt to replace things that people are using will meet with vigorous discussion.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Apr 2015 17:34:05 +0100

Hi Russ,

On 20/04/15 17:11, Russ Housley wrote:
> Stephen:
> 
> If that paragraph were removed, would you be happier with the
> charter?  If so, consider it gone.  

I would be happier yes. But I think we're better off having the
discussion now, before chartering, since otherwise we may end up
re-doing it a number of times.

If that discussion ends up with rough consensus for a "don't
duplicate" position then text such as you propose would be correct.
If that discussion ends up with rough consensus on a "duplicate
away, earlier efforts failed" position then it'd probably be a
good idea to say so in the charter text. (So, your bit of puzzling
text is very useful in the end - it may force us to get this out
of the way early.)

> I'm willing to assume that an
> attempt to replace things that people are using will meet with
> vigorous discussion.

Right. People are using CMC, but not afaik when dealing with any
public CAs for getting certificates for public Internet services.
I think CMP has some similar but much smaller set of real uses. (*)
And I'm not sure if EST has gotten traction. SCEP has uses but
that's another kettle of cans of worms and fish;-)

I think it would be better to have the vigorous discussion about
CMC vs.ACME-JSON-etc (if that's the one we need to have) before
we form the WG. But is that in fact the meat of your concern here?
If so, then I assume you'd be arguing for use of CMC/CRMF PDUs
in ACME messages. If not, I'm not back to being puzzled. Can you
clarify?

Cheers,
S.

(*) Last I checked, there still were a set of real users of CMP that
meant it would be wrong to declare it HISTORIC. If that's changed
since, it might be a fine thing to do though, and I'm happy to help
there, so if anyone has info please let us know, though that'd be
better done via mail on the pkix list (and then saag) and not here.

>>> Rather, throw out the parts that have been an impediment to the
>>> kind of automation proposed by ACME, but document the
>>> shortcoming.
>> 
>> Sorry, I'm still not getting it. I don't see any need for ACME to
>> document why CMP etc failed or what was wrong with CMP that may
>> have caused it to fail. And the same for CMC etc. BTW by "fail"
>> here I mean: not used by the major deployed PKIs on the public
>> Internet.
>> 
>> I do think that ACME ought learn from the past of course, and am
>> confident that there will be enough participants involved who have
>> that history for that to not be problematic.
>> 
>> But I do not think ACME ought be required to re-use any ASN.1 PDU
>> definitions from any previous RFCs on this topic.
>> 
>> Do we agree or disagree on that last? (I'm trying to get to quite
>> specific meanings for "duplicate.")
>> 
>> Cheers, S.
>> 
>> 
>> 
>>> 
>>> Russ
>>> 
>>>> certificate management efforts that have failed to get traction
>>>> over the last decade and a half. That is entirely fine IMO and
>>>> needs no explicit justification whatsoever since we have 15
>>>> years of crystal clear non-use, outside of niche environments.
>>>> (It is true that what is now considered a niche was not so
>>>> considered back then.)
>>>> 
>>>> It is just not credible for us to pretend that CMC, CMP, or EST
>>>> are widely used for certificate management on the public
>>>> Internet. If I'm wrong there I would really love to see the
>>>> evidence but absent such, duplicating bits of functionality
>>>> present in current RFCs that are not at all widely used is what
>>>> is needed for this effort and needs to be encouraged.
>>>> 
>>>> chartering - it'd be dumb of us to charter an ACME WG that has
>>>> to fight all the CRMF battles over again, or the ASN.1 vs.
>>>> whatever issues. So I hope lots of voices chime in and say what
>>>> they think.
>>>> 
>>>> S.
>>>> 
>>>> _______________________________________________ Acme mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/acme
>>> 
>>> 
>>> 
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 20 Apr 2015 12:40:55 -0400

> in ACME messages. If not, I'm not back to being puzzled. Can you

I was not concerned about CMC, CMP, or SCEP.  My concern is around EST.  The Hotspot spec points to it, and we should see if others are using it.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Apr 2015 20:04:07 +0100

Hiya,

On 20/04/15 17:40, Russ Housley wrote:
> Stephen:
> 
>>> I'm willing to assume that an attempt to replace things that
>>> people are using will meet with vigorous discussion.
>> 
>> public CAs for getting certificates for public Internet services. I
>> think CMP has some similar but much smaller set of real uses. (*) 
>> CMC vs.ACME-JSON-etc (if that's the one we need to have) before we
>> form the WG. But is that in fact the meat of your concern here? If
>> so, then I assume you'd be arguing for use of CMC/CRMF PDUs in ACME
>> messages. If not, I'm not back to being puzzled. Can you clarify?
> 
> I was not concerned about CMC, CMP, or SCEP.  My concern is around
> EST.  The Hotspot spec points to it, and we should see if others are
> using it.

(Do you have a ref for the hotspot spec? I don't know that one.)

Anyway EST carries (a profile of) CMC messages [1] doesn't it? So
aren't we really asking about use of CMC-defined, ASN.1 encoded
payloads here after all?

In case it helps, I think (open to correction of course) that everyone
would be fine with re-using and not duplicating PKCS#10, at least for
RSA, since that is what is well supported by well deployed code. And
that seems to be in the current ACME draft. [2] So I think we're mostly
talking about the bits and pieces of CMC/CRMF that go beyond PKCS#10 -
and it's those that are afaik unused and where we oughtn't be fussed
about duplicating (should that be what the WG wants).

I do agree that we might want to think some more if there's significant
deployment of EST somewhere relevant, or if a good argument that that's
highly likely can be made.

I also agree that asking the question "why isn't EST good enough" is
totally valid, and that it'd be great if someone would summarise the
earlier thread on that. [3]

Cheers,
S.

[1] https://tools.ietf.org/html/rfc7030#section-3
[2] https://tools.ietf.org/html/draft-barnes-acme-01#section-4
[3] https://www.ietf.org/mail-archive/web/acme/current/msg00003.html

---

From: Russ Housley <[email-masked]>
Date: Tue, 21 Apr 2015 06:53:23 -0400

Hotspot 2.0 is behind a paywall: https://www.wi-fi.org/hotspot-20-release-2-technical-specification-package-v110

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Apr 2015 12:00:05 +0100

On 21/04/15 11:53, Russ Housley wrote:
> Hotspot 2.0 is behind a paywall:
> https://www.wi-fi.org/hotspot-20-release-2-technical-specification-package-v110

Bummer;-( Not sure if someone can summarise what EST is being used
for there. Could be that it overlaps more with homenet/anima than
with acme for example, not sure.

I also asked a question below though and am interested in your take

Cheers,
S.

>>>> Right. People are using CMC, but not afaik when dealing with
>>>> any public CAs for getting certificates for public Internet
>>>> services. I think CMP has some similar but much smaller set of
>>>> real uses. (*) And I'm not sure if EST has gotten traction.
>>>> SCEP has uses but that's another kettle of cans of worms and
>>>> fish;-)
>>>> 
>>>> I think it would be better to have the vigorous discussion
>>>> about CMC vs.ACME-JSON-etc (if that's the one we need to have)
>>>> before we form the WG. But is that in fact the meat of your
>>>> concern here? If so, then I assume you'd be arguing for use of
>>>> CMC/CRMF PDUs in ACME messages. If not, I'm not back to being
>>>> puzzled. Can you clarify?
>>> 
>>> I was not concerned about CMC, CMP, or SCEP.  My concern is
>>> around EST.  The Hotspot spec points to it, and we should see if
>>> others are using it.
>> 
>> In case it helps, I think (open to correction of course) that
>> everyone would be fine with re-using and not duplicating PKCS#10,
>> at least for RSA, since that is what is well supported by well
>> deployed code. And that seems to be in the current ACME draft. [2]
>> So I think we're mostly talking about the bits and pieces of
>> CMC/CRMF that go beyond PKCS#10 - and it's those that are afaik
>> unused and where we oughtn't be fussed about duplicating (should
>> that be what the WG wants).
>> 
>> I do agree that we might want to think some more if there's
>> significant deployment of EST somewhere relevant, or if a good
>> argument that that's highly likely can be made.
>> 
>> I also agree that asking the question "why isn't EST good enough"
>> is totally valid, and that it'd be great if someone would summarise
>> the earlier thread on that. [3]
>> 
>> Cheers, S.
>> 
>> [1] https://tools.ietf.org/html/rfc7030#section-3 [2]
>> https://tools.ietf.org/html/draft-barnes-acme-01#section-4 [3]
>> https://www.ietf.org/mail-archive/web/acme/current/msg00003.html
>> 
>> 
>> 
>>> 
>>> Russ
>>>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 25 Apr 2015 13:05:37 -0700

On Mon, Apr 20, 2015 at 9:11 AM, Russ Housley <[email-masked]> wrote:

> Stephen:
>
> If that paragraph were removed, would you be happier with the charter?  If
> so, consider it gone.  I'm willing to assume that an attempt to replace
> things that people are using will meet with vigorous discussion.

I would suggest we do as you propose and remove this text. I think there
will
be plenty of occasion for people in the WG to argue about using existing
stuff
versus building anew.

-Ekr

---

From: [email-masked]
Date: Sat, 25 Apr 2015 16:20:16 -0400

+1

Arguments as to whether something is new get tedious. 

Sent from my iPhone

> On Apr 25, 2015, at 4:05 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> I would suggest we do as you propose and remove this text. I think there will
> be plenty of occasion for people in the WG to argue about using existing stuff
> versus building anew.
> 
> -Ekr
>  
>> 
>> Russ
>> 
>>

---

From: Russ Housley <[email-masked]>
Date: Sat, 25 Apr 2015 17:46:08 -0400

Here is the currrent language ...

Russ

= = = = = = = = = =

---

From: "Songhaibin (A)" <[email-masked]>
Date: Wed, 29 Apr 2015 09:00:43 +0000

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:[email-masked]] On Behalf Of Russ Housley
> Sent: Sunday, April 26, 2015 5:46 AM
> To: IETF ACME
> Subject: Re: [Acme] Proposed ACME Charter Language
> 
> 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.
> 
> compatible with common industry standards for the operation of a CA, for
> example the CA/Browser Forum Baseline Requirements [0].
>

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 29 Apr 2015 14:11:02 +0200

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