Subject: [Acme] ACME -06: revocation

From: Yaron Sheffer <[email-masked]>
Date: Tue, 30 May 2017 18:42:11 +0300

When we allow the issued certificate to revoke itself, this has major 
implications, in particular for delegated certificates. But even for 
regular certs, it is the account's private key that's more secure (it is 
managed by the security personnel where such exist, it is not deployed 
on multiple servers) and that is the certificate that should be 
preferred for revocation. So I suggest to use MAY for revocation by the 
issued certificate's private key, instead of SHOULD.

Also, including the actual certificate in the request means that the CA 
needs to perform multiple preliminary checks that would not be required 
if the client sent the certificate URL (or its serial number). The CA 
MUST parse the certificate, MUST validate it, MUST ensure that it was 
issued by the current CA, and then MUST identify it in its database of 
issued certs. More complexity, more opportunities for security holes.

Thanks,
     Yaron

---

From: Richard Barnes <[email-masked]>
Date: Tue, 30 May 2017 11:48:10 -0400

On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer <[email-masked]>
wrote:

> managed by the security personnel where such exist, it is not deployed on
> multiple servers) and that is the certificate that should be preferred for
> revocation. So I suggest to use MAY for revocation by the issued
> certificate's private key, instead of SHOULD.
>

You MAY not like the latest change we made, which upgraded this requirement
to MUST :)

https://github.com/ietf-wg-acme/acme/pull/300

> needs to perform multiple preliminary checks that would not be required if
> the client sent the certificate URL (or its serial number). The CA MUST
> parse the certificate, MUST validate it, MUST ensure that it was issued by
> the current CA, and then MUST identify it in its database of issued certs.
> More complexity, more opportunities for security holes.
>

The idea of including the certificate (as well as allowing a certificate to
revoke itself) was to support the case where an admin just finds a
certificate + private key lying around, and wants to kill it.  In that
case, you have neither the Certificate URI nor the account private key.

I would note that we have shifted from referencing keys by value to by
reference in request JWS objects, requiring clients to track their account
URIs.  We made that change in the interest of forcing the server to look up
a public key for the account, reducing the likelihood of the server
accepting a signature by an unknown key.

We might get some similar benefits here, but maybe not -- after all, if the
certificate doesn't correspond to a URI, then it's probably not from this
CA, in which case it the CA can't revoke it anyway.

--Richard

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

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 30 May 2017 18:59:21 +0300

On 30/05/17 18:48, Richard Barnes wrote:
>
>
> On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     When we allow the issued certificate to revoke itself, this has
>     major implications, in particular for delegated certificates. But
>     even for regular certs, it is the account's private key that's
>     more secure (it is managed by the security personnel where such
>     exist, it is not deployed on multiple servers) and that is the
>     certificate that should be preferred for revocation. So I suggest
>     to use MAY for revocation by the issued certificate's private key,
>     instead of SHOULD.
>
>
> You MAY not like the latest change we made, which upgraded this 
> requirement to MUST :)
>
>     Also, including the actual certificate in the request means that
>     the CA needs to perform multiple preliminary checks that would not
>     be required if the client sent the certificate URL (or its serial
>     number). The CA MUST parse the certificate, MUST validate it, MUST
>     ensure that it was issued by the current CA, and then MUST
>     identify it in its database of issued certs. More complexity, more
>     opportunities for security holes.
>
>
> The idea of including the certificate (as well as allowing a 
> certificate to revoke itself) was to support the case where an admin 
> just finds a certificate + private key lying around, and wants to kill 
> it.  In that case, you have neither the Certificate URI nor the 
> account private key.
>
> reference in request JWS objects, requiring clients to track their 
> account URIs.  We made that change in the interest of forcing the 
> server to look up a public key for the account, reducing the 
> likelihood of the server accepting a signature by an unknown key.
>
> We might get some similar benefits here, but maybe not -- after all, 
> if the certificate doesn't correspond to a URI, then it's probably not 
> from this CA, in which case it the CA can't revoke it anyway.
>
> --Richard
>
I certainly don't like the latest change :-)

I understand the use case of "finding a key lying around" (although I've 
never personally found a key lying around), but if you think of an 
enterprise with a small group of people managing security but a much 
larger group of people with access to server certs, this provides any 
server admin with a trivial way to DoS the organization by revoking 
www.bigcorp.com, so trivial that people can do it by mistake.

Thanks,

     Yaron

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 30 May 2017 19:50:54 +0300

On Tue, May 30, 2017 at 06:59:21PM +0300, Yaron Sheffer wrote:

> enterprise with a small group of people managing security but a much larger
> group of people with access to server certs, this provides any server admin
> with a trivial way to DoS the organization by revoking www.bigcorp.com, so
> trivial that people can do it by mistake.

Well, if the server admin is maliscous and has access to keys, he can do
worse things than to revoke certificates.

This mechanism is also limited to the single keypair, unlike say the revoke-
with-domain-authorization, which can revoke certificates with arbitrary domain
and account keys.

Also, if maliscous actors get ahold of private key, that is very definition
of private key compromise (and revocation is REQUIRED in that case, the ToS
of every public CA says so, since it is BR requirement).

And I think serious admins know when to request revocation, unlike lots of
persons on community.letsencrypt.org or similar places.

-Ilari

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 May 2017 13:10:32 -0400

Yaron:

If a party that has access to the private key is telling the CA that the certificate ought to be revoked.  I’m thinking that the CA ought to revoke it.  Any party that has access to that private key can do far more malicious things.

Russ

> On May 30, 2017, at 11:48 AM, Richard Barnes <[email-masked]> wrote:
> 
> 
> 
> On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer <[email-masked] <mailto:[email-masked]>> wrote:
> When we allow the issued certificate to revoke itself, this has major implications, in particular for delegated certificates. But even for regular certs, it is the account's private key that's more secure (it is managed by the security personnel where such exist, it is not deployed on multiple servers) and that is the certificate that should be preferred for revocation. So I suggest to use MAY for revocation by the issued certificate's private key, instead of SHOULD.
> 
> You MAY not like the latest change we made, which upgraded this requirement to MUST :)
> 
> https://github.com/ietf-wg-acme/acme/pull/300 <https://github.com/ietf-wg-acme/acme/pull/300>
> 
>  
> Also, including the actual certificate in the request means that the CA needs to perform multiple preliminary checks that would not be required if the client sent the certificate URL (or its serial number). The CA MUST parse the certificate, MUST validate it, MUST ensure that it was issued by the current CA, and then MUST identify it in its database of issued certs. More complexity, more opportunities for security holes.
> 
> The idea of including the certificate (as well as allowing a certificate to revoke itself) was to support the case where an admin just finds a certificate + private key lying around, and wants to kill it.  In that case, you have neither the Certificate URI nor the account private key.
> 
> I would note that we have shifted from referencing keys by value to by reference in request JWS objects, requiring clients to track their account URIs.  We made that change in the interest of forcing the server to look up a public key for the account, reducing the likelihood of the server accepting a signature by an unknown key.
> 
> We might get some similar benefits here, but maybe not -- after all, if the certificate doesn't correspond to a URI, then it's probably not from this CA, in which case it the CA can't revoke it anyway.
> 
> --Richard
> 
>  
> 
> Thanks,
>     Yaron
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/acme <https://www.ietf.org/mailman/listinfo/acme>
>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 30 May 2017 23:26:09 +0300

I know I'm in the rough here, but IMHO for many enterprises, when they 
compare between a certain downtime and a not so certain MITM threat, 
they would decide differently. But I'm not going to argue this point any 
further.

Thanks,

     Yaron

On 30/05/17 20:10, Russ Housley wrote:
> Yaron:
>
> If a party that has access to the private key is telling the CA that 
> the certificate ought to be revoked.  I’m thinking that the CA ought 
> to revoke it.  Any party that has access to that private key can do 
> far more malicious things.
>
> Russ
>
>
>
>> On May 30, 2017, at 11:48 AM, Richard Barnes <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
>> On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     to use MAY for revocation by the issued certificate's private
>>     key, instead of SHOULD.
>>
>>
>>     the CA needs to perform multiple preliminary checks that would
>>     not be required if the client sent the certificate URL (or its
>>     serial number). The CA MUST parse the certificate, MUST validate
>>     it, MUST ensure that it was issued by the current CA, and then
>>     MUST identify it in its database of issued certs. More
>>     complexity, more opportunities for security holes.
>>
>>
>> just finds a certificate + private key lying around, and wants to 
>> kill it.  In that case, you have neither the Certificate URI nor the 
>> account private key.
>>
>> I would note that we have shifted from referencing keys by value to 
>> by reference in request JWS objects, requiring clients to track their 
>> if the certificate doesn't correspond to a URI, then it's probably 
>> not from this CA, in which case it the CA can't revoke it anyway.
>>
>> --Richard
>>
>>
>>     Thanks,
>>         Yaron
>>
>>     <https://www.ietf.org/mailman/listinfo/acme>
>>
>>