Re: [Acme] ACME -06: revocation

2017-05-30 Thread Yaron Sheffer
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

Re: [Acme] ACME -06: revocation

2017-05-30 Thread Russ Housley
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

Re: [Acme] ACME -06: revocation

2017-05-30 Thread Ilari Liusvaara
On Tue, May 30, 2017 at 06:59:21PM +0300, Yaron Sheffer wrote: > 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

Re: [Acme] ACME -06: HTTPS authorization

2017-05-30 Thread Ilari Liusvaara
On Tue, May 30, 2017 at 11:49:43AM -0400, Richard Barnes wrote: > That just argues for adding for an "https-06" (which is always HTTPS) to go > alongside "http-01" (which is always HTTP). One idea would be to require matching SAN in certificate (but not trusted signer nor in-validity-window).

Re: [Acme] ACME -06 - notBefore/notAfter

2017-05-30 Thread Yaron Sheffer
OK, that wasn't clear to me in the context. Maybe change to: The server MUST return an error if it cannot fulfill the request as specified (including the CSR any other fields), and MUST NOT issue a certificate with contents other than those requested. On 30/05/17 18:53, Richard Barnes

Re: [Acme] ACME -06: revocation

2017-05-30 Thread Yaron Sheffer
On 30/05/17 18:48, Richard Barnes wrote: On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer > wrote: When we allow the issued certificate to revoke itself, this has major implications, in particular for delegated certificates. But

Re: [Acme] ACME -06 - notBefore/notAfter

2017-05-30 Thread Richard Barnes
""" The server MUST return an error if it cannot fulfill the request as specified, and MUST NOT issue a certificate with contents other than those requested. """ https://ietf-wg-acme.github.io/acme/#rfc.section.7.4 On Tue, May 30, 2017 at 11:51 AM, Yaron Sheffer wrote:

[Acme] ACME -06 - notBefore/notAfter

2017-05-30 Thread Yaron Sheffer
In the "Applying for Certificate Issuance" section: the notBefore and notAfter fields are not part of the CSR, and it is not clear if the server is allowed to change them according to its own policy. E.g. for a shorter period than requested. Thanks, Yaron

Re: [Acme] ACME -06: HTTPS authorization

2017-05-30 Thread Richard Barnes
That just argues for adding for an "https-06" (which is always HTTPS) to go alongside "http-01" (which is always HTTP). On Tue, May 30, 2017 at 11:47 AM, Yaron Sheffer wrote: > But removing the restriction would mean that the CA is free to do either > HTTP or HTTPS, and

Re: [Acme] ACME -06: revocation

2017-05-30 Thread Richard Barnes
On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer 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

Re: [Acme] ACME -06: HTTPS authorization

2017-05-30 Thread Yaron Sheffer
But removing the restriction would mean that the CA is free to do either HTTP or HTTPS, and the client doesn't know what to expect. So if my port 80 is firewalled, I'm still not in good shape. Thanks, Yaron On 30/05/17 18:38, Richard Barnes wrote: On Tue, May 30, 2017 at 11:32 AM,

Re: [Acme] ACME -06: HTTPS authorization

2017-05-30 Thread Ilari Liusvaara
On Tue, May 30, 2017 at 06:32:51PM +0300, Yaron Sheffer wrote: > > I'm not sure I understand why the section that describes HTTP > validation so specifically forbids using HTTPS. On the other hand, I > can think of use cases where I would want *only* HTTPS > authorization: > >

[Acme] ACME -06: revocation

2017-05-30 Thread Yaron Sheffer
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

Re: [Acme] ACME -06: HTTPS authorization

2017-05-30 Thread Richard Barnes
On Tue, May 30, 2017 at 11:32 AM, Yaron Sheffer wrote: > I'm not sure I understand why the section that describes HTTP validation > so specifically forbids using HTTPS. > This was because of the default-vhost attack. https://ietf-wg-acme.github.io/acme/#rfc.section.11.2

[Acme] ACME -06: HTTPS authorization

2017-05-30 Thread Yaron Sheffer
I'm not sure I understand why the section that describes HTTP validation so specifically forbids using HTTPS. On the other hand, I can think of use cases where I would want *only* HTTPS authorization: - The server only supports HTTPS, and perhaps port 80 is blocked