Re: [Acme] Allowing clients to understand the account creation functionality supported by a server

>From my perspective, the UX from not having this feature is pretty awful. And for clients to try to make the UX not awful, they'd have to add quite a bit of complexity. I'd much rather a must with a bit of extra information in the meta directory. ___

Re: [Acme] draft-shaffer-acme-star-lurk: key lifetime ?

Hi Ilari, all, I strongly disagree with your statement. From a crypto standpoint, key rotation IS an important point and should be addressed. I think something could/should be added to the I-D to limit the number of renewal or the period where the same CSR can be used for certificate

Re: [Acme] draft-shaffer-acme-star-lurk: key lifetime ?

On Thu, Mar 30, 2017 at 12:26:17PM -0500, Dr. Pala wrote: > > I have a small question about the I-D. In particular, it seems to me that > this proposal circumvents any limitation on the effective lifetime of a > short-lived-cert's keypair. From a cryptographic standpoint of view, it is > good

Re: [Acme] draft-shaffer-acme-star-lurk: key lifetime ?

Hi Eric, I am not saying it is the CA job (although, good CAs will impose max life-times on keys), but it seems to me that this issue should be addressed since it would violate one of the basic security principles when it comes to crypto, i.e. key lifetime. Maybe adding something to this

Re: [Acme] draft-shaffer-acme-star-lurk: key lifetime ?

I don't think it's the CA's job to dictate policy in this area. -Ekr On Thu, Mar 30, 2017 at 12:26 PM, Dr. Pala wrote: > Hi all, > > I have a small question about the I-D. In particular, it seems to me that > this proposal circumvents any limitation on the effective

Re: [Acme] Generating nonces probabilistically in 6.4.1. Replay-Nonce

As the veteran of many arguments about pseudorandomness and uniqueness, I think it's reasonable to consider a sufficiently long random string to be unique. "high probability" actually makes it worse, because 99.99 is actually a very high probability but not really a security boundary. If you want

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

On 03/30/2017 09:04 AM, Sean Leonard wrote: > IN PARTICULAR: both Apache and Ngnix may be subject to a private key > substitution attack with naive passing of the ACME response to the web > server! See: > http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate >

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

> On Mar 30, 2017, at 10:47 AM, Jacob Hoffman-Andrews wrote: > >> Therefore the “receiver” is the ACME client, which also is the web/TLS > server that incorporates the chain into its operations. > > Note that in common deployment today, the ACME client is separate from > the web

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

> Therefore the “receiver” is the ACME client, which also is the web/TLS server that incorporates the chain into its operations. Note that in common deployment today, the ACME client is separate from the web server. On 03/30/2017 08:27 AM, Sean Leonard wrote: > Contents: DER-encoded

Re: [Acme] Retrying failed authorizations

On 03/29/2017 08:31 PM, Hugo Landau wrote: >> What is the rest of the group's thoughts on whether we'd have to restart >> WGLC for this? > I'd hope that if the 'can retry individual challenges' option is chosen > this is considered a minor enough change to avoid restarting WGLC. > > However, it

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

On 03/29/2017 01:48 PM, Sean Leonard wrote: > If you are saying that the receiver is only expected to handle TLS > 1.2-ordered certificates: “Each following certificate MUST directly > certify the one preceding it” (MUST, not SHOULD) then we have a > different situation and PKCS #7/CMS certs-only