Subject: Re: [Acme] Proposed ACME Charter Language

From: "Dr. Pala" <[email-masked]>
Date: Sat, 2 May 2015 12:53:00 -0400

Hi ACME,

I just want to point out that it might be the case that the people who are supposed to "argue" about this might not even be aware of the work done in this WG. After reading the charter, it seems to me that the work should have been taken to the PKIX WG.

I also think it would be a good idea to define where and why existing protocols do not work - this is usually a good practice that allow people on focusing on what is the real and documented need and avoid throwing out the baby together with the bathwater. This also goes into the direction of better understanding what part of the work will overlap with existing documents.

On this note, it is still not clear to me is if it is the intention of ACME to deprecate the PKIX work, RFCs, and data formats today in use for certificate management ? Since the charter scope is left pretty much undefined on what will be covered, I think this is a legitimate concern/question...

Cheers,
Max

> On Apr 25, 2015, at 4:05 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
>> 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
>  
>> 
>> Russ
>> 
>> 
>> On Apr 20, 2015, at 12:05 PM, Stephen Farrell wrote:
>> 
>> >
>> >
>> > 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.
>> >
>> >
>> >
>> >>
>> >> Russ
>> >>
>> >> On Apr 20, 2015, at 11:43 AM, Stephen Farrell wrote:
>> >>
>> >>>
>> >>> Hi Russ,
>> >>>
>> >>> This bit puzzles me a lot, other bits puzzle me a little:-)
>> >>>
>> >>> On 20/04/15 16:23, Russ Housley wrote:
>> >>>> The ACME WG will not duplicate work from previous IETF
>> >>>> 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.
>> >>>
>> >>> _______________________________________________ Acme mailing list
>> >>> [email-masked] https://www.ietf.org/mailman/listinfo/acme
>> >>
>> >>
>> >>
>> 
>> _______________________________________________
>> Acme mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/acme
> 
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Ben Laurie <[email-masked]>
Date: Sat, 2 May 2015 18:24:50 +0100

On 2 May 2015 at 17:53, Dr. Pala <[email-masked]> wrote:

> Hi ACME,
>
> I just want to point out that it might be the case that the people who are
> supposed to "argue" about this might not even be aware of the work done in
> this WG. After reading the charter, it seems to me that the work should
> have been taken to the PKIX WG.
>

There is no PKIX WG.

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 2 May 2015 22:20:45 +0000

Max,

The PKIX WG is dead.

We seem to have a lot of enthusiasm, and probably a good consensus, for defining a new protocol. The target is online enrollment for servers, initially Web Servers although others can be supported.  The standard cert-request/cert data structures (i.e., PKCS 10 and 7) will be supported. 

As for defining where and why existing protocols do not work, we are taking it as an axiom that since none of gotten widespread internet deployment, they've failed.  Can anyone argue otherwise?  Sure, there are protocols and implementations and use, but they seem to be only particular products.

Am I wrong?  Is there an on-line certificate enrollment protocol that, say, multiple CA's support?

	/r$

---

From: Bernd Eckenfels <[email-masked]>
Date: Sun, 3 May 2015 02:51:47 +0200

Am Sat, 2 May 2015 22:20:45 +0000
schrieb "Salz, Rich" <[email-masked]>:
> We seem to have a lot of enthusiasm, and probably a good consensus,
> for defining a new protocol. The target is online enrollment for
> servers, initially Web Servers although others can be supported.  The
> standard cert-request/cert data structures (i.e., PKCS 10 and 7) will
> be supported. 

I am quite sure the Charter will be finished once letsencrypt is live :)

> that, say, multiple CA's support?

The question is, will ACME be the one?

But does that really matter? I would be happy with an open standard
only implemented by Lets Encrypt. 

(Yeah I am aware that this might not be the best oppinion on a planned
IETF WG, but the past discussion was not very encouraging.)

Gruss
Bernd

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 11 May 2015 08:32:25 +0200

> On this note, it is still not clear to me is if it is the intention of ACME to deprecate the PKIX work, RFCs, and data formats today in use for certificate management ? Since the charter scope is l…

Isn't SCEP actually the most successful protocol for distributed certification?
But SCEP is not a PKIX protocol.

Another problem is that Android, iOS and Windows have entirely different certificate enrollment support.

That is, apart from PKCS #10, PKIX haven't succeeded creating real standards for certificate enrollment which IMO means that there's nothing to build on except maybe PKCS #10.  I noted this problem more than 10 years ago but there were no interest in fixing it.  Now it is too late.

Anders

>
> Cheers,
> Max
>
>
> On Apr 25, 2015, at 4:05 PM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>
>>
>>
>> On Mon, Apr 20, 2015 at 9:11 AM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Stephen:
>>
>>     >>> [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/acme
>>     >>
>>     >>
>>     >>
>>
>>     [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 12 May 2015 14:34:48 -0700

Stepping back in time to this point in the thread...

On Sat, Apr 25, 2015 at 2:46 PM, Russ Housley <[email-masked]> wrote:

> 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].
>
>
​I don't really like the language "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]." Proving
compatibility with an unbounded set of standards seems likely to
generate a lot of wrangling on what "common industry standards".
Also, the point of the effort, after all, is to be better than *some* of
the current
operations of a CA.

Would the following work?

"The ACME working group is focused on automating certificate issuance,
validation,
revocation and renewal.  Review of other industry practices are not within
scope for this working group."

regards,

Ted

> The starting point for ACME WG discussions shall be draft-barnes-acme.
>
> [0] https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 13 May 2015 15:51:06 -0400

Ted and Simon:

> Ted Hardie <[email-masked]> writes:
> 
> +1
> The reference to CA/B and saying ACME must be compatible with it appear
> restrictive to me.  If we want to improve state-of-the-art, we can't be
> limited by compatibility with the lowest common denominator in the
> industry.

I think the point of this paragraph was to create a protocol that is compatible with existing CA policies and practices.

How about this?

The ACME working group is specifying ways to automate certificate
issuance, validation, revocation and renewal.  The ACME working
group is not reviewing or producing certificate policies or
practices.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 13 May 2015 19:53:16 +0000

> The ACME working group is specifying ways to automate certificate issuance,
> validation, revocation and renewal.  The ACME working group is not
> reviewing or producing certificate policies or practices.

+1  A nice clean statement of what is not in scope.

---

From: Russ Housley <[email-masked]>
Date: Wed, 13 May 2015 15:56:14 -0400

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:[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: Ted Hardie <[email-masked]>
Date: Wed, 13 May 2015 12:59:47 -0700

On Wed, May 13, 2015 at 12:53 PM, Salz, Rich <[email-masked]> wrote:

> issuance,

​I agree; I think this captures it well.

Ted​

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 13 May 2015 16:02:07 -0400

> ​I agree; I think this captures it well.

I prefer the wording of this statement as well.  Thanks.
Kathleen

-- 

Best regards,
Kathleen

---

From: Russ Housley <[email-masked]>
Date: Wed, 13 May 2015 16:25:21 -0400

The current charter language about certificate revocation could be interpreted as raising the bar too high.  I suggest that we can keep it simple.

OLD:

NEW:

ACME certificate management must, in an automated manner, allow an
authorized party to request revocation of a certificate.

Russ

---

From: Randy Bush <[email-masked]>
Date: Wed, 13 May 2015 12:46:52 -1000

> The current charter language about certificate revocation could be
> interpreted as raising the bar too high.  I suggest that we can keep
> it simple.
> 
> OLD:
> 

/me likes simple, and this revision

randy

---

From: Ted Hardie <[email-masked]>
Date: Wed, 13 May 2015 15:59:11 -0700

On Wed, May 13, 2015 at 3:46 PM, Randy Bush <[email-masked]> wrote:

> ​I'm not sure this is actually the same requirement.  The initial aim was
for ACME to provide something like an "apt-get install" level of
simplicity; I read this as something like an "apt-get revoke" equivalent.
I think

"allow an authorized party to request revocation" may be a larger set than
then site admin envisioned in the first--it sort of depends on who the
"authorized party" is.

How about:

"ACME certificate management must provide automated methods for revocation
parallel to those use to request a certificate"?

These all pretty small tweaks, though.

​Ted​

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 May 2015 16:03:04 -0700

> parallel to those use to request a certificate"?

I think that you might find the discussions on revocation on the
(proposed) acme spec enlightening here.  I believe that there are
several ways in which authorization might be determined: if you were
the one to originally request the certificate, if you have the private
key for that certificate, and some other mix of factors whereby those
two parties signal that they have delegated this authority to you.

That's why I favour the more general wording chosen; even if it is
technically different.  It does potentially create a more complex
protocol, but this allows the working group to make that choice,
rather than baking it into the charter.

---

From: Randy Bush <[email-masked]>
Date: Wed, 13 May 2015 13:03:21 -1000

>> /me likes simple, and this revision

confession: it came out of a discussion in which i participated

> How about:
> 
> "ACME certificate management must provide automated methods for
> revocation parallel to those use to request a certificate"?

what the heck does "parallel" mean?  does it include means to revoke a
cert for which i have lost the private key and want to use an entirely
different proof of ownership/control?

ramdu

---

From: Ted Hardie <[email-masked]>
Date: Wed, 13 May 2015 16:16:28 -0700

> different proof of ownership/control?

​To me it means if you prove control of a domain in order to request
a cert by methods 1, 2, or 3, then you can request revocation​ if
you can prove control by the same set of methods.  I do not think
it means that you have to pick the same one from the set, but
it is something for the working group to discuss.

Is there language you like better for that?

Ted

---

From: Randy Bush <[email-masked]>
Date: Wed, 13 May 2015 13:22:12 -1000

> To me it means if you prove control of a domain in order to request a
> cert by methods 1, 2, or 3, then you can request revocation if you can
> prove control by the same set of methods.

and what if i can prove control by method 42?

> I do not think it means that you have to pick the same one from the
> set, but it is something for the working group to discuss.

which is one of the reasons russ's phrasing was so good; it left it for
the wg to discuss and did not overly constrain the space.

> Is there language you like better for that?

yes, russ's

randy, who has had his say

---

From: Ted Hardie <[email-masked]>
Date: Wed, 13 May 2015 16:36:51 -0700

> and what if i can prove control by method 42?

​So, the point I'm getting at is that the system ought to provide
an automated way to request revocation if the requester can meet
the same bar as it would take to request or renew a certificate.  If 42
is one of the ways to meet that bar, well and good.  If 42 is not one
of the ways to meet the original bar, then putting effort to automating
revocation on that basis seems off to me.  I'm not particularly interested
in automating revocation on the basis that someone has a court order,
for example, even if that would be a method to prove you are an authorized
party.  Sure, you can hand the CA a court order, but they should look
at it careful like, not automate the revocation.

> the wg to discuss and did not overly constrain the space.
​I think I want a wee bit more constraining here than you do.

> randy, who has had his say

I'm hardly going to fall on a sword over this, but I wanted to
explain why I see the issue worth discussion now.

Ted

---

From: Richard Barnes <[email-masked]>
Date: Thu, 14 May 2015 13:04:25 -0400

> at it careful like, not automate the revocation.

The length of this paragraph is why I liked Russ's first revision ("allow
an authorized party to request revocation").  Ultimately, the CA is going
to have some policy about who it allows to revoke.  The protocol needs to
provide authentication of the requestor to support that policy decision,
but beyond that, the policy is up to the CA.

--Richard

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 15 May 2015 11:10:38 -0400

On Wed 2015-05-13 19:36:51 -0400, Ted Hardie wrote:
> revocation on that basis seems off to me.

There is at least one scenario where automated revocation seems
legitimate but automated issuance does not: posession of the
end-entity's secret key.

That is: If i have the secret key, i *also* need to prove something else
(control of the domain) to get a certificate issued.  But if i have the
secret key to an already-issued certificate, i should not need to prove
control of the domain to get the certificate revoked.

If I compromise your secret key, the nicest possible thing i can do with
it is get it revoked.  There is no reason to prevent this action from
anyone who has access to the secret key.

>> authorized party to request revocation of a certificate.

because it lets the WG (and implementers/deployers) decide to include
types of authorization that might be relevant for revocation but not for
issuance, while still covering the general case.

        --dkg

---

From: Paul Winkeler <[email-masked]>
Date: Fri, 15 May 2015 12:16:29 -0400

Isn’t this a means to effect a denial of service attack?  End users maybe “smart” enough to click on the message that allows them to connect anyway, but there are many application stacks out there that fall apart once the certs that control their encrypted connections are revoked…

> On May 15, 2015, at 11:10, Daniel Kahn Gillmor <[email-masked]> wrote:
>

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Fri, 15 May 2015 12:19:55 -0400

I think the point DKG was making is that if an attacker has private
key material you are lucky if they simply revoke your key, so yeah.

On Fri, May 15, 2015 at 12:16 PM, Paul Winkeler
<[email-masked]> wrote:
> Isn’t this a means to effect a denial of service attack?  End users maybe
> “smart” enough to click on the message that allows them to connect anyway,
> but there are many application stacks out there that fall apart once the
> certs that control their encrypted connections are revoked…
>

-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
[email-masked]
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Michael Ströder <[email-masked]>
Date: Fri, 15 May 2015 18:29:33 +0200

Paul Winkeler wrote:
> Isn’t this a means to effect a denial of service attack?

Yes.

But if an attacker has the private key you definitely want to stop the service 
using the accompanying public key cert. Because if you provide a TLS secured 
service you somewhat promise to the user that the traffic cannot be intercepted.

=> full ack with Rich's statement here

Ciao, Michael.