This all looks good to me.
On 02/13/2017 05:49 PM, Roland Shoemaker wrote:
> I propose we remove the 'author', 'revoke', and 'ct-sct' link relations.
> 'author' seems to provide no concrete value, and 'revoke' is already
> provided by the 'directory' endpoint. The 'ct-sct' relation is also
>
I propose we remove the 'author', 'revoke', and 'ct-sct' link relations.
'author' seems to provide no concrete value, and 'revoke' is already
provided by the 'directory' endpoint. The 'ct-sct' relation is also
somewhat pointless as the SCT will be provided by the CA via the
certificate or a OCSP
At Rich's request, here are the technical parts. I assume that the
editors will be trawling through the entirety of the original mail
(for which I apologize).
These are just the headline items, I pulled two forward because I
think they are more important. The others are small beans. Of course
>From the WGLC thread, Russ Housley said:
> Section 6.4.2 says:
> The default format of the certificate is PEM (application/x-pem-file)
> as specified by [RFC7468]. ... The client may request other formats by
> including an Accept header in its request. For example, the client
> may use the
I would concur that clients should endeavour to support
(and thusly CAs can consider using in future, when support is available in
wider librarys)
but because of the risks they should only consider doing so
if/when all their processes are in place to ensure failures can't occur
but how best to
On 02/13/2017 12:20 PM, Russ Housley wrote:
> I do not think it is a risk with the authorizations that have been
> defined. I was wondering about a situation where a client make a
> mistake. If a client tries to fulfill one of the authorizations and
> for some reason is unable to do so completely,
> In the WGLC thread, Russ asked:
>
>> In Section 6.5, should the example use different challenges for "http-01",
>> "tls-sni-02", and "dns-01"?
> (https://ietf-wg-acme.github.io/acme/#rfc.section.6.5)
>
> I assume you meant "token" here, and no, I think the token can be the same
> across
On 02/12/2017 10:09 PM, Anders Rundgren wrote:
> JWS is great for what is was originally designed for. ES6 normalization
> nullifies the need for dressing JSON data in Base64Url.
Could you clarify this comment? Are you proposing that ACME should not
wrap internal fields in another layer of
I would definitely support removing ", and servers SHOULD emit pinning
headers", especially because of the footgun risk you indicated, but I think
there *is* some merit in continuing to recommend support for HPKP on the
client side.
On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews
In the WGLC thread, Russ asked:
> In Section 6.5, should the example use different challenges for "http-01",
> "tls-sni-02", and "dns-01"?
(https://ietf-wg-acme.github.io/acme/#rfc.section.6.5)
I assume you meant "token" here, and no, I think the token can be the same
across multiple
Martin brought up a section I've been considering removing:
> Clients SHOULD support HTTP public key pinning [RFC7469], and servers
SHOULD emit pinning headers.
Here's my reasoning:
- Public key pinning isn't implemented in most HTTPS libraries outside
of browsers, so this is a considerable
Rich asked to me to divide my comments into technical and editorial. This are
the same comment that I sent earlier with that categorization.
Russ
= = = = = = = =
TECHNICAL
In Section 5.1, I think it is desirable to add a requirement that the ACME
server SHOULD OCSP Staple.
In Section 5.5,
12 matches
Mail list logo
