Adam Roach has entered the following ballot position for
draft-ietf-acme-star-09: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
Adam Roach has entered the following ballot position for
draft-ietf-acme-star-09: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
Adam Roach has entered the following ballot position for
draft-ietf-acme-tls-alpn-06: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
Adam Roach has entered the following ballot position for
draft-ietf-acme-acme-16: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
[as an individual]
On 10/5/18 11:21 AM, Jacob Hoffman-Andrews wrote:
In the rounds of reviews on
https://github.com/ietf-wg-acme/acme/pull/445, I missed an addition:
the suggestion to use capability URLs for access control on
certificate URLs. We should definitely not introduce this into the
The new text looks great. Thanks for the work that everyone has done to
address the privacy concerns I highlighted.
I do worry that implementors are likely to overlook the new text when
the examples so clearly do not follow the recommendations in section
10.5. Please note that this was
[as an individual]
On 9/7/18 6:48 PM, Erica Portnoy wrote:
If someone's in a position to watch traffic going *from* a server
trying to authenticate, they can certainly watch traffic going *to*
that server, and note the various domain names being hosted on that
server (since no encrypted sni
On 8/31/18 3:58 PM, Jacob Hoffman-Andrews wrote:
On 08/31/2018 01:51 PM, Adam Roach wrote:
The baseline problem here is that the original analysis that
determined that orders, authorizations, challenges, and certificates
were "not sensitive" was incorrect. These are all potentially
On 8/31/18 3:14 PM, Jacob Hoffman-Andrews wrote:
That winds up leaving us pretty close to being back at draft-14: Since
POST-as-GET protects resource bodies, and the currently-specified
resources are already broken down into sensitive (account) and not
(orders, authorizations, challenges,
.
Adam Roach recently pointed out in his Area Director review that even
when the contents of GET URLs aren’t sensitive, their correlation may
be. For instance, some CAs might consider the grouping of certificates
by account to be sensitive.
Richard Barnes proposes[2] to change all GETs to POSTs
On 8/30/18 8:48 AM, Felix Fontein wrote:
Hello,
On 8/30/18 7:55 AM, Richard Barnes wrote:
Focusing on DISCUSS comment for now, will pick up COMMENTs later.
On your DISCUSS, I think you're off on a couple of small things
Yeah, I woke up with the sudden realization that I'd had the wrong
On 8/30/18 7:55 AM, Richard Barnes wrote:
Focusing on DISCUSS comment for now, will pick up COMMENTs later.
On your DISCUSS, I think you're off on a couple of small things
Yeah, I woke up with the sudden realization that I'd had the wrong model
in my head when I talked through the cert
Adam Roach has entered the following ballot position for
draft-ietf-acme-acme-14: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
On 8/31/17 19:25, Stephen Farrell wrote:
I really like the idea that the acme WG aims to figure out a way to
enable people at home to use https with their home n/w routers.
I'm not at all sure that a DNS-based approach here will cut the
mustard, though it's a not-bad plan to define one in any
14 matches
Mail list logo
