>From RFC 2616:
A client MUST include a Host header field in all HTTP/1.1 request messages
. If the requested URI does not include an Internet host name for the
service being requested, then the Host header field MUST be given with an
empty value.
I guess an IP address is not considered an Intern
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 considered
On 03/25/2017 09:40 AM, Hugo Landau wrote:
> Currently, when an order is created, authorizations are created for it,
> and challenges are created for each of those authorizations.
>
> If a challenge is failed once, the challenge comes to have status
> "invalid", as does the authorization containing
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
wro
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
revocatio
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
rem
>
> 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 considera
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
certi
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 TXT
> record
> > directly i
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
> reverse
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 be
> On 28 Mar 2017, at 01:30, 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 d
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 for
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 un
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
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 t
16 matches
Mail list logo