Subject: [Acme] Why revocation a certificate can't be done without authorization ?

From: Kas <[email-masked]>
Date: Sat, 15 Sep 2018 05:37:41 +0300

Hello everyone,

Shouldn't the revocation process more relaxed ?
Section.7.6 require account authorization to revoke a certificate, and i 
can't see the good of this requirement and making it the only way, it is 
logical that the account owner can revoke a certificate, what i suggest 
is :
Anyone should be able to revoke a certificate if he can prove that he 
has the private key of the certificate AND can pair it with the 
certificate itself ( Serial Number, Public Key .... ), for me this makes 
more sense, in case a server had been compromised then no need to wait 
for the account owner, so directory should have permanent URL for 
revocation that will take the Private Key of a certificate (or its hash) 
along the Serial number of the certificate, and would love to hear 
explanation of why this might be bad practice.

Best regards
K. Obaideen

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 15 Sep 2018 07:29:16 +0300

On Sat, Sep 15, 2018 at 05:37:41AM +0300, Kas wrote:
> logical that the account owner can revoke a certificate, what i suggest is :
> Anyone should be able to revoke a certificate if he can prove that he has
> the private key of the certificate AND can pair it with the certificate
> itself ( Serial Number, Public Key .... ), for me this makes more sense, in
> case a server had been compromised then no need to wait for the account
> owner, so directory should have permanent URL for revocation that will take
> the Private Key of a certificate (or its hash) along the Serial number of
> the certificate, and would love to hear explanation of why this might be bad
> practice.

One can already sign revocation requests using private key of the
certificate being revoked (without even having an account). And this
uses the usual revocation endpoint found in the directory.

-Ilari

---

From: Kas <[email-masked]>
Date: Thu, 20 Sep 2018 15:58:56 +0300

From section 2 :
"The CA verifies that the client controls the requested domain name(s) 
by having the ACME client perform some action(s) that can only be done 
with control of the domain name(s). For example, the CA might require a 
client requesting example.com to provision DNS record under example.com 
or an HTTP resource under http://example.com."

I suggest to use "example.com" only for the client mentioned in section 
2, while adding another identifier like "acmeserver.com" or 
"caserver.com" will enhance the readability of all these examples.

---

From: Felipe Gasper <[email-masked]>
Date: Thu, 20 Sep 2018 09:02:46 -0400

Are “acmeserver.com” or “caserver.com” reserved domains?

What about:

acme-client.example.com

acme-server.example.com

?

-FG

> On Sep 20, 2018, at 8:58 AM, Kas <kas=[email-masked]> wrote:
> 
> From section 2 :
> "The CA verifies that the client controls the requested domain name(s) by having the ACME client perform some action(s) that can only be done with control of the domain name(s). For example, the CA might require a client requesting example.com to provision DNS record under example.com or an HTTP resource under http://example.com."
> 
> I suggest to use "example.com" only for the client mentioned in section 2, while adding another identifier like "acmeserver.com" or "caserver.com" will enhance the readability of all these examples.
> 
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Sep 2018 09:54:38 -0500

The list of reserved names is here:

https://tools.ietf.org/html/rfc2606

I can understand how something more evocative might be helpful, but at this
point, I'm inclined to let it be.

--Richard

On Thu, Sep 20, 2018 at 8:04 AM Felipe Gasper <[email-masked]>
wrote:

> by having the ACME client perform some action(s) that can only be done with
> control of the domain name(s). For example, the CA might require a client
> requesting example.com to provision DNS record under example.com or an
> HTTP resource under http://example.com."
> >
> 2, while adding another identifier like "acmeserver.com" or "caserver.com"
> will enhance the readability of all these examples.
> >

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 20 Sep 2018 15:26:01 +0000

*   I can understand how something more evocative might be helpful, but at this point, I'm inclined to let it be.

I agree.  Using subdomains of example.com in the examples will no doubt lead to some questioning why the domains aren’t totally different.

It’s not perfect, but especially now, let’s not try to asymptotically approach that.

---

From: Alan Doherty <[email-masked]>
Date: Thu, 20 Sep 2018 16:08:06 +0100

or both

 From section 2 :
"The CA verifies that the client controls the requested domain name(s) by having the ACME client perform some action(s) that can only be done with control of the domain name(s). For example, the CA might require a client requesting example.org to provision DNS record under requested-name.example.org or an HTTP resource under http://requested-name.example.org."

I suggest to use "example.org" only for the client mentioned in section 2, while adding another identifier like "acmeserver.example.net" or "caserver.example.net" will enhance the readability of all these examples.

thus differentiating the
role.example.(org for request org, net for acme provider, com and others for other cases)

thus both role(descriptive) and tld(consistent)

so say a SAN example could be (to show domains don't have to be related)
requested-name.example.org
other-requested-name.example.com

acmeserver.example.net

At 14:02 20/09/2018  Thursday, Felipe Gasper wrote:
>Are “acmeserver.com” or “caserver.com” reserved domains? What about: acme-client.example.com acme-server.example.com ? -FG > On Sep 20, 2018, at 8:58 AM, Kas <kas=[email-masked]> wrote: > > From section 2 : > "The CA verifies that the client controls the requested domain name(s) by having the ACME client perform some action(s) that can only be done with control of the domain name(s). For example, the CA might require a client requesting example.com to provision DNS record under example.com or an HTTP resource under http://example.com." > > I suggest to use "example.com" only for the client mentioned in section 2, while adding another identifier like "acmeserver.com" or "caserver.com" will enhance the readability of all these examples. > > _______________________________________________ > Acme mailing list > [email-masked] > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email-masked] https://www.iet
f.org/mailman/listinfo/acme

---

From: Tim Hollebeek <[email-masked]>
Date: Thu, 20 Sep 2018 15:42:20 +0000

I strongly agree with those who do not want to open this can of worms at this time, but my preference for examples in future documents would be something like "example.com" for a generic domain name being validated (because the .com tends to evoke a generic end-user DNS name, for better or worse), while using things like "acme-server.example" for more specific server roles.

The documents could even explicitly specify this convention (example.com or .net is a generic domain name being validated, anything .example is the name of a specific server acting in a particular role).

I think such an explicit enumeration of how various example names are used, and consistent use of such a naming policy would make many documents and examples much clearer.

-Tim

> -----Original Message-----
> From: Acme <[email-masked]> On Behalf Of Alan Doherty
> Sent: Thursday, September 20, 2018 11:08 AM
> To: Felipe Gasper <[email-masked]>; Kas
> <kas=[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Acme] example.com is used all over the draft
> 
> or both
> 
>  From section 2 :
> "The CA verifies that the client controls the requested domain name(s) by
> having the ACME client perform some action(s) that can only be done with
> requesting example.org to provision DNS record under requested-
> name.example.org or an HTTP resource under http://requested-
> name.example.org."
> 
> I suggest to use "example.org" only for the client mentioned in section 2, while
> adding another identifier like "acmeserver.example.net" or
> "caserver.example.net" will enhance the readability of all these examples.
> 
> thus differentiating the
> requested-name.example.org other-requested-name.example.com
> 
> acmeserver.example.net
> 
> >Are â€œacmeserver.comâ€ or â€œcaserver.comâ€ reserved domains?
> What
> >about: acme-client.example.com acme-server.example.com ? -FG > On Sep
> >20, 2018, at 8:58 AM, Kas <kas=[email-masked]> wrote: > >
> >From section 2 : > "The CA verifies that the client controls the
> >requested domain name(s) by having the ACME client perform some
> >action(s) that can only be done with control of the domain name(s). For
> >example, the CA might require a client requesting example.com to
> >provision DNS record under example.com or an HTTP resource under
> >http://example.com." > > I suggest to use "example.com" only for the
> >client mentioned in section 2, while adding another identifier like
> >"acmeserver.com" or "caserver.com" will enhance the readability of all
> >these examples. > > _______________________________________________
> >
> >Acme mailing list > [email-masked] >
> >_______________________________________________ Acme mailing list
> >[email-masked] https://www.iet