Re: [Acme] Require servers to accept at least one automated revocation method

The other endpoints' sections in the document are written using language assuming that that endpoint is implemented, so it makes sense to do the same thing here. So given that there's a revocation endpoint, you're saying that all of the revocation authorization methods mentioned must be

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

Dumping some of this info in `directory.meta` doesn't really seem that tragic to me. It's not that much information, and could avoid some errors. I would note, however, that we could also do this in an extension, rather than in the main spec. On Tue, Mar 28, 2017 at 6:04 PM, Daniel McCarney

Re: [Acme] Require servers to accept at least one automated revocation method

There's no requirement for the server to have a revocation endpoint at all! """ The server MUST provide “directory” and “new-nonce” resources. """ ... not "revoke-cert". It's up to the CA which parts of ACME they use. The only way this would make sense is if it were framed as "for the

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

I still think this is the wrong layer to solve this problem. If the crux of the matter is that `urn:ietf:params:acme:error:invalidContact` isn't sufficient to distinguish between invalid vs unsupported without parsing we could add a `urn:ietf:params:acme:error:unsupportedContact` error type and

Re: [Acme] Entropy requirement for challenge token

> > I think Daniel's change at https://github.com/ietf-wg- > acme/acme/pull/284/files is a nice quick fix to the issue, but I agree it > could use a few extra sentences explaining it in security considerations. I will take a crack at amending this PR with a few sentences in the security

[Acme] Require servers to accept at least one automated revocation method

Section 7.6 reads: Revocation requests are different from other ACME requests in that they can be signed either with an account key pair or the key pair in the certificate. Before revoking a certificate, the server MUST verify that the key used to sign the request is authorized to revoke the

Re: [Acme] Fwd: New Version Notification for draft-shoemaker-acme-ip-00.txt

On Tue, Mar 28, 2017 at 3:08 PM, Ilari Liusvaara wrote: > On Mon, Mar 27, 2017 at 07:28:53PM -0400, Richard Barnes wrote: > > Thanks, Roland. Interesting draft. > > > > Couple of first reactions: > > > > - Why use the target of the PTR instead of just provisioning the

Re: [Acme] Fwd: New Version Notification for draft-shoemaker-acme-ip-00.txt

On Mon, Mar 27, 2017 at 07:28:53PM -0400, Richard Barnes wrote: > Thanks, Roland. Interesting draft. > > Couple of first reactions: > > - Why use the target of the PTR instead of just provisioning the TXT record > directly in the reverse DNS. (Is there some restriction in the spec for >

[Acme] Fwd: I-D Action: draft-barnes-acme-service-provider-00.txt

Hi all, Chris and I put together this draft which has some extensions to support an ACME challenge based on a service provider identifer and token. This is based on the work in the ATIS/SIP Forum NNI task group. The document has not yet been approved so there isn't on a public server but can

Re: [Acme] Fwd: New Version Notification for draft-shoemaker-acme-ip-00.txt

On 03/27/2017 05:30 PM, Roland Bracewell Shoemaker wrote: > The original reason for this was that I held the belief that there was > an RFC that set restrictions on the record types that should exist in > the reverse zones (i.e. PTR/CNAME/NS/SOA) only. After looking through > relevant documents

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

At 11:46 28/03/2017 Tuesday, Martin Thomson wrote: >I agree with Jacob here. MUST seems appropriate, but requiring >uniqueness absolutely imposes a constraint on server design that is so >onerous that I would see it as impractical. (Also, the document >doesn't really identify a scope for this

Re: [Acme] Fwd: New Version Notification for draft-shoemaker-acme-ip-00.txt

At 00:28 28/03/2017 Tuesday, Richard Barnes wrote: >Thanks, Roland. Interesting draft. > >Couple of first reactions: > >- Why use the target of the PTR instead of just provisioning the TXT record >directly in the reverse DNS.  (Is there some restriction in the spec for >reverse DNS that says

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

I agree with Jacob here. MUST seems appropriate, but requiring uniqueness absolutely imposes a constraint on server design that is so onerous that I would see it as impractical. (Also, the document doesn't really identify a scope for this uniqueness, which would probably be necessary if you had