Re: [Acme] Considerations about ACME BoF

Thanks for your detailed note. I want to make sure we have started to address your issues. Stephen responded to the procedural ones, and from your reply it appeared to me that you are, basically, satisfied. Let me talk to the technical points you raise. Reinventing the wheel. Many parties

Re: [Acme] Considerations about ACME BoF

b) Getting a server certificate for a cloud server within seconds, and with no manual intervention is possible today with a little scripting on the server and an appropriate API from one of the existing CAs. If your current provider cannot do that for you, then I suggest you shop around a

Re: [Acme] Want client-defined callback port

I understand that you want it to “just work” (you said that a couple of times :), but other folks have raised security concerns – do you understand or agree with them? One way forward is to say a client MAY specific a port, where the default is 443. An ACME server MAY reject requests for ports

Re: [Acme] Current Charter language

Any other obvious edits needed? LGTM -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] WG meeting at IETF 93

http://tools.ietf.org/html/draft-jones-jose-jws-signing-input-options-00 The WG should spend some time on this; it's on the agenda. For the benefit of the list, I asked Mike off-line if he could attend the WG meeting. ___ Acme mailing list

[Acme] Supporting off-line (manual) validation

Suppose we add a new challenge offline/ where / is an IANA registry (first-come first-served). The ACME client then stops doing online protocol, communicates with its human who does the appropriate credential validation with the CA. Ultimately (hours, days, weeks, months later), the

Re: [Acme] New draft and DANGER

> Please review the PR as soon as possible and provide comments to the > list. Other issues or text suggestions for the draft are, of course, also > welcome. It can be useful to open an issue on the GH repo, so that things don't get lost. But please everyone, avoid the temptation to have all

Re: [Acme] Issuing certificates based on Simple HTTP challenges

> The target users are server admins right? > In order to set up their services, they should be familiar with DNS. Nope, not a requirement. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] The path to the "directory" resource should not be "/" and should be specified in draft-ietf-acme-acme-01

> draft-ietf-acme-acme-01 states: > > In order to help clients configure themselves with the right > URIs for each ACME operation, ACME servers provide a directory > object. This should be the root URL with which clients are > configured. > > The question is, what

Re: [Acme] Content-Type and file extensions for HTTP01 challenges

Ø Might not that bad as long as CAs offer both versions. But we have other pending changes? because of insecure? DVSNI challenges. They should maybe coordinated and updated at once. This is an RFC-in-progress. We’re likely to settle on one version of each type.

[Acme] New issue: Clarify how to handle bad requests

Please see https://github.com/ietf-wg-acme/acme/issues/47 for background, but discuss it here on the mailing list. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Revoking certificates issued by an unknown ACME server

> This isn't sanely automatable. > > It's unlikely that this will pose an issue if a human wants to figure out the > issuing server. But as things stand to automate things you'd need to maintain > a database of CAs to directory URLs. I don't see a problem with that. You've got a cert, you can

Re: [Acme] Proposed changes to TLS-SNI, autorenewal removal

> Agreed, but that doesn't mean the ACME server has to check for such a SAN. Agreed. > So I say keep the client-side part of the spec the same, but change item > three of the server-side part to say: > > "Verify that the certificate contains a subjectAltName extension containing a > dNSName

[Acme] draft agenda posted

https://datatracker.ietf.org/meeting/95/agenda/acme/ We know what Phill's topic is, we just don't have a pithy headline for it yet :) LURK and ACME consolidation, perhaps? Our revised schedule called for us to have WGLC this month. We're obviously slipping that, but let's see what we need to

Re: [Acme] Paging for authorizations and certificates lists

> For arrays, yes. It follows the pattern established with Atom, but it's > fairly > widely used. You put N things in the response, then provide a rel=next link > for the next part. Thanks. ___ Acme mailing list Acme@ietf.org

Re: [Acme] Paging for authorizations and certificates lists

Are there common and well-specified semantics for merging "paged" JSON objects? Is his necessary? The serve can just stream it out and any client who is asking for this huge name must be willing to generate it, too. Or is that wrong? ___ Acme

Re: [Acme] Account deletion for security currently useless if rolled over

> What is a PR? :) Assuming the question is serious, take a look at this tutorial: https://yangsu.github.io/pull-request-tutorial/ Alternatively, post a diff to the list with the changes you'd like to see. ___ Acme mailing list Acme@ietf.org

Re: [Acme] Account deletion for security currently useless if rolled over

It’s not stupid ? Understand the terms used (such as PR in this WG:) can be among the hardest parts. > Will make a draft... Great, looking forward to it! -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ Acme

Re: [Acme] Account deactivation

> Let me explain a bit more: Shall a CA receive a valid and trustworthy request > for deletion of an account/authorization, the CA must totally erase any trace > of data regarding that account Speaking as a WG chair, I disagree. EU data retention, like US Calea laws, are outside the scope of

[Acme] Minutes please

If you took minutes at the ACME WG meeting, please post them here for folks to review and correct. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ Acme mailing list Acme@ietf.org

Re: [Acme] CAA Account Key Binding Draft Specification

> Alright, here's the first draft. > > https://hlandau.github.io/draft-landau-acme-caa/ Can others in the WG read this and make a suggestion as to yes/no adopt? It's short (and the first para of 3.1 is a "did you read this" sentence fragment test? :) Thanks!

Re: [Acme] Short term certificates - two options

> i have to ask how/why would you be sending the user to said cdn supplier > (via dns) in the first place for them to see said expired cert (plus warnings > if > client gives them) DNS caching. ___ Acme mailing list Acme@ietf.org

Re: [Acme] Short term certificates - two options

> What happens to your content *after* you've changed your CDN is *not* a >problem you can fix with certificates. Gee, I thought I showed otherwise. If the certificate expires, the browsers will ignore it. Ok? ___ Acme mailing list Acme@ietf.org

Re: [Acme] Minutes and verifying some decisions

Since we’re keeping the nonces, yes just close the issue. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

[Acme] Minutes and verifying some decisions

I've posted the minutes here: https://www.ietf.org/proceedings/96/minutes/minutes-96-acme Please review them. At the meeting, we came to consensus on several items, summarized here: * support both old and new 'applications' flow * Add version into protected payload * For issue 157, decided to

Re: [Acme] Support issuing certificates to subdomains when top level domain-ownership can be verified

> My request for the ACME would be: If I can prove I own the top level domain, > I should also be allowed to issue certs for any subdomain without need for > verification of those. Speaking as an individual, not co-chair. As a counter-example, if I own wordpress.net should I be able to get a

Re: [Acme] Fw: About the ACME Protocol

I stripped most of your message out, trying to leave only the questions that I think still need replies. But please feel free to continue this conversation. > Regarding the on-going development of the spec: I was thinking more about the > individual commits on github and less about the IETF

Re: [Acme] Short term certificates - two options

> >I think this could work, but I believe there are use cases > >(specifically, CDNs) where people do not want to advertise the delegation. > > I favor solutions where the relying party can be aware of the delegation if > they want to be. FWIW, in the CDN case origin sites generally *do not*

Re: [Acme] Preconditions

Speaking as an individual, not a chair, this seems like the right trade-off (a bit of complexity for way more generality) to make. I am in favor. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Preconditions

> I really think it's cleaner at this point to change the model.  There's not > that much deployed code yet, so we should go ahead and get things right. Not as chair: strongly agree. ___ Acme mailing list Acme@ietf.org

Re: [Acme] Preconditions

> There are dozens of projects that will need to rework their code if we > restructure the protocol, including most of these and probably a lot that > aren't listed: > > https://letsencrypt.org/docs/client-options/ That's the LetsEncrypt protocol, not the IETF ACME protocol. We're not here to

Re: [Acme] Pre-authorization approach

> ACME describes possible validation methods but does not tell any CA what > they _must_ use. I think it is valid, under the current draft, for a CA to > only > support out-of-band methods, right? This is correct. "Mechanism not policy" to bring back an old phrase :)

Re: [Acme] Short term certificates - two options

Browsers check validity time. They do not look for CRL's; they sometimes look for OCSP status. "I want to get my content off a CDN" is a valid use-case. Sometimes it's not a CDN breach, sometimes it's a business decision. I don't want to erase my content, I want to rotate it across multiple

Re: [Acme] Editorial fixes in GitHub

WG members. We'd like to get into last call very soon. Please look at the issues that Jacob lists below and post commentary here. > Remove SCT link relation. https://github.com/ietf-wg-acme/acme/pull/234 > Specify multi-viewpoint validation. > https://github.com/ietf-wg-acme/acme/pull/239 >

Re: [Acme] ACME draft is now in WGLC.

> PLEASE reply on list if you will review and/or are interested in working on > interop. Looking for last-minute Valentine's Day plans? (https://en.wikipedia.org/wiki/Valentine's_Day among others). What could be more romantic than an evening spent with your loved one reading the ACME WGLC

[Acme] Recent pull requests

Authors, Please resolve/merge 231 and 232 and publish a new draft - those are truly strictly editorial. We'll treat 234 and 235 as WGLC comments. If you want to pull some of the changes in 235 out into a separate PR that (a) has agreement between you, and (b) *is* strictly editorial, feel

Re: [Acme] Well Known URI review

> I began the request/review process yesterday if anyone else is interested > (although it looks like it may have already been approved): > https://www.ietf.org/mail-archive/web/wellknown-uri- > review/current/msg00152.html Yes, the designated expert approved it (shady character mnot) and it

Re: [Acme] Terms of service agreement changes

Okay, then. We'll see if we can get consensus during early September. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz > -Original Message- > From: Jacob Hoffman-Andrews [mailto:j...@eff.org] > Sent: Monday, August 29, 2016 2:36 PM > To

[Acme] FW: NomCom 2016-2017: Call for Nominations

In particular, Stephen isn't re-upping, so there's an opening in the Security Area. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz -Original Message- From: NomCom Chair 2016 [mailto:nomcom-chair-2...@ietf.org] Sent: Monday, August 29, 2016 4:37 PM

Re: [Acme] Terms of service agreement changes

Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz From: Richard Barnes [mailto:r...@ipv.sx] Sent: Thursday, September 08, 2016 1:06 PM To: Salz, Rich Cc: Jacob Hoffman-Andrews; acme@ietf.org Subject: Re: [Acme] Terms of service agreement changes So, it's early September... ? On Mon, Aug 29, 201

Re: [Acme] Pre-authorization approach

If anyone objects to this, and there is ensuing discussion on the WG mail list, we’ll work to resolve it. Otherwise, “silence implies agreement” and we’ll declare consensus next Tuesday. Thanks. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz From: Richard

Re: [Acme] Support issuing certificates to subdomains when top level domain-ownership can be verified

> Sorry for bothering you all, with what in retrospect seems to have been a > tech-support like issue. Speaking as co-chair: not at all. If we all had to be experts before doing anything, we'd do nothing. :) /r$ -- Senior Architect, Akamai Technologies IM: richs...@jabber.at

Re: [Acme] Pre-authorization approach

As co-chair: Let’s think about this over the weekend and – if you have something new, please post early next week. Perhaps review the mailing list archives before posting. Then we’ll try to determine consensus at the end of the week. -- Senior Architect, Akamai Technologies IM:

[Acme] CAA draft is accepted by the WG

Hugo will be posting a new draft, and moving the repo to our github project shortly. There was no discussion, and I want to get this submitted before the cutoff for the IETF meeting in two weeks. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richs...@jabber.at Twitter:

[Acme] IETF-97 Agenda

Here's the current agenda draft for IETF-97. Please reply to the list if you want any changes. -- Rich and Ted. ACME at IETF-97 Wed Nov 16, 2016 at 13:30-15:00 5 min Administrivia 50 min Open Issues on ACME I-D Including "ready for last call" 15 min Short-term

Re: [Acme] Nonces and replay attacks

> but a nonce is a number which should only be used once, and since it's > generated at random The first part is right, the second part is not strictly correct. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

[Acme] Draft minutes posted

https://www.ietf.org/proceedings/97/minutes/minutes-97-acme-00.html Please send comment by end of month; deadline for corrections is January 9. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richs...@jabber.at Twitter: RichSalz

[Acme] Looking for comments on https://github.com/ietf-wg-acme/acme/issues/215

With the couple of recent pull requests, the document editors are about to close all but on issue, #215. Does the WG have any feelings on this? Is it something we need to address NOW, or can we add a new type of challenge later on if there's interest? Please reply on-list by earl next week.

[Acme] FW: [ietf-wg-acme/acme] Add CAA text (per IETF98) (#290)

: Salz, Rich; Your activity Subject: [ietf-wg-acme/acme] Add CAA text (per IETF98) (#290) You can view, comment on, or merge this pull request online at: https://github.com/ietf-wg-acme/acme/pull/290<https://urldefense.proofpoint.com/v2/url?u=ht

Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2

Speaking as an individual, I think returning the certlist in the response will lead to careless clients than can *only* handle synchronous cert creation. This strikes me as a premature optimization. ___ Acme mailing list Acme@ietf.org

Re: [Acme] ACME draft is now in WGLC.

> Rumour has it that CAA will soon be a requirement It just passed their balloting so CA/B forum now requires it. See the LAMPS WG thread(s) on CAA erratum 4515. > The CAA check is/was easy to make and crippling it > by not making it a requirement was IMNSHO a mistake. ... > I urge the WG to

Re: [Acme] ACME draft is now in WGLC -- require CAA ?

> I'd agree that the CAA check should be made mandatory. At least, I can't > think of any good reason why it shouldn't be. Have you seen the thread on the LAMPS (SPASM) mailing list, titled "CAA Erratum 4515"? That raises some technical issues, which make me (as an individual at least) think

[Acme] Confirming consensus

At the IETF last week we had unanimous consensus to change the CAA draft so that it used the term "validation-methods" and not "acme-methods" Does anyone disagree? Please speak up in the next couple of days if you do not agree. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev

Re: [Acme] Friday's meeting

> We need a Jabber scribe and a note taker.  Please volunteer. There will be gifts. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Consensus -- CAA draft to WGLC?

> https://github.com/ietf-wg-acme/acme/pull/332 I like this. I proposed one minor wording clarification. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

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

> The biggest concern I have is the text regarding certificate lifetime and the > handling of the possibility that IP addresses are dynamically allocated. This > seems a little weak and it leaves a lot to the CA to manage. Is there > anything > that can be done to gain a stronger assertion that

[Acme] Minutes from IEtf 99

Please take a look at the minutes/memes and post corrections by the next week. Minute-taker gets to choose if he accepts changed pictures or not ☺ -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richs...@jabber.at Twitter: RichSalz From: Richard Barnes [mailto:r...@ipv.sx]

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

Sean, at the meeting we agreed to do more in this area; look for new content from the editors. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richs...@jabber.at Twitter: RichSalz > -Original Message- > From: Sean Leonard [mailto:dev+i...@seantek.com] > Sent:

Re: [Acme] Minutes from IEtf 99

Twitter: RichSalz From: Richard Barnes [mailto:r...@ipv.sx] Sent: Friday, July 21, 2017 9:39 AM To: Daniel McCarney <c...@letsencrypt.org> Cc: acme@ietf.org; Salz, Rich <rs...@akamai.com> Subject: Re: [Acme] Minutes from IEtf 99 Of course you're right. I apologize. I will go throu

Re: [Acme] Consensus -- CAA draft to WGLC?

Based on feedback here, Hugo just posted an updated draft, https://tools.ietf.org/html/draft-ietf-acme-caa-02 I would like to advance this to the IESG in a week. Please speak up if you disagree. Also, still looking for a document shepherd (see

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

> is there any procedure proposed in the ACME documents to update the > ACME resource records on the primary DNS server (e.g. DynDNS/TSIG RFCs > 2136/2845)? No, there is no DNS-update protocol specified. But what ACME resource records are you thinking of?

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

> For a fully automated validation process the ACME-client needs some kind of > protocol/interface to add/update/remove the DNS challenge records on the > primare DNS server. This is out of scope for our WG, but since we are looking at rechartering, it could be brought within scope. But I think

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

> You think there should be a proprietary plug-in for any combination of DNS- > provider <-> ACME-client? The question is backwards. Does there have to be an open standard for any DNS provider/ACME client? There is an important distinction. ___ Acme

Re: [Acme] Consensus -- CAA draft to WGLC?

So let's see. Can we live with this? Create a spec-required registry for validation method names. Do not reference CABF docs. Change the CA sample names from A B to X Y or foo bar or this that or whatever. ___ Acme mailing list Acme@ietf.org

Re: [Acme] Consensus -- CAA draft to WGLC?

> 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) to change for the CAA draft. ___ Acme mailing list

Re: [Acme] Futures

> I'm not sure that would be a feasible solution: the most obvious reason being > it'd require an extreme charter-stretching exercise. Besides, STAR includes > an extension of ACME, thus the ACME WG looks to me like the obvious place > where to host this work. That's fine. I'm just asking

Re: [Acme] Futures

> So we submitted a draft to define a new challenge type to support the > ATIS/SIP Forum NNI task group (SHAKEN) requirements, which are based on using > protocols defined in STIR: Would it make sense to move this forward in STIR? I ask because

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

>I would rather sidestep the issue of what format to put the certificate >response in, by putting the certificates directly into the JSON ACME order >object. I have not seen any arguments against that premise (except for “size”) >and several arguments in favor of it. The "so-called PEM format"

Re: [Acme] Issuing a cert with a superset of requested identifiers

It's unclear to me whether an ACME CA is allowed to issue a cert with a superset of identifiers that were requested in the order. I see the language: > The server MUST return an error if it cannot fulfill the request as > specified, and MUST NOT issue a certificate with

Re: [Acme] Call for adoption STAR (short-term automatically-renewed) certificates

> 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. The document will be split into the recurring-order/renewal part, and the delegation part.

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

As chair: Thanks for the detailed review. As an individual: I agree we need a new term other than CDN. All the good words are taken, but perhaps Agent works? > draft-iab-web-pki-problems has been abandoned. I didn't notice that. Rats. -- Senior Architect, Akamai Technologies Member,

Re: [Acme] Before entering WGLC ...

> This might be easier to read, though is actually slightly longer: > Where a CAA property has an "account-uri" parameter, a CA MUST NOT > consider that property to authorize issuance in the context of a given > certificate issuance request unless the CA recognises the URI > specified as

Re: [Acme] Before entering WGLC ...

How about this: A CA MAY proceed with issuance if a CAA record is present whose value matches the account-uri parameter of the account making the request. If no CAA records have such a match, then the CA MUST NOT proceed with issuance. ___ Acme

Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token

>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

[Acme] draft minutes from june 2 interim

There were about 20 people present on the call. It lasted about 50 minutes. Would those who were on the call please post corrections here? Thank you. >Hugo's CAA draft (already adopted, short, might be ready for > WGLC) -- https://tools.ietf.org/html/draft-ietf-acme-caa-01

[Acme] Consensus -- CAA draft to WGLC?

>>Hugo's CAA draft (already adopted, short, might be >> ready for WGLC) -- https://tools.ietf.org/html/draft-ietf-acme-caa-01 This has moved to WGLC. If you know of any reason why it should not advance to the IESG, please post by end of next week. If you are willing to be the

[Acme] Adopt two email-related drafts

At the interim, we had strong consensus to adopt Alexsey's draft (was one, is now two) on ACME challenges and certs for email services and users: https://datatracker.ietf.org/doc/draft-melnikov-acme-email-smime/ https://datatracker.ietf.org/doc/draft-melnikov-acme-email-tls/ If you are

[Acme] Call for adoption, ACME challenge for validating IP addresses

At the interim, we briefly discussed this document: https://tools.ietf.org/html/draft-shoemaker-acme-ip-00 Yaron had some questions about use-cases, which Roland replied to on the mailing list. Should we adopt this draft? (Recall that adoption means it's a good starting point, not that

Re: [Acme] draft minutes from june 2 interim

The minutes for the June 2 interim are now available: https://datatracker.ietf.org/doc/minutes-interim-2017-acme-01-201706021100/ The next couple of messages will be to call for various WG adoptions and WGLC. ___ Acme mailing list

[Acme] Call for adoption; (1) ACME challenge for ATIS/SIP (2) identifiers and challenges for telephone numbers

At the interim we had strong consensus to adopt these two drafts as WG documents. I am grouping them in a single email because they are related, and to point out that with both of these we will be collaborating with the STIR WG. If you feel it is not appropriate for us to adopt, please post to

[Acme] Call for adoption STAR (short-term automatically-renewed) certificates

At the June 2 interim, we had consensus to adopt https://datatracker.ietf.org/doc/draft-sheffer-acme-star/ as a WG document, subject to splitting It into two documents, the ACME extension in one, and the delegation protocol in another. This corresponds to #1 and #2 in the abstract of the

Re: [Acme] Before entering WGLC ...

> >    . . .  A CA MUST only consider a property with an "account-uri" > >    parameter to authorize issuance where the URI specified is an URI > >    that the CA recognises as identifying the account making a > >    certificate issuance request. > > > > > This is not a [crisp] MUST statement.  I

[Acme] Before entering WGLC ...

Hugo, the CAA document is in WGLC. Russ raised the following issue on some text in section 2:    . . .  A CA MUST only consider a property with an "account-uri"    parameter to authorize issuance where the URI specified is an URI    that the CA recognises as identifying the account making a    

[Acme] Please submit your I-D as WG documents

Authors, Please submit your drafts as WG documents for adoption, thank you! -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richs...@jabber.at Twitter: RichSalz ___ Acme mailing list Acme@ietf.org

Re: [Acme] Consensus -- CAA draft to WGLC?

> The two last ones are editorial, but the first about enumerating all BR > methods isn't (since it needs new validation method identifiers). Thinking about it a bit more, I don't think it is appropriate for ACME to list CABF things. That's a strong view as an individual, and a moderate view as

Re: [Acme] Consensus -- CAA draft to WGLC?

> Couple of minor comments: These seem like all strictly editorial to me. Anyone disagree? -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richs...@jabber.at Twitter: RichSalz ___ Acme mailing list Acme@ietf.org

Re: [Acme] Before entering WGLC ...

Thank you. For me, it addresses the issue. Russ, are you ok? ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

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

If the suggestion is fine with Daniel, I think editorial clarification and a new error code can be added without disrupting the cycle and I am strongly in favor of that. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

[Acme] ACME notes from IETF99

An anonymous correspondent sends the following. I will try to upload them but it might be too late… 1. draft-ietf-acme-acme The draft passed a second WGLC and has gone for IESG review. There are some minor editorial issues. No further work is expected. 2.

Re: [Acme] Minutes from IEtf 99

Ø https://datatracker.ietf.org/meeting/99/materials/minutes-99-acme Ø Kind of underwhelming, I know. Ø Rich: Are we planning on fleshing this out? Richard Barnes had promised to. I should take back the spinner I gave him. ___ Acme mailing list

Re: [Acme] Issuing a cert with a superset of requested identifiers

There’s compliant and there’s compliant. ☺ The IETF has no protocol police, and you will not get a ticket for issuing a cert “wrongly.” Will anyone complain if you change the CSR to say “S.A.” or “Pty” instead of “Inc” or “Ltd”? Of course not. Will people be upset if you add other random

[Acme] FW: I-D Action: draft-ietf-acme-caa-03.txt

If you raised concerns before, please see if this latest draft resolves them. If there are no objections by next Weds, Sept 6, we will move this forward to the IESG. On 8/30/17, 4:37 AM, "Hugo Landau" wrote: > A New Internet-Draft is available from the on-line

Re: [Acme] Resend: [Gen-art] Genart telechat review of draft-ietf-acme-acme-07]

Thank you for the detailed feedback! As announced at the meeting on Thursday, the editor’s plan is to address the major technical issue and start looking at your review. We’ll put out another draft, and perhaps do a limited WGLC that focuses on just the not-purely-editorial changes.

Re: [Acme] Removing OOB Challenge Type

Thank you for the reminder. As chair, I say that we have consensus to remove the OOB challenge. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

[Acme] Agenda topics

I assume we’ll do a block of time on the core draft changes, and what we should do about re-enter WGLC or other options. And then I think much of our time will be on STIR certificate stuff. But I could be totally wrong. Do you have things you want to talk about? Either locally or remotely?

Re: [Acme] Mail regarding draft-ietf-acme-tls-alpn

* As I read it, the server would have to temporarily use a customized self-signed certificate while the check is pending. If you renew before the current cert expires, that’s not an issue, right? ___ Acme mailing list Acme@ietf.org

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

* Well, we have a fair bit of experience of a lot of people talking to Let's Encrypt. That's not really the same as a lot of servers and a lot of clients. We have multiple CA’s that support it, and other implementations as well. Certainly LE dominates, but it’s not the only usage. And

[Acme] Do we need/want mandatory-to-implement signature algorithms?

* Yes, please ask. If I'm going to tell the IESG that no MTI is needed, I want to tell them that the WG had consensus. This came up in the “AD review” thread that many of you have probably just seen and skimmed or ignored. :) ACME does not define any mandatory-to-implement signature

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

* The reason I chose those values is because you're already tied to TLS for the communications and therefore you necessarily have the TLS MTI cipher suites, which means you already have those algorithms. If your toolkit exposes it. If your toolkit is a black box or scripted such as CURL,

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

I believe the working group has decided that MTI algorithms are not necessary. If you want that confirmed on the list, we can ask. ACME isn’t just WebPKI, as you know, it’s also becoming STIR and some have proposed home environments. We have many implementations to serve as proof points that

  1   2   3   >