On Tue, May 15, 2018 at 2:37 AM Ilari Liusvaara
wrote:
> On Tue, May 15, 2018 at 01:20:14AM +0000, Richard Barnes wrote:
> > [ Adding the mailing list ]
> >
> > > S 6.6.
> > > > |
> > | |
> >
[ Adding the mailing list ]
Thanks for the thorough review, EKR. I've posted a PR with proposed
resolutions:
https://github.com/ietf-wg-acme/acme/pull/425
You do hit on a couple of moderately technical points, some of which I
would like the WG to take a quick look at. Those are highlighted wi
Hi Dale,
Thanks for the review. Responses inline below; changes in this PR:
https://github.com/ietf-wg-acme/acme/pull/424
On Wed, Apr 18, 2018 at 9:03 PM, Dale Worley wrote:
> Reviewer: Dale Worley
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The
Hi Dale,
Thanks for the review. Responses inline below; changes in this PR:
https://github.com/ietf-wg-acme/acme/pull/424
On Wed, Apr 18, 2018 at 9:03 PM, Dale Worley wrote:
> Reviewer: Dale Worley
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The
I'm generally skeptical of trying to enumerate what clients should **not**
do. But this seems fine. I approved the PR.
On Tue, Apr 17, 2018 at 12:53 PM, Daniel McCarney
wrote:
> There has been some confusion[0][1] around the relationship between the
> "identifiers" and "authorizations" arrays
Here's a quick PR implementing Tim's proposed changes.
https://github.com/ietf-wg-acme/acme/pull/420
Personally, these seem fine to me. I would be in favor of merging the PR.
On Wed, Apr 11, 2018 at 4:41 PM, Tim Hollebeek
wrote:
>
> I think the draft is in very good shape.
>
> Unfortunately
On Tue, Mar 27, 2018 at 9:16 PM, Sophie Herold
wrote:
> On 27/03/18 22:54, Daniel McCarney wrote:
> > Are you also
> > proposing that authorizations should be retrieved only by authenticated
> > POST?
>
> The information contained in an order will be (more or less) part of the
> certificate. Ther
be too busy
> this week having just come back to work from IETF week. So I’d rather any
> changes that we know are happening should be published before the
> directorates get started on their reviews.
>
> Yoav
>
>
> On 27 Mar 2018, at 22:09, Richard Barnes wrote:
>
>
On Tue, Mar 27, 2018 at 8:26 PM, Sophie Herold
wrote:
>
> On 23/03/18 15:43, Daniel McCarney wrote:
> > My preference here is no. This would introduce two ways to check for the
> > same thing: whether an order is ready. One by checking the status ==
> > "ready" and one by checking if there is a f
Yoav: I'm going to propose we wait until IETF LC ends, and cut a new draft
before sending it to the IESG. Merging PRs is just the modern way of doing
accepting LC comments and addressing them before IESG evaluation.
On Mon, Mar 26, 2018 at 8:00 PM, Daniel McCarney
wrote:
> Richard: Will you tak
This matches my understanding. ACME cannot be prescriptive on this, not
least because the notion of a "root certificate" is not well defined for
the server -- the server doesn't know what the client does or does not
trust.
On Mon, Mar 12, 2018 at 11:26 AM, Martin Thomson
wrote:
> The usage mod
I'm not sure we have material for 30min on the main document. AFAIK, all
the open issues are closed.
On Fri, Mar 9, 2018 at 8:56 AM, Salz, Rich wrote:
> We are meeting Weds, 15:20-16:50 90 minutes
>
>
>
> Agenda bashing + Blue sheets + Note Well (5 min)
> Status update (chairs - 5 min)
>
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
p with httpbis. I think that's an
> error, though probably only an error of omission. 7694 was so fixated
> on solving the content-coding issue, it neglected the obvious
> accompanying fix.
>
> On Mon, Mar 5, 2018 at 9:38 AM, Richard Barnes wrote:
> > How about Accept?
ent, so yes.
> See rfc7694 for details.
>
> 406 is for failed conneg. Not something you expect to see much here.
>
>
> On 5 Mar. 2018 09:25, "Richard Barnes" wrote:
>
> The lengths of the emails in this thread illustrate the complexity risk
> here :)
>
>
The lengths of the emails in this thread illustrate the complexity risk
here :)
In the interest of simplicity, I would really like to stick to Flattened
JSON unless someone has **strong** objections.
Logan, to your point about library compatibility, two notes: (1) it's OK if
we front-run librarie
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
vectors" document separate from the main spec [0]. There are
sagree?
--Richard
>
> Logan
>
>
> On Mar 2, 2018 9:47 AM, "Felipe Gasper" wrote:
>
> Could there be some way of using a header like “Accept” for a server to
> indicate whether it supports jose, jose+json, or both?
>
> -F
>
> > On Mar 2, 2018, at
This is seeming like a lot of work for a pretty minor use case.
I would propose we stick with a simpler solution here. While Sophie's
solution does seem more general, in the interest of getting the spec
shipped, I would propose we just add the boolean flag and write an
extension spec if a more ge
Daniel: I don't have a strong objection here, but could you elaborate what
the client is expected to do differently based on this flag?
On Fri, Mar 2, 2018 at 12:22 PM, Daniel McCarney
wrote:
> Hi folks,
>
> There is a slight disconnect with the current specification between
> identifiers in new
hard
On Fri, Mar 2, 2018 at 9:31 AM, Logan Widick wrote:
> Are challenge retries still supported? If so, how will retries affect the
> state transitions? What state would a server use to indicate that something
> had an error but could be retried later?
>
> Sincerely,
>
> Loga
Hey all,
I merged #395 last night (thanks, Logan!). While I was reviewing that, I
noticed that we need to cover the case where the client sends an encoding
that the server doesn't understand. So I've posted a follow-on that adds
an error code and requires its usage. LMK if you have any objectio
Hey all,
We had a couple of GitHub issues and mailing list posts expressing
confusion about the "status" field in ACME objects. To try to clear all of
that up, I've posted a PR that lays out required state transitions and
aligns the field descriptions with that description. All the description
s
+1
This approach is a major improvement from earlier efforts at a TLS-based
challenge. It follows normal TLS processing logic much more closely,
differing only in the fact that the certificate presented has an extra
extension. Minimizing the differences w.r.t. normal behavior seems like a
good a
On Fri, Jan 19, 2018 at 4:38 PM, Ilari Liusvaara
wrote:
> On Fri, Jan 19, 2018 at 09:51:33AM -0500, Daniel McCarney wrote:
> > >
> > > I agree this approach will limit compatible TLS servers but luckily
> > > HAProxy should be fully compatible.
> >
> >
> > Alas, there's nothing like hitting send
Good point. Posted a PR: https://github.com/ietf-wg-acme/acme/pull/385
On Fri, Jan 5, 2018 at 6:03 PM, Jörn Heissler
wrote:
> Hello,
>
> https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.
> html#rfc.section.7.6
> states:
>
> If this field is not set the server SHOULD use the unspecif
over SHOULD. Updated in 5fcaa6c on my
> PR branch.
>
> - Daniel / cpu
>
> On Fri, Jan 5, 2018 at 4:24 PM, Richard Barnes wrote:
>
>> Why not a MUST? If you don't implement preauthorization, there's no need
>> for a value. I guess you could provide "null&quo
Why not a MUST? If you don't implement preauthorization, there's no need
for a value. I guess you could provide "null", but ... don't.
On Fri, Jan 5, 2018 at 2:33 PM, Daniel McCarney wrote:
> Hi Ilari,
>
>
>> This impiles that if pre-authorization is not supported, newAuthz better
>> be absent
On Wed, Dec 20, 2017 at 4:27 PM, Jacob Hoffman-Andrews wrote:
> On 11/16/2017 02:28 PM, Roland Bracewell Shoemaker wrote:
> > The point of the draft is to provide a method for validating the control
> > of IP addresses in the same way that the ACME draft does for DNS names.
> > This allows ACME i
+1
On Fri, Dec 15, 2017 at 10:24 AM, Daniel McCarney
wrote:
> Hi Sophie,
>
> I think there are two "mistakes" in this example:
>
>
> Agreed on both mistakes. Thanks for flagging!
>
> To avoid unnecessary confusion, I suggest that the table could look something
>> like this:
>
>
> I like your pr
the Automated Certificate Management
> Environment WG of the IETF.
>
> Title : Automatic Certificate Management Environment
> (ACME)
> Authors : Richard Barnes
> Jacob Hoffman-Andrews
> Daniel McCarney
&g
On Wed, Dec 6, 2017 at 3:38 PM, Jacob Hoffman-Andrews wrote:
> On 12/05/2017 03:07 PM, Sophie Herold wrote:
> > Having mentioned new-authz: The definition of new-authz is now a subset
> > of new-order. Is there any reason to keep the new-authz resource at all?
> > Would there be any difference in
Good observation. I would be OK moving everything to camelCase [1], since
it seems like that's a more natural fit for programming language bindings.
This also seems like a less disruptive change than some other things we've
been doing lately (finalization). At best, it's a string change; at wors
I would like to keep it around. Part of the idea of the order and
authorization objects is to provide some possibility of accounting for how
a certificate was issued. Removing the "csr" would remove some of that
transparency.
As Jacob points out, CAs are already required to keep around CSRs in a
On Wed, Nov 29, 2017 at 12:43 PM, Mary Barnes
wrote:
> My comments below [MB].
>
> Regards,
> Mary
>
> On Wed, Nov 29, 2017 at 11:23 AM, Andrew Ayer
> wrote:
>
>> On Tue, 28 Nov 2017 13:28:08 -0500
>> Daniel McCarney wrote:
>>
>> > >
>> > > The canonical example for me here is SSLMate [1], whic
Hey all,
I just posted a PR adding a "meta" field and an error code that allow a CA
to enforce external account binding:
https://github.com/ietf-wg-acme/acme/pull/359
This is a pretty minor change, but I think it will make some use cases flow
better. Please chime in if you think this is a bad i
Thanks for the review, Martin. I've posted responses in a PR, along with a
couple of other minor fixes:
https://github.com/ietf-wg-acme/acme/pull/357
On Tue, Nov 28, 2017 at 5:38 AM, Martin Stiemerling
wrote:
> Hi all,
>
> I've reviewed this document as part of the transport area review team's
might be able to provide further
insight.
But like I said, this is not blocking anything for the base spec any more.
It's just a possible extension if someone shows up and asks for the feature.
--Richard
[1] https://sslmate.com/help/api/rest
>
> - Daniel / cpu
>
>
> On
Using my editor's prerogative, I went ahead and merged this PR.
On Tue, Nov 28, 2017 at 1:05 PM, Richard Barnes wrote:
> I think this is fine to land now. It's not my favorite approach, but
> there's clear consensus. I filed Issue #356 [1] to track the lost
> functi
I think this is fine to land now. It's not my favorite approach, but
there's clear consensus. I filed Issue #356 [1] to track the lost
functionality here, and how we might want to add it back.
https://github.com/ietf-wg-acme/acme/issues/356
On Mon, Nov 27, 2017 at 3:04 PM, Jacob Hoffman-Andrews
This sounds pretty inoffensive to me. Want to send a PR?
Following Daniel's lead on looking for implementation: Is this something LE
would be implementing?
On Thu, Nov 16, 2017 at 9:23 AM, Jacob Hoffman-Andrews wrote:
> In previous versions of ACME, there was sometimes a need to return
> multi
CSR first /
CSR last).
Thanks,
--Richard
On Wed, Nov 8, 2017 at 9:05 AM, Daniel McCarney wrote:
> Hi Ilari,
>
> I guess if you find any use for the key at all depends on if authorizations
>> are order-scoped or account-scoped.
>
>
> See this follow-up thread[0] - it
On Fri, Nov 3, 2017 at 12:59 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:
> On Tue, Oct 31, 2017 at 3:51 PM, Richard Barnes wrote:
> >
> >
> > On Mon, Oct 30, 2017 at 9:37 PM, Kathleen Moriarty
> > wrote:
> >>
> >> Hi
I think the intent when we implemented it was to communicate to clients
that an authz was only good for a single issuance, so that if a client was
doing pre-authorization, they would know that that authorization wouldn't
be reused.
Given that all issuance now goes through new-order, it's probably
gt;> the process. This was mentioned in another thread on this topic, but to
>> provide a concrete example of where this might be useful, Let's Encrypt
>> currently refuses to issue for CSRs containing a weak key. By initially
>> providing the CSR, the server is able to immediat
ed in the finalize request, we're
OK for CA bloat -- the CA can throw away the first CSR after it parses it
and produces the authorizations.
Or rather, they should keep around a hash of the CSR so that they can
verify that the second CSR is the same. Since we should require that.
--Ri
CA isn't willing to issue at the time of
> finalization.
>
> There also isn't a CAA-PKP so we're bikeshedding about impact on features
> that are both unspecified & unimplemented.
>
> - Daniel / cpu
>
> On Mon, Oct 30, 2017 at 3:33 PM, Richard Barnes wrote:
On Tue, Oct 31, 2017 at 4:39 PM, Eric Rescorla wrote:
>
>
> On Tue, Oct 31, 2017 at 12:51 PM, Richard Barnes wrote:
>
>>
>>
>> On Mon, Oct 30, 2017 at 9:37 PM, Kathleen Moriarty <
>> kathleen.moriarty.i...@gmail.com> wrote:
>>
>>> Hi
On Mon, Oct 30, 2017 at 9:37 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:
> Hi Richard,
>
> On Mon, Oct 30, 2017 at 6:27 PM, Richard Barnes wrote:
> >
> >
> > On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty
> > wrote:
> >>
&
ng came up, sorry for the delay and this was a
> good reminder.
>
> On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes wrote:
> > Hi Kathleen,
> >
> > Thanks for the review. Some responses inline. I've started a PR to
> respond
> > to these comments here:
&
Certificate Management
> Environment WG of the IETF.
>
> Title : Automatic Certificate Management Environment
> (ACME)
> Authors : Richard Barnes
> Jacob Hoffman-Andrews
> James Kasten
>
On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney
wrote:
> > Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key).
> Implementing that without knowing the public key at validation time is
> annoying.
>
> Can you expand on "annoying"?
>
> It seems completely possible to reject t
On Wed, Oct 25, 2017 at 4:40 AM, Prasheel Soni
wrote:
> Hi Devs,
>
> I recently tried to implement the 'new-order' process in Node.JS and came
> across several confusions which are required to be cleared before we can
> move on:
>
Hi Prasheel,
In case it's helpful, here's my node.js implementat
Good catch, Logan. Suggested fix:
https://github.com/ietf-wg-acme/acme/pull/346
On Thu, Oct 19, 2017 at 4:52 PM, Logan Widick
wrote:
> I was not involved with RFC 6068 in any way. However, from my
> understanding of the RFC, that subset ("mailto:us...@example.com";) might
> (roughly) look some
On Thu, Oct 19, 2017 at 2:21 PM, Hugo Landau wrote:
> > > With regard to ACME-CAA PR#2: Is a "vendor" validation method, rather
> > > than a prefix, really that useful?
> > >
> >
> > It seems like something we're likely to need at some point, given that
> > there's still some diversity in validat
Picking this up after a long gap...
On Sat, Jul 8, 2017 at 4:44 AM, Hugo Landau wrote:
> > > https://github.com/ietf-wg-acme/acme/pull/332
> Alright, if the ACME spec wants to genericise its validation methods
> registry, I'm okay with the validation-methods change as-is.
>
> Questions:
>
> 1. S
[[ An ACME editor emerges from hibernation... ]]
Hey all,
I've spent a few minutes today processing pull requests. I've merged
several that I didn't think merited WG discussion, but I'm reflecting them
here for visibility (including a couple that Jacob approved as well):
TYPOS:
#327 - Remove "t
Hi Kathleen,
Thanks for the review. Some responses inline. I've started a PR to
respond to these comments here:
https://github.com/ietf-wg-acme/acme/pull/345
I agree with Daniel that we should hold off on IETF LC until we've
addressed the issues around proactive issuance / caching of CSRs. Th
ssue now" request
(vs. the GET poll).
--Richard
On Wed, Sep 20, 2017 at 1:22 PM, Richard Barnes wrote:
> Hey Daniel,
>
> Thanks for the input. I can see why you might be feeling some pain here,
> but I'm not sure the proposed solution is quite right.
>
> Note that
Hey Daniel,
Thanks for the input. I can see why you might be feeling some pain here,
but I'm not sure the proposed solution is quite right.
Note that ACME already has the "new-authorization" flow, which does pretty
much exactly what you're proposing. The only difference is that instead of
autho
Yeah, I agree that the intent here is for the CSR to match the certificate
in all material respects.
This does require the client to know what it wants, so it knows what to put
in the CSR. Do you have a use case where that's not the case?
On Thu, Aug 17, 2017 at 9:54 AM, Salz, Rich wrote:
>
>
changed pictures or not J
>>
>>
>>
>> --
>>
>> Senior Architect, Akamai Technologies
>>
>> Member, OpenSSL Dev Team
>>
>> IM: richs...@jabber.at Twitter: RichSalz
>>
>>
>>
>> *From:* Richard Barnes [mailto:r..
etf-acme-acme-07.txt
>> To: i-d-annou...@ietf.org
>> Cc: acme@ietf.org
>>
>>
>>
>> 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 o
On Fri, Jul 7, 2017 at 2:06 PM, Jacob Hoffman-Andrews wrote:
> On 07/07/2017 06:42 AM, Richard Barnes wrote:
> > C) Instead of using *key* authorizations, use *account*
> > authorizations. Instead of the object being of "token.H(key)", make
> > it "tok
On Fri, Jul 7, 2017 at 9:33 AM, Hugo Landau wrote:
> >On Thu, Jul 6, 2017 at 11:57 AM, Salz, Rich <[1]rs...@akamai.com>
> wrote:
> >
> > So let's see. Can we live with this?
> >
> > Create a spec-required registry for validation method names.
> >
> >I share Hugo's concern about
On Wed, Jul 5, 2017 at 6:03 PM, Jacob Hoffman-Andrews wrote:
> On 06/30/2017 09:54 AM, Dunning, John wrote:
>
> Based on your description below, I think door A makes more sense to me.
> My paraphrase of it is that key authorizations get bound at creation time,
> and thus get “grandfathered” in af
On Thu, Jul 6, 2017 at 11:57 AM, Salz, Rich wrote:
> So let's see. Can we live with this?
>
> Create a spec-required registry for validation method names.
>
I share Hugo's concern about divergence here. Should we maybe just put
these in the ACME challenge types registry? It is already Spec-Re
t would create the semantic I
mention above. That part should probably go into a separate minor update
spec, though, not in this spec.
--Richard
>
> Thanks,
>
> Yaron
>
>
> On 06/07/17 00:17, Richard Barnes wrote:
>
>> Just for context here: I think the original o
Just for context here: I think the original operating model for CAA was
that the CA would tell the customer what values to put in there in order to
authorize issuance. So it was safe to use arbitrary values because it was
basically a closed loop CA -> Customer -> CAA -> CA.
Nonetheless, I sympath
https://github.com/ietf-wg-acme/acme-caa/pull/2
On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich wrote:
> > There's no listing going on here, since there's no registry for the
> values. CABF could put tokens in their documents if they like.
>
> Okay, please propose wording (or did you? Sorry if so)
There's no listing going on here, since there's no registry for the
values. CABF could put tokens in their documents if they like.
On Tue, Jun 13, 2017 at 1:33 PM, Salz, Rich wrote:
> > The two last ones are editorial, but the first about enumerating all BR
> > methods isn't (since it needs new
There isn't anything in the current spec(s), and it doesn't really seem in
scope for this work. That is, I don't think it's worthwhile to make a
one-off solution for updating the DNS with records for ACME, vs. improving
the state of DNS management in general.
That said, you can certainly integrat
gt; I would expect that latter semantics would be hairier for server
> implementors, because they’d need to keep multiple credentials alive and
> associated with the account for the maximum lifetime of any extant tokens.
>
>
> On 6/19/17, 2:44 PM, "Ilari Liusvaara" wrot
I'm going to retract my earlier proposal that we address this issue.
While the idea of better aligning the challenges is aesthetically
appealing, there seems to be agreement that there's not a major security
issue here. And the spec has already passed WGLC with the existing set of
challenges.
So
Thanks for the PRs. I merged them.
I don't think that PUT is appropriate for really any requests that ACME
uses. Quoth RFC 7231:
"""
The PUT method requests that the state of the target resource be
created or replaced with the state defined by the representation
enclosed in the request
OK, I'm not hearing any real enthusiasm for this idea (except from
Daniel). So I'm going to close the PR.
On Wed, Jun 14, 2017 at 6:39 PM, Richard Barnes wrote:
> For some context: https://letsencrypt.org/2017/06/14/acme-v2-api.html
>
> To be clear about my opinion
This seems sensible; rolling keys shouldn't invalidate things in transit
any more than changing your Gmail password should delete your drafts folder.
I would have a little bit of a hard time calling this "purely editorial",
since it specifies server behavior. But it seems like you're just
codifyi
the LE proprietary protocol any
>> special status other than by acknowledging provenance.
>>
>> This is the IETF version of ACME, and as such it needs no version
>> qualification. I doubt that there will be any confusion from this
>> being deployed alongside the proprietary
ut it seems like the regularity it provides will help
simplify analysis and make implementation easier, so I'm inclined to do it.
Thanks,
--Richard
On Tue, Jun 13, 2017 at 1:23 PM, Ilari Liusvaara
wrote:
> On Tue, Jun 13, 2017 at 11:59:21AM -0400, Richard Barnes wrote:
> >
Hey Zach,
Thanks for submitting a PR on this. I just filed a review with some
specific comments:
https://github.com/ietf-wg-acme/acme/pull/312#pullrequestreview-43769669
This change seems fine to me, especially if we make the change I propose in
there to digest the whole key authorization inste
(Everyone get your bike shed paint out)
In talking with a few folks around the community, I've heard people refer
to the IETF version of ACME as "v2", where implicitly "v1" is the initial
version deployed by Let's Encrypt and its clients right now.
How would people feel about reflecting this
Couple of minor comments:
- It might be useful to specify validation methods even without ACME. The
CAB Forum is working on whittling down the space of available mechanisms to
an enumerated list, and while these might not completely overlap with ACME
methods, it will be a small enough list to enu
I don't think we should adopt this until the Recurring Orders stuff has
been split out.
I'm still not convinced of the need for the other interface here, much less
the need to do it in this WG.
On Fri, Jun 9, 2017 at 4:47 PM, Russ Housley wrote:
>
> > On 08/06/2017, 20:56, "Acme on behalf of Ru
"""
The server MUST return an error if it cannot fulfill the request as
specified, and MUST NOT issue a certificate with contents other than those
requested.
"""
https://ietf-wg-acme.github.io/acme/#rfc.section.7.4
On Tue, May 30, 2017 at 11:51 AM, Yaron Sheffer
wrote:
> In the "Applying for C
nd the client doesn't know what to expect. So if my port 80
> is firewalled, I'm still not in good shape.
>
> Thanks,
>
> Yaron
>
> On 30/05/17 18:38, Richard Barnes wrote:
>
>
>
> On Tue, May 30, 2017 at 11:32 AM, Yaron Sheffer
> wrote:
>
>&g
On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer
wrote:
> When we allow the issued certificate to revoke itself, this has major
> implications, in particular for delegated certificates. But even for
> regular certs, it is the account's private key that's more secure (it is
> managed by the securit
On Tue, May 30, 2017 at 11:32 AM, Yaron Sheffer
wrote:
> I'm not sure I understand why the section that describes HTTP validation
> so specifically forbids using HTTPS.
>
This was because of the default-vhost attack.
https://ietf-wg-acme.github.io/acme/#rfc.section.11.2
Given that we don't rea
y-return-existing" is true and the
> account doesn't exist?
>
> On Thu, Apr 27, 2017 at 2:40 PM, Richard Barnes wrote:
>
>>
>>
>> On Tue, Apr 18, 2017 at 1:34 AM, Hugo Landau wrote:
>>
>>> >In reviewing a PR today noting that a client can fi
I agree we should forbid this behavior. Draft PR specifying an HTTP error
code but not an ACME one:
https://github.com/ietf-wg-acme/acme/pull/307
On Thu, Apr 20, 2017 at 7:02 PM, Logan Widick
wrote:
> So there would need to be a new error type (possibly named something like
> "accountKeyCollis
Based on Jacob's research, I'm pretty well convinced that this is not an
issue. Nonetheless, I have posted a PR to add some text about this risk.
https://github.com/ietf-wg-acme/acme/pull/306
On Thu, Apr 27, 2017 at 12:55 AM, Jacob Hoffman-Andrews
wrote:
> On 03/30/2017 09:04 AM, Sean Leonard
On Tue, Apr 18, 2017 at 1:34 AM, Hugo Landau wrote:
> >In reviewing a PR today noting that a client can find the account URI
> for
> >a key pair using a new-account request with an empty payload [1],
> Jacob
> >and I thought it might be a little more robust to use an explicit
> signal
rders, its certificates and its
> authorizations?
>
Same as before -- you get a 200 with the existing account.
--Richard
>
> Sincerely,
>
> Logan Widick
>
> On Apr 17, 2017 17:45, "Richard Barnes" wrote:
>
>> In reviewing a PR today noting that a cli
On Tue, Apr 18, 2017 at 1:28 AM, Hugo Landau wrote:
> >Hey Hugo,
> >Thanks for the PR. Jacob and I chatted a bit about this, and wanted
> to
> >propose a slightly different approach:
> >[1]https://github.com/ietf-wg-acme/acme/pull/297
> >What do you think? Others on the list
On Wed, Apr 26, 2017 at 2:09 PM, Logan Widick
wrote:
> According to the draft minutes, as of the end of IETF 98, the plan was to
> eliminate the "up" link relation from authorization to order since an
> authorization can belong to multiple orders and nobody seemed to rely on
> this relation. Howe
In reviewing a PR today noting that a client can find the account URI for a
key pair using a new-account request with an empty payload [1], Jacob and I
thought it might be a little more robust to use an explicit signal. I've
posted a PR that adds a "recovery" field to indicate to the server that i
Hey Hugo,
Thanks for the PR. Jacob and I chatted a bit about this, and wanted to
propose a slightly different approach:
https://github.com/ietf-wg-acme/acme/pull/297
What do you think? Others on the list have any thoughts?
Thanks,
--Richard
On Sun, Apr 9, 2017 at 4:47 AM, Hugo Landau wrote:
On Fri, Mar 31, 2017 at 5:23 PM, Sean Leonard wrote:
> Hi ACME:
>
> SECOND PART.
>
> I think some of my comments may have been misconstrued about the “**Don't
> call it PEM certificate chain** (slide 21)” issue.
>
> Textual encoding amounts to a way to ASCII-armor binary data in plain
> text. Thi
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
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 provision
101 - 200 of 392 matches
Mail list logo
