Re: [Acme] [Technical Errata Reported] RFC8555 (7565)

This seems correct to me. I would mark it Verified. On Thu, Jul 13, 2023 at 12:19 PM RFC Errata System < rfc-edi...@rfc-editor.org> wrote: > The following errata report has been submitted for RFC8555, > "Automatic Certificate Management Environment (ACME)". > >

Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

Hi Mike, Paul, So if I understand this correctly, the idea is that an ACME client that intends to obtain a certificate for example.com will look up CAA records for example.com and follow the guidance there as to which CA to contact? Couple of observations on a quick skim: A brief "protocol

Re: [Acme] Call for adoption for draft-bweeks-acme-device-attest

I have read the draft, and it seems well thought through. Especially if there is implementor interest, this seems like a sane thing for the WG to adopt. On Tue, Nov 15, 2022 at 2:53 PM Carl Wallace wrote: > I’ve read the draft and support its adoption. > > > > *From: *Acme on behalf of Deb

Re: [Acme] [IANA #1217629] Expert Review for draft-ietf-acme-dtnnodeid-07 (acme)

Hi Amanda, I reviewed the diff, and it doesn't look like anything relevant to the review changed. So I think we're good. --RLB On Fri, Oct 14, 2022 at 4:12 PM Amanda Baber via RT < drafts-expert-rev...@iana.org> wrote: > Dear Richard (cc: acme WG), > > You approved the proposed registrations

Re: [Acme] Authority Token WGLC

er > vendor/CA URL. > > I think if we include it as optional, I have no issue including it, if we > think it needs to be mandatory would probably want to get more feedback > from others. > > -Chris > > On Aug 26, 2022, at 5:02 PM, Richard Barnes wrote: > > One minor po

Re: [Acme] Authority Token WGLC

One minor point: STIR PASSporT objects reference certificates via the JWS "x5u" header, which requires that the URL respond to GET, vs. the POST-as-GET that is used for the ACME certificate URL. On the face of it, this would seem to require a STIR signer to download their certificate from the CA

Re: [Acme] Fwd: New Version Notification for draft-suchan-acme-onion-00.txt

Yep, this is the right way to suggest a new draft! Thanks for writing this up. One high-level comment on a quick skim: I don't think you need the new identifier type. Since .onion is a "legit" TLD [RFC7686], onion names are part of the DNS namespace. It's OK for CAs to have different policies

Re: [Acme] 2nd working group call for adoption

I have read the document, and support its adoption. This functionality actually reflects the existing behavior of a lot of CAs in the Web PKI (allowing issuance for subdomains after validating a registered domain), so it's good to have clear semantics in ACME for it. --Richard On Thu, Oct 14,

[Acme] Fwd: New Version Notification for draft-biggs-acme-sso-00.txt

Tue, Dec 8, 2020 at 10:09 AM Subject: New Version Notification for draft-biggs-acme-sso-00.txt To: Andrew Biggs , Richard L. Barnes A new version of I-D, draft-biggs-acme-sso-00.txt has been successfully submitted by Richard Barnes and posted to the IETF repository. Name: draft-bigg

Re: [Acme] [Editorial Errata Reported] RFC8555 (6321)

(Submitter removed) This appears to be invalid. On Mon, Oct 26, 2020 at 10:50 PM RFC Errata System < rfc-edi...@rfc-editor.org> wrote: > The following errata report has been submitted for RFC8555, > "Automatic Certificate Management Environment (ACME)". > >

Re: [Acme] [Technical Errata Reported] RFC8555 (5979)

ADs: This seems like a nice clarification, but not really an error. Suggest HFDU. On Tue, Feb 11, 2020 at 4:49 PM RFC Errata System wrote: > The following errata report has been submitted for RFC8555, > "Automatic Certificate Management Environment (ACME)". > >

Re: [Acme] draft-ietf-acme-star

and therefore we > propose to move forward with the current draft version. Please let us > know if we missed anything. > > Cheers, Thomas (on behalf of the authors) > > > On 28/08/2019 at 15:52, Richard Barnes wrote: > > > > I had a chance to take a look at this d

[Acme] draft-ietf-acme-star

I had a chance to take a look at this draft as a result of being a designated expert on the registries. I approved the registrations, but independently, I have several major concerns about the draft. In no particular order - The use of the "STAR" acronym is not helpful. This is not an acronym

Re: [Acme] [Technical Errata Reported] RFC8555 (5729)

+1 On Thu, May 23, 2019 at 7:43 PM Jacob Hoffman-Andrews wrote: > I believe this should be verified. > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Editorial Errata Reported] RFC8555 (5734)

+1 On Thu, May 23, 2019 at 7:38 PM Jacob Hoffman-Andrews wrote: > I believe this should be verified. > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Editorial Errata Reported] RFC8555 (5735)

+1 On Thu, May 23, 2019 at 7:39 PM Jacob Hoffman-Andrews wrote: > I believe this should be verified. > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

[Acme] Use cases / trust model for device certs

Hey Rifaat, Owen and I were chatting about ACME and device certs this morning, and it seemed like it might be useful to rekindle discussion on the topic here on the ACME list. I'd like to push a little more on the trust model here. Just to establish some terminology: - Device: Uses

Re: [Acme] draft-ietf-acme-ip-05

Hey Kathleen, I'm not clear on what you're after here. Do you see something in here forbidding use for client certificates that needs to be removed? Do you think there needs to be some explanation of how to put the right EKU in the CSR? It might help if you could submit a PR. --Richard On

Re: [Acme] Client certificate draft

On Fri, Mar 29, 2019 at 9:30 AM Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote: > > > On Fri, Mar 29, 2019 at 4:27 AM Richard Barnes wrote: > >> >> >> On Fri, Mar 29, 2019 at 7:49 AM Kathleen Moriarty < >> kathleen.moriarty.i...@gmail

Re: [Acme] Client certificate draft

On Fri, Mar 29, 2019 at 7:49 AM Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote: > I meant to respond inline as well. > > Sent from my mobile device > > On Mar 28, 2019, at 4:58 PM, Richard Barnes wrote: > > To recap and extend some things that were said

Re: [Acme] Client certificate draft

To recap and extend some things that were said at the meeting: - ACME can already be used for client certificates that attest to domain names. It's just an EKU difference, so it can be negotiated in the CSR. - ACME can already be used for code-signing certs, with external validation. As with

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

Thanks to everyone for your work on this! On Mon, Mar 11, 2019 at 5:08 PM wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 8555 > > Title: Automatic Certificate Management Environment (ACME) > Author: R. Barnes, >

Re: [Acme] Add badPublicKey error

On Thu, Jan 24, 2019 at 10:52 AM Salz, Rich wrote: > As WG co-chair, I am not thrilled with making this addition so very very > late in the process. If the WG wants to do it, we'd need (a) clear > consensus and (b) a quick approval from the IESG. > Note that since the registration policy is

Re: [Acme] Add badPublicKey error

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, 2019 at 9:26 AM Rob Stradling wrote: > I realize it's very late for making non-editorial changes to > draft-ietf-acme-acme, but I'd like to propose adding a new

Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt

ossible, I would like to keep this proposal independent of the > Token > Authority framework at this stage. > I'm confused. Issuing with authority tokens entails exactly the flow you've laid out. It's just that the interaction between the client and the token authority is undefined in that d

Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt

"Always be closing" :) Or to cite a more ancient source: "Quidquid facies, respice ad mortem" "Whatever you do, contemplate death" -- Seneca On Thu, Jan 17, 2019 at 4:09 PM Salz, Rich wrote: > Richard always wants to close WG’s. :) His views don’t necessarily > reflect those of the AD’s or

Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt

ion makes sense. > I looked at the "authority token" documents a while ago; I will take a > look again to see if I can align this document with that framework. > > Regards, > Rifaat > > > On Thu, Jan 17, 2019 at 1:51 AM Richard Barnes wrote: > >> It seems

Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt

It seems like the core of this draft is identifier delegation. Namely, the CA recognizes the DA as an authority for a certain identifier space (e.g., the first few octets of a MAC address), and the JWT delegates permission to issue certificates for some identifier in that space to the Client.

Re: [Acme] Meeting in Prague?

I hold out hope that we can have the WG closed by Prague. If we haven't, and the collaborators on the phone stuff need to meet, that seems like it can be handled as a side meeting. On Tue, Jan 15, 2019 at 9:09 AM Salz, Rich wrote: > Should we meet in Prague? > > > > Most of our documents are

[Acme] email-tls, identifiers, challenges

Hey all, Following up on my comments at the mic today... It seems like we have few questions here: 1. What identifiers do we envision going in the certificate? 2. What identifiers should be validated in ACME to support issuance for those identifiers? 3. What challenges should be used to validate

Re: [Acme] Please consider adding server authentication

On Mon, Oct 22, 2018 at 10:57 AM Kas wrote: > > On 10/22/2018 5:40 PM, Richard Barnes wrote: > > On Mon, Oct 22, 2018 at 10:13 AM Kas > wrote: > >> Hi Richard, >> The weak point here is the TLS connection so the question is : >> How to prevent man in t

Re: [Acme] Please consider adding server authentication

dy no need for third-party resources. --Richard > > Best regards, > K. Obaideen > > On 10/22/2018 3:48 PM, Richard Barnes wrote: > > Hi Kas, > > Before launching into mechanism, maybe you could clarify what > authentication property you think is lacking here? > &g

Re: [Acme] Please consider adding server authentication

Hi Kas, Before launching into mechanism, maybe you could clarify what authentication property you think is lacking here? Note that ACME already has server authentication, via TLS server authentication. All the normal PKI mitigations apply there: CT, HPKP, etc. It is also already the case that

Re: [Acme] Adam Roach's Yes on draft-ietf-acme-acme-16: (with COMMENT)

Thanks for your review, Adam! On Tue, Oct 16, 2018, 15:11 Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-acme-acme-16: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines.

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

> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Automated Certificate Management > Environment WG of the IETF. > > Title : Automatic Certificate Management Environment > (ACME

Re: [Acme] lack of nonce for external account binding (was Re: Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14:) (with DISCUSS and COMMENT)

On Wed, Oct 10, 2018 at 6:47 PM Benjamin Kaduk wrote: > On Wed, Oct 10, 2018 at 06:42:33PM -0400, Richard Barnes wrote: > > On Wed, Oct 3, 2018 at 11:54 AM Benjamin Kaduk wrote: > > > > > On Sat, Sep 15, 2018 at 08:51:55PM -0500, Benjamin Kaduk wrote: > > > >

Re: [Acme] lack of nonce for external account binding (was Re: Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14:) (with DISCUSS and COMMENT)

On Wed, Oct 3, 2018 at 11:54 AM Benjamin Kaduk wrote: > On Sat, Sep 15, 2018 at 08:51:55PM -0500, Benjamin Kaduk wrote: > > On Fri, Sep 14, 2018 at 03:59:07PM -0400, Daniel McCarney wrote: > > > > My co-author Daniel McCarney is working on the COMMENT comments. > > > > > > > IMPORTANT: I don't

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

goals > is to switch away from the "counting accounts" or "counting authzs" > examples (which I think we can't effectively mitigate) to more specific > examples of correlations. However, I think I can make that point with > examples from across all the different re

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

ng accounts" or "counting authzs" > examples (which I think we can't effectively mitigate) to more specific > examples of correlations. However, I think I can make that point with > examples from across all the different resource types. > > On 10/09/2018 12:27 PM, Ri

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

Thanks for the PR. My only issue is with the changes in there that slim down the example. ISTM that we should be encouraging unguessable URLs as widely as possible; guessable URLs should be a justified exception (as you noted in your description of what LE does). If you could slim this down to

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

So here's the compromise I would propose: 1. Remove GET for certificates. I think this is a mistake, but I can grant that it's clunky as-is, and it will be straightforward to re-add it later if it's needed. 2. Keep the security considerations about capability URLs and the randomized examples.

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

2018 at 6:31 AM Richard Barnes wrote: > >> Not sure which existing text you're referring to. No conflict comes to >> mind. >> >> In particular, this seems compatible with the stuff in #post-as-get about >> how the server indicates that it doesn't allow GET

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

uire that we retain that > text? > > -Ekr > > > On Sun, Oct 7, 2018 at 4:37 PM Salz, Rich wrote: > >> WG, this PR adds a new optional indicator that GET can be used to fetch >> certificates. >> >> >> >> If you opposed please speak up now.

Re: [Acme] Allow get for certificates?

I went ahead and posted a PR adding the "meta" field: https://github.com/ietf-wg-acme/acme/pull/462 On Sun, Oct 7, 2018 at 5:04 AM Thomas Fossati wrote: > The 10/06/2018 17:27, Richard Barnes wrote: > > I'm not hard set against this change, I just don't see much benefit. &g

Re: [Acme] Randomizing URLs in examples

NE. Stop merging. Discuss on the list. > > > > *From: *Richard Barnes > *Date: *Saturday, October 6, 2018 at 5:38 PM > *To: *"acme@ietf.org" > *Subject: *[Acme] Randomizing URLs in examples > > > > I have opened a PR reverting Jacob's reversion of t

[Acme] Randomizing URLs in examples

I have opened a PR reverting Jacob's reversion of the #455 https://github.com/ietf-wg-acme/acme/pull/460 The randomization of examples is independent of whether you think GETs are a good idea or not. As noted in the Security Considerations, having different types of resources in different

Re: [Acme] Allow get for certificates?

I'm not hard set against this change, I just don't see much benefit. Allowing GETs for certificate URLs is so low-risk that we weren't going to access-control it at all until a couple weeks ago. Now it's so high-risk that we need to REQUIRE authentication? That's "REQUIRED" in the RFC 2119

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

On Fri, Oct 5, 2018 at 1:41 PM Adam Roach wrote: > [as an individual] > > On 10/5/18 11:21 AM, Jacob Hoffman-Andrews wrote: > > In the rounds of reviews on https://github.com/ietf-wg-acme/acme/pull/445, > I missed an addition: the suggestion to use capability URLs for access > control on

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

In the spirit of giving credit where credit is due: I just noticed that Sophie Herold had suggested making URLs non-guessable all the way back in January [0]. Not sure why that got missed at the time (looks like we got distracted by the reasoning), but retroactive thanks to Sophie! [0]

Re: [Acme] New Version Notification for draft-ietf-acme-acme-15.txt

t;: "example.org" > }, > > "challenges": [ >{ > "type": "http-01", > "url": "https://example.com/acme/authz/1234/0; > <https://example.com/acme/authz/1234/0>, > "status&qu

Re: [Acme] malformedRequest vs. malformed in draft-ietf-acme-acme-15

Thanks, Felix, good catch. I have implemented this fix in the following PR: https://github.com/ietf-wg-acme/acme/pull/454 Please take a look and let me know if that looks good. On Tue, Oct 2, 2018 at 9:56 PM Felix Fontein wrote: > Hi, > > while looking at POST-as-GET support for account

Re: [Acme] Mismatch between example and text in 7.4.2 of draft-ietf-acme-acme-15

Thanks, David, good idea. I have implemented this fix (with slightly different words) in this PR: https://github.com/ietf-wg-acme/acme/pull/454 On Sat, Sep 29, 2018 at 7:07 PM David Hancock wrote: > In section 7.4.2. "Downloading the Certificate", the text doesn't match > the example (text

Re: [Acme] New Version Notification for draft-ietf-acme-acme-15.txt

This version incorporates the feedback from the IESG, most notably moving from to GET to POST-as-GET. Chairs / ADs - Where to from here? On Tue, Sep 25, 2018 at 11:02 PM Richard Barnes wrote: > This version incorporates the feedback from the IESG, most notably moving > from to GET t

[Acme] Tightening up the PEM cert chain type

FYI: In response to a GitHub issue[1], I have filed a PR [2] to tighten up the definition of the application/pem-certificate-chain media type in two ways: 1. Forbid explanatory text 2. Require the "strict" format Chairs: OK to handle this on the same "comments-by-Friday" basis as the

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

on closing this out? What are the next process steps? On Fri, Aug 31, 2018 at 6:08 PM Richard Barnes wrote: > Hey all, > > This thread forked into a couple of different issues, so I wanted to post > a little end-of-day summary of the issues and where we stand. I've updated > t

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

On Wed, Sep 5, 2018 at 3:43 PM Jacob Hoffman-Andrews wrote: > On 09/05/2018 12:39 PM, Richard Barnes wrote: > > Using the same notation, I'm: > > > > 1) "" > > 2) "urn:ietf:params:acme:get" > > 99) "{}" > > Given that, I'm w

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

-octet string 0x1844, which conveniently base64url-encodes to "GET" :) On Wed, Sep 5, 2018 at 1:17 PM Jacob Hoffman-Andrews wrote: > On 09/05/2018 08:33 AM, Richard Barnes wrote: > > 1. A field in the protected header ("urn:ietf:params:acme:get": true) > > wi

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

On Wed, Sep 5, 2018 at 12:53 PM Salz, Rich wrote: > >- Because being generous in what you receive is harmful. > > https://tools.ietf.org/html/draft-iab-protocol-maintenance-00 >

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

Because being generous in what you receive is harmful. https://tools.ietf.org/html/draft-iab-protocol-maintenance-00 In case anyone want to try to interop, I updated my lego patch to implement (1): https://github.com/bifurcation/lego/pull/1/commits/750383d7ad272a0894d6ff86d4d85d38f965c14f On

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

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 uses. What would you guys think about one of these explicit markers: 1. A field in

Re: [Acme] nomenclature: “POST-as-GET”

On Tue, Sep 4, 2018 at 1:44 PM Felipe Gasper wrote: > FWIW, it seems to me like, if the HTTP verb being used is, in fact, > “POST”, then a more appropriate term for the proposed fix for the identity > correlation problem identified last week would be “GET-as-POST” rather than > “POST-as-GET”. >

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

instance, some CAs might consider the grouping of certificates > by account to be sensitive. > > Richard Barnes proposes[2] to change all GETs to POSTs (except directory > and new-nonce). This will be a breaking change. Clients that were > compatible with previous draf

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

On Fri, Aug 31, 2018 at 3:30 PM Jacob Hoffman-Andrews wrote: > On 08/31/2018 07:25 AM, Richard Barnes wrote: > > The problem with using POST-as-GET for certificate resources, as > > Felipe I think pointed out, is that the thing that downloads the > > certificate URL is oft

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

>> >> I would encourage other ACME client/server developers to try their hand >> at implementing the changes from [1] as well. I've tested my PR with >> hand-rolled requests but not as part of an automated issuance process with >> a "real"

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

your bugs. > > [0] - https://github.com/letsencrypt/pebble/pull/162 > [1] - https://github.com/ietf-wg-acme/acme/pull/445/files > > On Fri, Aug 31, 2018 at 1:21 PM, Richard Barnes wrote: > >> No, if a server receives a GET request for a resource other than those >> sp

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

On Fri, Aug 31, 2018 at 4:15 PM Jacob Hoffman-Andrews wrote: > On 08/31/2018 12:30 PM, Jacob Hoffman-Andrews wrote: > > /account/100/certificate/3438 > > /account/201/certificate/3439 > > /account/100/certificate/3440* > > Here's an issue that came up during code review: When you POST-as-GET to

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

> Mississauga, Ontario > > > > On Aug 30, 2018, at 11:51 AM, Salz, Rich > > > wrote: > > > > It appears that we missed a security issue. > > > > Please take a look at the PR mentioned below. It removes many GET > requests and turns them into P

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

On Fri, Aug 31, 2018 at 1:39 PM Benjamin Kaduk wrote: > On Fri, Aug 31, 2018 at 12:32:08PM -0400, Richard Barnes wrote: > > I've started a PR for your DISCUSS comments here: > > > > https://github.com/ietf-wg-acme/acme/pull/447 > > > > Right now, th

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

No, if a server receives a GET request for a resource other than those specified, then it MUST return 405. But please check out the PR and see if it's clear there. On Fri, Aug 31, 2018 at 1:14 PM Salz, Rich wrote: > >- * Servers MUST return a 405 if they get a GET for a resource other >

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

Responses to COMMENT comments inline below (DISCUSS part trimmed). PR here: https://github.com/ietf-wg-acme/acme/pull/448 On Thu, Aug 30, 2018 at 12:50 AM Adam Roach wrote: > > -- > COMMENT: >

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

gt; I'm not sure what you mean by "caaIdentities element gives a leaf cert some control over the trust anchors that are used". Who is controlling whose use of trust anchors, and how? On Thu, Aug 30, 2018 at 8:06 PM Benjamin Kaduk wrote: > On Wed, Aug 29, 2018 at 09:10:06PM

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

t towards transparency. > > Adam Roach recently pointed out in his Area Director review that even > when the contents of GET URLs aren’t sensitive, their correlation may > be. For instance, some CAs might consider the grouping of certificates > by account to be sensitive. > > Ri

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

The problem with using POST-as-GET for certificate resources, as Felipe I think pointed out, is that the thing that downloads the certificate URL is often not an ACME player, doesn't have an account, etc. It's a web server or something. (cf. the STAR drafts.) What I'm saying is that it's

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

her the server > allows a plain GET for a certificate … other than, of course, getting a 405 > back when the client tries to request a certificate via GET. > > -F > > > On Aug 31, 2018, at 10:16 AM, Richard Barnes wrote: > > > > TBH, I'm not averse to allowing GETs fo

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

TBH, I'm not averse to allowing GETs for certificate resources. It seems analogous to allowing them for the directory resource, just on the opposite side of the process. That is, the directory and certificate resources are the interfaces between ACME and the outside world, so it makes sense not

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

a PR: https://github.com/ietf-wg-acme/acme/pull/445 On Thu, Aug 30, 2018 at 11:33 AM Adam Roach wrote: > On 8/30/18 8:48 AM, Felix Fontein wrote: > > Hello, > > > On 8/30/18 7:55 AM, Richard Barnes wrote: > > Focusing on DISCUSS comment for now, will pick up COMMENTs la

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

such as “DIGIT”, “ALPHA”, etc. Using them would > make the base64url rule clearer: > > > > base64url = ALPHA / DIGIT / “-“ / “_” > > > > Thanks, > > Corey > > > > *From: *Acme on behalf of Richard Barnes > > *Date: *Thursday, August 30, 2018 at 8:2

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

Focusing on DISCUSS comment for now, will pick up COMMENTs later. On your DISCUSS, I think you're off on a couple of small things, but right on the underlying point that the document doesn't really provide any guidance as to which resources a server should consider sensitive. I agree that it

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

Thanks, James. Fixed in the PR. On Wed, Aug 29, 2018 at 10:41 PM Manger, James < james.h.man...@team.telstra.com> wrote: > >> base64url = [A-Z] / [a-z] / [0-9] / "-" / "_" > > > base64url = (%x40-5A) / (%x61-7A) / (%x30-39) / "-" / "_" > > > > “A” is %x41 (not %x40) > > > > -- > > James

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

Hi Ben, Thanks for the detailed review. Responses to the DISCUSS comments inline. My co-author Daniel McCarney is working on the COMMENT comments. --Richard On Wed, Aug 29, 2018 at 2:53 PM Benjamin Kaduk wrote: > > It looks like the server returns an unauthenticated "badSignatureAlgorithm" >

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

I noticed that we already had some text in the security considerations about redirects, so I reverted to SHOULD and added a forward pointer. > More limited forms of delegation can also lead to an unintended > party gaining the ability to successfully complete a validation > transaction. For

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

Hi Alexey, Thanks for the comments. A couple of replies are below; resulting edits are in this PR: https://github.com/ietf-wg-acme/acme/pull/442 --Richard On Wed, Aug 29, 2018 at 7:14 AM Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for >

Re: [Acme] Ben Campbell's Yes on draft-ietf-acme-acme-14: (with COMMENT)

Hi Ben, Thanks for the comments. A couple of replies are below; resulting edits are in this PR: https://github.com/ietf-wg-acme/acme/pull/441 --Richard On Tue, Aug 28, 2018 at 10:46 PM Ben Campbell wrote: > Ben Campbell has entered the following ballot position for >

Re: [Acme] draft-ietf-acme-tls-alpn-03

I don't really think it matters much who's going to make a new version. The only difference here is whether you go back to IANA to get a new code point. Given that the IANA process is not onerous, it seems like the extra couple of octets are not really adding anything here. So I'm inclined to do

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

; This draft is a work item of the Automated Certificate Management > Environment WG of the IETF. > > Title : Automatic Certificate Management Environment > (ACME) > Authors : Richard Barnes > Jacob Hoffman-Andrews >

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

l/433 >> >> And three issues: >> >> https://github.com/ietf-wg-acme/acme/issues/434 >> https://github.com/ietf-wg-acme/acme/issues/435 >> https://github.com/ietf-wg-acme/acme/issues/436 >> >> spt >> >> > On Aug 8, 2018, at 21:48, Richa

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

Without looking at them in context that seem pretty reasonable. Happy to review a PR. On Wed, Aug 8, 2018, 21:03 Sean Turner wrote: > These are all minor so I didn’t send them to i...@ietf.org. Also, once > we settle on whether these are okay, I can submit a PR if you’d like (or > not if

Re: [Acme] DE review comment draft-ietf-acme-acme

Seems reasonable. I filed , which I'll handle with the rest of LC comments in a couple of days. On Tue, Aug 7, 2018 at 7:59 PM Jim Schaad wrote: > It would be nice to have the description for the JOSE header 'url' be more > descriptive that the

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

You beat me to it. On Wed, Jul 25, 2018 at 1:59 PM Salz, Rich wrote: > Use ip-addr.arpa names? > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing

Re: [Acme] Consensus on WGLC for draft-ietf-acme-star-03

As a point of order, I'm pretty sure the chairs don't need consensus to move to WGLC, they can just do it. On Wed, Jul 18, 2018 at 3:53 PM Salz, Rich wrote: > For context: this is draft-ietf-acme-star-03 as mentioned in the Subject > but not the body. > > > > *From: *Rich Salz > *Date:

Re: [Acme] Confirming consensus

On Thu, Jul 19, 2018, 17:05 Ilari Liusvaara wrote: > On Thu, Jul 19, 2018 at 01:03:14PM -0700, Roland Shoemaker wrote: > > One thing that I forgot to bring up during the meeting was an issue > > that was brought up with regards to the order in which the ACME-TLS-ALPN > > and ACME-IP drafts are

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

Richard Barnes wrote: > I went ahead and posted a PR implementing EKR's suggestion: > > https://github.com/ietf-wg-acme/acme/pull/429 > > > On Wed, May 30, 2018 at 4:23 PM Daniel McCarney > wrote: > >> We have multiple CA’s that support it, and

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

I went ahead and posted a PR implementing EKR's suggestion: https://github.com/ietf-wg-acme/acme/pull/429 On Wed, May 30, 2018 at 4:23 PM Daniel McCarney wrote: > We have multiple CA’s that support it, and other implementations as well. > > > Of the multiple CAs that support ACME, which

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

On Thu, May 31, 2018 at 5:09 PM Eric Rescorla wrote: > > > On Thu, May 31, 2018 at 2:03 PM, Richard Barnes wrote: > >> >> >> On Wed, May 30, 2018 at 5:41 PM Stephen Farrell < >> stephen.farr...@cs.tcd.ie> wrote: >> >>> >>> Hi R

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

On Wed, May 30, 2018 at 5:41 PM Stephen Farrell wrote: > > Hi Russ, > > On 30/05/18 22:31, Russ Housley wrote: > > It seems to me that ACME is being used to support certificate > > enrollment for many different applications, so the same approach > > seems appropriate. > I agree with your

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

On Tue, May 29, 2018 at 4:02 PM Eric Rescorla wrote: > > > On Mon, May 28, 2018 at 9:57 PM, Russ Housley > wrote: > >> Eric: >> >> >> > > Do you want to specify a set of acceptable signature algorithms here? > > I am inclined not to. We have already forbidden "none" and MAC. We

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

On Tue, May 15, 2018 at 2:37 AM Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Tue, May 15, 2018 at 01:20:14AM +, Richard Barnes wrote: > > [ Adding the mailing list ] > > > > > S 6.6. > > > > | > > |

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

[ 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

Re: [Acme] Genart last call review of draft-ietf-acme-acme-11

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

Re: [Acme] Genart last call review of draft-ietf-acme-acme-11

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

  1   2   3   >