> On Mar 5, 2018, at 5:58 PM, Matthew D. Hardeman wrote:
>
>> On Mar 5, 2018, at 3:50 PM, Felipe Gasper wrote:
>>
>> Quick point: the alleviation of polling would go for authz status as well as
>> to certificate delivery.
>>
>> A certificate order that has 10 domains needs to poll for the st
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 similar
On 03/05/2018 04:37 PM, Tim Hollebeek wrote:
> I think we may come to regret using that trick so much. Such schemes
> are only one software bug away from having rather profound effects
> on trust decisions and the entire ecosystem.
This is a good point, but an important mitigating factor is that t
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 we’l
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 to
... 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 p
> 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 (slightly) rather than decrease.
>
> Quick point:
Draft 10 highlight reel for the tl;dr crowd:
- Clarification of JWS serialization. ACME now requires flattened JSON
serialization - https://github.com/ietf-wg-acme/acme/pull/410
- Clarification of object status fields and state model (incl. new
"ready" state for orders): https://github
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
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 do
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 conn
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,
> time-to-delivery for certificates is likely to increas
On 03/04/2018 02:17 PM, Richard Barnes wrote:
> Hey Joern,
>
> This is a probably a good thing to have. I think that rather than
> putting these in the main spec, it might be better to have them in a
> second draft. This is a pretty common pattern. For example, for TLS
> 1.3, there's a "test ve
> 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 status as well as to
cer
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 a
> 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 poll for the
>> certificate u
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
> certi
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 respond to GET requests for resou
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 handshak
19 matches
Mail list logo
