Re: [Acme] I-D Action: draft-ietf-acme-tls-alpn-00.txt

That's a fair point. Although note that critical extension bugs don't tend to be of the "ignore critical extension" variety (though that happens), they tend to be of the "understand the critical extension for the purposes of rejecting it and then getting the logic backwards" or something

Re: [Acme] ALPN based TLS challenge

The concerns in this email, many of which I share, are the reason why I’d really like to get around to doing a full security analysis of all of the BR validation methods at some point. They’ve mostly been considered in isolation, when in reality there are many overlapping themes. Maybe

Re: [Acme] I-D Action: draft-ietf-acme-tls-alpn-00.txt

I'm generally supportive of this, but one concern I do have, and I admit I'm mostly just thinking aloud here, is that we are slowly accumulating a larger and larger number of things that look like certificates, but aren't due to people playing games with critical extensions. I think we may come

Re: [Acme] Fwd: I-D Action: draft-barnes-acme-token-challenge-02.txt

... and the joint draft Mary was referring to is this: https://www.ietf.org/id/draft-peterson-acme-authority-token-01.txt ... which provides a generic framework for acquiring an authority token as a response to ACME challenges. The specific identifier types for the telephone number and service

Re: [Acme] Concerning alternative formats …

> On Mar 5, 2018, at 3:50 PM, Felipe Gasper wrote: > > >> On Mar 5, 2018, at 1:13 PM, Matthew D. Hardeman >> wrote: >> >> Especially with CT logging being a pragmatic requirement, time-to-delivery >> for certificates is likely to increase

[Acme] I-D Action: draft-ietf-acme-acme-10.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Automated Certificate Management Environment WG of the IETF. Title : Automatic Certificate Management Environment (ACME) Authors : Richard Barnes

[Acme] Fwd: I-D Action: draft-barnes-acme-token-challenge-02.txt

Hi all, This update is just to fix some overt cut and past errors as I inadvertently left references to Service provider code when I was splitting the generic functionality. Please ignore the -01 as I introduced other errors in fixing those errors. It's important to note that this document

Re: [Acme] Concerning alternative formats …

Sure. Plenty of ways to do that. If your primary concern is issuance, then you don't even need server push, you can just long-poll. In HTTP/1.1, that's gross because it ties up a connection and has some disgusting keep-alive properties. In h2 there is no opportunity cost to worry about, the

Re: [Acme] Concerning alternative formats …

Thomson: Could h2 push replace some of the polling here? On Mon, Mar 5, 2018 at 4:50 PM, Felipe Gasper wrote: > > > On Mar 5, 2018, at 1:13 PM, Matthew D. Hardeman > wrote: > > > > Especially with CT logging being a pragmatic requirement, >

Re: [Acme] Concerning alternative formats …

> On Mar 5, 2018, at 1:13 PM, Matthew D. Hardeman wrote: > > Especially with CT logging being a pragmatic requirement, time-to-delivery > for certificates is likely to increase (slightly) rather than decrease. Quick point: the alleviation of polling would go for authz

Re: [Acme] Concerning alternative formats …

My working experience is primarily outside the PKI space, but I can offer some perspectives on scalability and deployment architecture issues. WebSocket is entirely appropriate for real-time or near-real-time bidirectional communications of an asynchronous nature. The overhead of WebSocket as

Re: [Acme] Concerning alternative formats …

> On Mar 5, 2018, at 9:35 AM, Jörn Heissler > wrote: > > On Mon, Mar 05, 2018 at 09:11:02 -0500, Felipe Gasper wrote: >> Regarding alternative formats, I think ACME over WebSocket would be a great >> thing. Replay-nonce would go away, and clients wouldn’t need to

Re: [Acme] Concerning alternative formats …

On Mon, Mar 05, 2018 at 09:11:02 -0500, Felipe Gasper wrote: > Regarding alternative formats, I think ACME over WebSocket would be a great > thing. Replay-nonce would go away, and clients wouldn’t need to poll for the > certificate unless the connection dropped. The server could send the >

Re: [Acme] Explicitly forbid to answer GET requests for account info

Thanks Joern, merged. On Sun, Mar 4, 2018 at 6:57 AM, Jörn Heissler wrote: > Hi, > > another PR that slightly changes meaning (SHOULD NOT -> MUST NOT): > https://github.com/ietf-wg-acme/acme/pull/407 > > Section "Request Authentication" says: > "Servers MUST NOT

[Acme] Concerning alternative formats …

For what it’s worth: Regarding alternative formats, I think ACME over WebSocket would be a great thing. Replay-nonce would go away, and clients wouldn’t need to poll for the certificate unless the connection dropped. The server could send the certificate as soon as it’s ready. A simple