Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)

> > I thought that was the reason why ACME limits wildcard authz to DNS. I don't think RFC 8555 imposes any restrictions on what challenge types can be used for wildcard identifiers. Limiting wildcard DNS identifiers to the DNS-01 challenge is a policy decision by Let's Encrypt. On Mon, Jan

Re: [Acme] orders, authorizations, and identifiers (oh my)

to be some policy > external to ACME that would indicate the feasibility of such a thing. > > Does that sound right? > > -F > > > On Jul 16, 2019, at 10:24 AM, Daniel McCarney > wrote: > > > > So if we tell the human operator, “Jane & Pat gave the OK, but Fred

Re: [Acme] orders, authorizations, and identifiers (oh my)

> > So it would be reasonable for this order to contain a single authz … and > would that authz’s identifier be just “example.com”, then? Thus that > authz object would not reference “www”, even though it is that domain’s > corresponding authz object? Or would a client be accountable for >

Re: [Acme] Responding to challenges - spec bug?

Thanks Rob, I also agree this is a valid erratum finding with the spec. On Wed, May 22, 2019 at 7:34 AM Rob Stradling wrote: > On 20/05/2019 20:29, Jörn Heissler wrote: > > On Mon, May 20, 2019 at 15:56:21 +, Rob Stradling wrote: > >> How would folks feel about an erratum to change that

Re: [Acme] RFC 8555 on Automatic Certificate Management Environment (ACME)

+1! Thanks everyone! On Mon, Mar 11, 2019 at 6:03 PM Jacob Hoffman-Andrews wrote: > Yes, big thanks! This was a huge group effort over many years, and I'm > very grateful to everyone who has contributed to it. > > ___ > Acme mailing list >

Re: [Acme] Add badPublicKey error

> > As an individual, I dislike putting "here's what's wrong with your key" in > the error message. For example, it encourages a thief to do "venue > shopping" looking for a CA that will certify their stolen keypair. > I don't think this is a meaningful example. The server has to return some kind

Re: [Acme] Add badPublicKey error

+1 - this seems like something we should have had already. Thanks for catching & proposing the fix Rob. On Thu, Jan 24, 2019 at 9:30 AM Richard Barnes wrote: > This seems fine to me. It's basically just a table entry, with some > description of how to use it. > > --Richard > > On Thu, Jan 24,

Re: [Acme] AD Review: draft-ietf-acme-star-04

Hi Diego, > There is a Boulder-based full implementation Does Telefonica plan to maintain the copy of Boulder you forked into this repo as a stand-alone project separate from github.com/letsencrypt/boulder? On Wed, Jan 16, 2019 at 6:21 PM Diego R. Lopez wrote: > Hi, > > > > There is a

Re: [Acme] vestige of certificate GET

> > I’m under the impression that plain GET for certificates is not to be > part of the principal ACME spec; should the above, then, be removed? Good catch, I agree. It doesn't look like EKR/Richard's PR (#467) covers this so I opened another: https://github.com/ietf-wg-acme/acme/pull/468 On

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

I am also opposed to this change. I think it is a clunky solution and there hasn't been convincing justification of why the base ACME draft needs to carry this complexity instead of having STAR add the extensions it requires. On Mon, Oct 8, 2018 at 3:27 PM Jacob Hoffman-Andrews wrote: > >

Re: [Acme] Allow get for certificates?

> The narrow fix -- Remove "orders." No one implements it, and this is the > least disruptive option to a mature spec. I support this narrow fix. On Mon, Oct 8, 2018 at 3:25 PM Jacob Hoffman-Andrews wrote: > The POST-as-GET mess started because Adam Roach pointed out that the > "orders" URL

Re: [Acme] Backing-out capability URLs from the spec (added in #445)

I'm strongly in favour of Jacob's suggestions in 459. On Fri, Oct 5, 2018 at 7:17 PM Jacob Hoffman-Andrews wrote: > Here's my proposal that removes the STAR special-casing in ACME, making > certificate URLs behave the same way as all other fetchable resources: >

Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

Here's another PR with further feedback: https://github.com/ietf-wg-acme/acme/pull/453 Replies in-line below. > Perhaps dropping the "to clients" would remove the reading that > there is nonce/client tracking without losing any significant information, > but this seems to fall under editorial

Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

> My co-author Daniel McCarney is working on the COMMENT comments. I've addressed most of the "COMMENT" feedback in the following PR: https://github.com/ietf-wg-acme/acme/pull/451 Further replies inline below. As a note, I'm a bit starved for time. Because I don't have a usecas

Re: [Acme] POST-as-GET payload contents

> > AFAIK, every JSON library out there marshalls {} as "{}", with no > whitespace, and every JOSE library signs whatever string you give it. I agree, I don't think the {} body will be an implementation challenge. We can say that with some confidence because the existing draft already includes a

Re: [Acme] POST-as-GET payload contents

#1 sounds OK to me On Wed, Sep 5, 2018 at 11:33 AM, Richard Barnes wrote: > I'm tempted to say that the "" / null ambiguity is an interop problem for > JOSE, not for us. But nonetheless, it's a problem. > > I'm still uncomfortable with {}, though, because it risks colliding with > other POST

Re: [Acme] ACME breaking change: Most GETs become POSTs

> How does using POST address this? Please read the draft. We're talking about POSTs authenticated with JWS not vanilla HTTP POSTs. On Fri, Aug 31, 2018 at 3:34 PM, Nico Williams wrote: > On Thu, Aug 30, 2018 at 04:20:41PM -0700, Jacob Hoffman-Andrews wrote: > > ACME currently has

Re: [Acme] ACME breaking change: Most GETs become POSTs

> > In short, I think certificates should be POST-as-GET just like the other > resources. +1. If we're replacing the GETs to Orders, Authorizations and Challenges there's no sense in excluding Certificates. I prefer the uniformity over exceptions for use-cases that don't have strong real-world

Re: [Acme] ACME breaking change: Most GETs become POSTs

214446189 [1] https://github.com/ietf-wg-acme/acme/pull/445#issuecomment-417505743 On Fri, Aug 31, 2018 at 2:56 PM, Daniel McCarney wrote: > I think its an anti-pattern to standardize protocol features that haven't > been implemented by anyone so here's a PR[0] for the Pebble ACME server

Re: [Acme] ACME breaking change: Most GETs become POSTs

I think its an anti-pattern to standardize protocol features that haven't been implemented by anyone so here's a PR[0] for the Pebble ACME server that implements Richard's proposal[1] to establish viability. The proposal seems OK to me given the trade-offs/alternatives on the table. I would

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

> > > I think SHOULD basically makes redirects non interoperable. I think a > bit more text explaining why SHOULD or change this to MUST. Also, if there > are some security issues related to redirects, adding a pointer here would > be good. > I'm slightly adverse to changing this to a MUST.

Re: [Acme] Need doc shepherds

Hi Rich, I would be willing to be the document shepard for draft-ietf-acme-tls-alpn-03 and draft-ietf-acme-ip-04. Please let me know if someone else has already stepped up, if not I will prepare the writeup over this coming week. Thanks! On Wed, Aug 15, 2018 at 11:31 AM, Salz, Rich <

Re: [Acme] optional MIME parameter for application/pem-certificate-chain

My feelings are similar to Richard's. There are probably some niche usecases for this feature that merit thought but I think it would benefit from larger design discussion. Given that we're very close to finishing the base specification and there hasn't been significant demand for this to date I

Re: [Acme] Last Call: (Automatic Certificate Management Environment (ACME)) to Proposed Standard

Thanks for the review/PRs Sean. I left a +1 for PR 433. Richard: can that be merged? I left some feedback on PR 432 and a question on issue 435. On Wed, Aug 8, 2018 at 11:42 PM, Sean Turner wrote: > Okay two PRs: > > https://github.com/ietf-wg-acme/acme/pull/432 >

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

ternet-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

Re: [Acme] Draft authors -- please send a status

I can volunteer for being the ACME-CAA document shepherd but would appreciate some off-list guidance on the requirements. On Wed, Jun 27, 2018 at 2:31 PM, Salz, Rich < rsalz=40akamai@dmarc.ietf.org> wrote: > Is anyone interested in being the document shepherd for the CAA draft? > > > > > >

Re: [Acme] AD Review: draft-ietf-acme-acme-12

> > We have multiple CA’s that support it, and other implementations as well. Of the multiple CAs that support ACME, which support something resembling the current draft? When I looked last the non-Let's Encrypt ACME server implementations all seemed to be targeting Certbot and the "ACMEv1" era

[Acme] Let's Encrypt ACME-CAA validation-methods support

Hi folks, I'm happy to share that Let's Encrypt has deployed support for Hugo Landau's ACME-CAA "validation-methods" CAA record extension in the staging environment[0]. Community feedback/review would be most appreciated. You can find more information in the associated API announcement[1].

[Acme] don't assume sort order of "authorizations", "identifiers" and "challenges" in responses.

There has been some confusion[0][1] around the relationship between the "identifiers" and "authorizations" arrays in an order object. Because one particular ACME implementation[2] returns an authorization for each identifier in an order some developers made assumptions about the order of the

Re: [Acme] Comments on ACME draft

I think #420 is a good addition and is worth merging once Martin Thomson's review feedback is addressed. Thanks Richard, Tim. On Wed, Apr 11, 2018 at 6:04 PM, Jacob Hoffman-Andrews wrote: > I agree, these seem worth merging. > > On 04/11/2018 01:56 PM, Richard Barnes wrote: > >

Re: [Acme] Reminder: Orders List

Hi Sophie, > Shouldn't the orders list objects be protected in the same way as the account > objects? I don't think so. Authorizations objects also contain domain names and are retrievable by GET. Why shouldn't an order be the same way? Are you also proposing that authorizations should be

Re: [Acme] Question about finalizing an order

ne to read an “old” > version of the draft. > > Thanks > > Yoav > > > On 26 Mar 2018, at 17:52, Daniel McCarney <c...@letsencrypt.org> wrote: > > PR #417 was merged. This should be resolved now. > > Thanks again! > > - Daniel / cpu > > On Fri, Mar 23, 2

Re: [Acme] Question about finalizing an order

PR #417 was merged. This should be resolved now. Thanks again! - Daniel / cpu On Fri, Mar 23, 2018 at 10:43 AM, Daniel McCarney <c...@letsencrypt.org> wrote: > Hi Ning, > > It seems that the second statement makes more sense, by changing the >> “pending” into “ready” i

Re: [Acme] Question about finalizing an order

Hi Ning, It seems that the second statement makes more sense, by changing the > “pending” into “ready” in the first statement. Agreed, this was an oversight in https://github.com/ietf-wg-acme/acme/commit/5da11f713e808bd5c8a707dc67754f5ca37b120e .. I opened a pull request to implement this fix

Re: [Acme] Question about the "expired" status

Merged & resolved. Thanks again, On Wed, Mar 21, 2018 at 2:26 PM, Daniel McCarney <c...@letsencrypt.org> wrote: > Hi again Ning, > > I opened https://github.com/ietf-wg-acme/acme/pull/416 just now to > resolve these. Since this is strictly editorial it should be poss

Re: [Acme] Question about the "expired" status

Hi again Ning, I opened https://github.com/ietf-wg-acme/acme/pull/416 just now to resolve these. Since this is strictly editorial it should be possible to merge by EOD. In the future it would save some time if you were able to provide PRs to address these small changes yourself :-) Thanks! -

Re: [Acme] Questions about Account Objects in draft-ietf-acme-acme-10

Hi Ning, Thanks for the questions. I appreciate you bringing up these inconsistencies. Section 7.1.2 indicates that the “orders” field is a required field. > However, the response example in Section 7.3 does not have the “orders” > field. I am wondering if the “orders” field would be optional

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

Re: [Acme] Optional "Wildcard" authorization field

est of getting the spec > shipped, I would propose we just add the boolean flag and write an > extension spec if a more general solution is needed. > > --Richard > > > On Fri, Mar 2, 2018 at 4:58 PM, Daniel McCarney <c...@letsencrypt.org> > wrote: > >> This

Re: [Acme] Optional "Wildcard" authorization field

le. Your proposal is more robust but also a bigger change and I'd like to know someone in the real world will benefit from the work involved :-) - Daniel / cpu On Fri, Mar 2, 2018 at 3:46 PM, Sophie Herold <sophie_her...@hemio.de> wrote: > On 02/03/18 18:32, Daniel McCarney wrote: &g

Re: [Acme] Optional "Wildcard" authorization field

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 <c...@letsencrypt.org> > wrote: > >> Hi folks, >> >> There is a slight disconnect w

[Acme] Optional "Wildcard" authorization field

Hi folks, There is a slight disconnect with the current specification between identifiers in newOrder/newAuthz requests and identifiers in authorization objects. The former is allowed to include wildcard domains in the value of DNS type identifiers while the latter is forbidden. Let's Encrypt's

Re: [Acme] -09 draft: Challenge objects?

Hi Felipe, Does this PR from Richard Barnes address your feedback? https://github.com/ietf-wg-acme/acme/pull/399 Thanks! On Sat, Jan 13, 2018 at 8:50 AM, Felipe Gasper wrote: > Hello, > > I’ve been looking over the -09 draft and have created a Perl > client

Re: [Acme] Challenge objects are provoking implementation mistakes

standard. > > fulfilling a challenge: > e.g. client provisioning a TXT record > > responding to a challenge: > posting to the challenge url (the server can try validation now) > > Best, > Sophie > > On 02/01/18 20:51, Daniel McCarney wrote: > > Thanks for th

Re: [Acme] ALPN based TLS challenge

+1 The WG should adopt this document. I will volunteer to help review if adopted. On Mon, Feb 26, 2018 at 12:02 PM, Richard Barnes wrote: > +1 > > This approach is a major improvement from earlier efforts at a TLS-based > challenge. It follows normal TLS processing logic much

Re: [Acme] Removing TLS-SNI-02, plans for continuation of last-call

Only positive responses were noted and the discussion period Rich mentioned has passed so I've merged https://github.com/ietf-wg-acme/acme/pull/390 Thanks all, - Daniel / cpu On Fri, Jan 12, 2018 at 1:29 PM, Daniel McCarney <c...@letsencrypt.org> wrote: > This removes the "tl

Re: [Acme] Challenge "errors" -> "error"

There hasn't been any dissent on-list about this proposal. I'm going to merge the PR. Thanks all! On Fri, Jan 12, 2018 at 11:32 AM, Daniel McCarney <c...@letsencrypt.org> wrote: > +1 - I'm in favour of this change as well. > > On Thu, Jan 11, 2018 at 7:24 PM, Jonathan R

Re: [Acme] Fixing the TLS-SNI challenge type

challenge response certificate. I would be happy to be corrected :-) On Fri, Jan 19, 2018 at 9:43 AM, Daniel McCarney <c...@letsencrypt.org> wrote: > If we use the "real" identifier for SNI, we'd limit that option to web >> servers that natively support the ALPN val

Re: [Acme] Fixing the TLS-SNI challenge type

> > If we use the "real" identifier for SNI, we'd limit that option to web > servers that natively support the ALPN value for ACME and can route based > on it. > Not sure how common this kind of setup is, if it's just a small subset of > HAProxy deployments it'd probably not have much of an

Re: [Acme] Removing TLS-SNI-02, plans for continuation of last-call

/acme/pull/390/commits/3441d4435a6e8454fa68749231d801ec4f894bbc Thanks Ilari, - Daniel / cpu On Fri, Jan 12, 2018 at 1:23 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Fri, Jan 12, 2018 at 12:45:55PM -0500, Daniel McCarney wrote: > > Hello folks, > > > > As I'm sure many of you are awar

[Acme] Removing TLS-SNI-02, plans for continuation of last-call

Hello folks, As I'm sure many of you are aware by now, recent developments[0] [1] [2] have identified real-world server/hosting configurations that violate the assumptions of TLS-SNI-01 as well as its currently specified replacement, TLS-SNI-02. In light of these issues and the feasibility of

Re: [Acme] Challenge "errors" -> "error"

+1 - I'm in favour of this change as well. On Thu, Jan 11, 2018 at 7:24 PM, Jonathan Rudenberg wrote: > > > On Jan 8, 2018, at 13:37, Jacob Hoffman-Andrews wrote: > > > > In the course of testing Let's Encrypt's ACME v2 endpoint, we realized > > that the

Re: [Acme] Clarify that newAuthz endpoint is optional

, Richard Barnes <r...@ipv.sx> wrote: > 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 <c...@letsencrypt.org> >

Re: [Acme] Clarify that newAuthz endpoint is optional

the presence of that field an indicator of pre-authorization support (or lack thereof). I'll update to a SHOULD in my PR since I agree that maps better. Thanks! On Fri, Jan 5, 2018 at 2:27 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Fri, Jan 05, 2018 at 02:05:22PM -0500,

[Acme] Let's Encrypt draft-09 test endpoint

The list may be interested to know Let's Encrypt has made a test environment available based on ACME draft-09. The announcement post with more details is available here: https://community.letsencrypt.org/t/staging-endpoint-for-acme-v2/49605 Compatible clients can be configured with the

[Acme] Clarify that newAuthz endpoint is optional

In Section 7.4.1 "Pre-Authorization" the spec says: If a CA wishes to allow pre-authorization within ACME, it can offer > a "new authorization" resource in its directory by adding the field > "newAuthz" with a URL for the new authorization resource. That text indicates that the CA may wish

Re: [Acme] YA WGLC for draft-ietf-acme-acme

te: > I meant the one titled “Challenge objects are provoking implementation > mistakes” > > If there are other threads that are still open, then obviously let’s get > them closed before submitting the next draft. > > > On 2 Jan 2018, at 21:52, Daniel McCarney <c...@letsencr

Re: [Acme] YA WGLC for draft-ietf-acme-acme

gt; > *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 WG of the IETF. > >Title : Automatic Certifica

Re: [Acme] Removing OOB Challenge Type

Happy Friday folks ;-) Can we move forward with removing the OOB challenge? It seems like there is rough consensus: Clint, Jacob, Andrew and myself all vote for removal. Robert posed one use-case that he thought required OOB challenges but doesn't, and one use-case where they have plans for the

Re: [Acme] new-authz, new-order and examples

Hi Sophie, i noted that the examples in "7.4. Applying for Certificate Issuance" are > still using CSRs. Good catch! I'll submit a PR to address this oversight this afternoon. > Further, I didn't found explicit coverage of the case that there is a valid > authorization (say via new-authz) at

Re: [Acme] Removing OOB Challenge Type

> > That’s not right. Deployments rarely occur right as the draft is finished. What isn't right? I expressed an opinion that entering last call for specification text that hasn't been implemented by anyone seems like a recipe for errata. My comment was also specific to implementations not

Re: [Acme] Removing OOB Challenge Type

> Daniel, please do not merge this until we determine WG consensus Of course :-) I don't have any merge privileges! On Thu, Nov 30, 2017 at 11:42 AM, Salz, Rich wrote: > Does anyone disagree with Daniel’s reasoning? If so, please speak up > before next Friday. > > > >

[Acme] Removing OOB Challenge Type

Hi folks, In a previous thread[0] surveying ACME implementations two commercial CAs (BuyPass and DigiCert) outlined that their ACME integrations use external account binding but **not** the Out-of-Band (OOB) challenge type. As Clint from DigiCert points out[1] having a binding with an external

Re: [Acme] Landing PR#342 (proactive issuance with identifier-first)

onfirming could accommodate #342 without needing a CSR in new-order. I hope Andrew can clarify if I'm remembering incorrectly. On Tue, Nov 28, 2017 at 1:23 PM, Richard Barnes <r...@ipv.sx> wrote: > > > On Tue, Nov 28, 2017 at 1:19 PM, Daniel McCarney <c...@letsencrypt.org>

Re: [Acme] Landing PR#342 (proactive issuance with identifier-first)

> > I filed Issue #356 [1] to track the lost functionality here, and how we > might want to add it back. >From #356: " In making that change, we dropped support for certain legacy back-end > APIs that require a CSR before issuing challenges" Which legacy back-end APIs are you referring to? I

Re: [Acme] Allowable "tel" contacts; publishing allowed contact schemes and their ACME-specific restrictions

I would be supportive of removing non-mailto contact examples. I don't think it's accurate to say that "mailto" is the only contact scheme currently supported by the ACME standard. That isn't the case for the spec as-written today - it is the only mandatory contact scheme. I believe its been left

Re: [Acme] Returning multiple errors

I think this is a solid proposal addressing a real need. I'm +1 for supporting it both in spec and in Boulder/Pebble. Thanks Jacob, On Wed, Nov 15, 2017 at 8:23 PM, Jacob Hoffman-Andrews wrote: > In previous versions of ACME, there was sometimes a need to return > multiple

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

authorizationFirst (https://github.com/ietf-wg-acme/acme/pull/350) > > Personally, my current preference is for (3), because it seems like the > least complex / error prone way to support both back-end cases (CSR first / > CSR last). > > Thanks, > --Richard > >

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

uamQ4SPkxHR_eschpBSqkG1-yE On Thu, Nov 2, 2017 at 12:18 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Thu, Nov 02, 2017 at 10:29:58AM -0400, Daniel McCarney wrote: > > > > > I understand that these corner cases aren't a super convincing line of > > arg

Re: [Acme] Survey of draft-07 implementations

ng to our current plan this will be completed in Q4 2017. We > hope to begin the implementation in Q1 2018, but right now I am not able to > say when this will be finished. > > > > Regards > > Mads > > > > *From:* Daniel McCarney [mailto:c...@letsencrypt.org

Re: [Acme] Missing rationale for the Authorization "scope" field

that that authorization wouldn't > be reused. > > Given that all issuance now goes through new-order, it's probably safe to > remove this. If the client guesses wrong about what authz it needs, the > server can tell it what else it needs to do. > > --Richard > >

[Acme] Missing rationale for the Authorization "scope" field

Section 7.1.4 "Authorization Objects" describes an optional "scope" field. If present it must be a URI pointing to an order and the authorization is considered to be valid only for that order. If no scope value is present it is assumed that the authorization is valid for any order. Looking back

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

, Nov 2, 2017 at 10:15 AM, Richard Barnes <r...@ipv.sx> wrote: > > > On Thu, Nov 2, 2017 at 9:51 AM, Daniel McCarney <c...@letsencrypt.org> > wrote: > >> This was mentioned in another thread on this topic, but to provide a >>> concrete example of where thi

Re: [Acme] Survey of draft-07 implementations

ernal Account Binding in a next phase >> where the idea is to exploit how the ACME protocol may be used to support >> issuance and administration of other types of TLS certificates than DV. >> >> >> >> Regards >> >> Mads >> >> >> &g

Re: [Acme] Survey of draft-07 implementations

y be used to support > issuance and administration of other types of TLS certificates than DV. > > > > Regards > > Mads > > > > *From:* Acme [mailto:acme-boun...@ietf.org] *On Behalf Of *Daniel McCarney > *Sent:* fredag 20. oktober 2017 22:36 > *To:* IETF

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

On the one hand, sending a CSR twice seems clumsy (as Hugo notes above) > and it makes the server parse the CSR twice. On the other hand, using a > CSR both times makes the client logic a bit simpler since you just send the > same thing in both requests. > > Anyone else have thought

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

/ cpu On Mon, Oct 30, 2017 at 3:33 PM, Richard Barnes <r...@ipv.sx> wrote: > > > On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney <c...@letsencrypt.org> > wrote: > >> > Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key). >> Implementing

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

> 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 the order finalization message based on a CAA-PKP property. In-fact, we

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

Hi Hugo, Providing the CSR up-front allows the CA to predicate order processing on > aspects of that CSR, both with regard to the present protocol and any > future extensions, both now and in the future in ways that we can and > cannot foresee. I don't think it's appropriate to defer giving

[Acme] Survey of draft-07 implementations

Hi folks, As the WG approaches last-call on ACME draft-07[0] I wanted to get a sense of which portions of the spec have been implemented and which haven't. In particular I'd like to hear if anyone has implemented: * External Account Binding (Section 7.3.5) * Pre-Authorization for Order based

Re: [Acme] AD review of draft-ietf-acme-acme

> > > Is there any chance we'll get through this review so I can start last > call this week? I think it is premature to start last-call. There are *no* full implementations of the current draft (as far as I am aware) and experience from attempting a complete implementation has highlighted a

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

Hi again, Richard: Do you have any subsequent thoughts now that Roland and myself have given feedback on your proposed changes and why we still prefer the suggestions I made initially? Andrew's original support of proactive issuance was the most constructive vote for why that behaviour was

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

fetch ~ > > new-authz) -- or rather, one fewer in the new-authz case because > > there's no new-cert request. To what degree would your problem be > > solved simply by having the affected integrators move over to that > flow? > > > > I can sympathize that the

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

ew-authz case because there's no new-cert request. To >> what degree would your problem be solved simply by having the affected >> integrators move over to that flow? >> >> I can sympathize that the new-order flow might not be suitable for all >> use cases. Maybe it wo

[Acme] Revisiting Proactive Issuance & new-order CSR

Hi folks, Just over a year ago in a thread titled "Proactive vs On-Finalization Certificate Issuance"[0] we reached the consensus on the question of whether to issue a certificate "on-finalization" or "proactively" with the conclusion to standardize on proactive issuance. Implementation

Re: [Acme] Minutes from IEtf 99

utes-99-acme > > Kind of underwhelming, I know. > > Rich: Are we planning on fleshing this out? > > Yoav > > On 24 Aug 2017, at 21:59, Daniel McCarney <c...@letsencrypt.org> wrote: > > The real minutes are what we will upload in a few days or weeks, and they >>

Re: [Acme] Minutes from IEtf 99

; > > It should be noted that Richard’s notes are just an aid to the chairs > (that's Rich and me now that Ted is moving on) > > > > The real minutes are what we will upload in a few days or weeks, and they > are usually in plaintext form. > > > > Sent from my Windows 10

[Acme] Send "Location" header in key-rollover conflict response.

Hi folks, In 7.3.1 "Finding an Account URL Given a Key" the server returns a "Location" header populated with the account URL of the account associated with a given account key. In 7.3.6 "Account Key Roll-over", there is a similar condition in which the new key specified as part of a rollover

Re: [Acme] Minutes from IEtf 99

e now that Ted is moving on) > > > > The real minutes are what we will upload in a few days or weeks, and they > are usually in plaintext form. > > > > Sent from my Windows 10 phone > > > > *From: *Daniel McCarney <c...@letsencrypt.org> > *Sent: *Friday, July 21

Re: [Acme] Minutes from IEtf 99

Hi Richard, Thank you! No need to apologize. On Fri, Jul 21, 2017 at 9:38 AM, Richard Barnes <r...@ipv.sx> wrote: > Of course you're right. I apologize. I will go through the audio > recording and produce some proper notes. > > On Jul 21, 2017 3:32 PM, "Daniel McCarney

Re: [Acme] Minutes from IEtf 99

I think this is the second time (in my memory) the WG notes have been distributed in "meme form". At the risk of being the stick in the mud I want to express an opinion that "meme notes" are distracting and I think the time spent producing the memes would have been better spent capturing the

Re: [Acme] Automated procedure for DNS challenge records?

I agree with the others that have shared the opinion that this is outside of the scope of ACME and this WG. In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) there > is already a protocol for clients to add/update/delete resource records on > DNS servers. Most DNS server

Re: [Acme] v2

> > Given that Let's Encrypt has evolved their interface some since the first > version, I'm not sure there's one consolidated spec out there for what they > currently have deployed. There isn't AFAIK - the closest thing is the list of "boulder divergences" we maintain along with the

[Acme] "mailto" mandatory to implement

Following up on the draft minutes[0] item for server contact support from the meeting at IETF98: """ - **Advertise server contact support** (slide 19) - Discussion: Ted highlights the risk of failure in negotiation (empty intersection) a single MTI scheme is necessary and sufficient for interop

Re: [Acme] Entropy requirement for challenge token

Updated #284 to clarify the token entropy requirement in the security considerations section. Thanks for the feedback. On Tue, Mar 28, 2017 at 5:30 PM, Daniel McCarney <c...@letsencrypt.org> wrote: > I think Daniel's change at https://github.com/ietf-wg- >> acme/acme/pull/284/

Re: [Acme] Allowing clients to understand the account creation functionality supported by a server

an extension, rather > than in the main spec. > > On Tue, Mar 28, 2017 at 6:04 PM, Daniel McCarney <c...@letsencrypt.org> > wrote: > >> I still think this is the wrong layer to solve this problem. If the crux >> of the matter is that `urn:ietf:params:acme:error:inva

Re: [Acme] Allowing clients to understand the account creation functionality supported by a server

n and become less portable.) > > Providing information about the supported contact schemes in a machine > readable format (e.g., in response to a GET requests on the server's > new-account URI) does add work for ACME server implementors, but not so > much that it's worth complicating the

Re: [Acme] Entropy requirement for challenge token

; Is this accurate? If so, it seems like some version of this explanation > should be included in the Security Considerations section. > > -- > *From:* Daniel McCarney <c...@letsencrypt.org> <c...@letsencrypt.org> > *Sent:* Wednesday, March

Re: [Acme] Use of "shortly" in normative language of Section 7.4, Applying for Certificate Issuance

euing for available capacity > - Manual vetting > > I think "MUST begin" covers for all of those, while allowing some > vagueness as to how long they will take. > > On 03/22/2017 09:39 AM, Daniel McCarney wrote: > > Hi Zach, > > For background I think this M

Re: [Acme] Fwd: Inconsistent abbreviations for resource names

Oops! RFC editing is not thread safe and Jacob and I have encountered a data race. One of our PRs can be closed. I'm not particular about which :-) On Wed, Mar 22, 2017 at 1:01 PM, Jacob Hoffman-Andrews wrote: > Hi Niklas, > > Sorry for the delay in getting back to you. > > On

  1   2   >