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
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
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
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).
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
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
"""
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:
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
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
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
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,
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:
>
>
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
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
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
15 matches
Mail list logo