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

gement Environment > WG of the IETF. > >Title : ACME IP Identifier Validation Extension > Author : Roland Bracewell Shoemaker > Filename: draft-ietf-acme-ip-07.txt > Pages : 5 > Date: 2019-09-27 >

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

Hey Roman, Sorry for the lag on this, I’ve been occupied by non-IETF work recently. I’ve done a pass based on your comments. I’m slightly confused about what you mean by including the clarify suggested in the previous AD review thread with regard to section 6 though. I believe the update in

Re: [Acme] Time for ACME-CAA discussion at 102

Great, thanks! > On Jul 16, 2018, at 8:44 PM, Salz, Rich wrote: > > Yes, you can go right after the main acme doc > > On 7/16/18, 11:08 PM, "Roland Shoemaker" wrote: > >I know this is quite late but could we reserve some time for a discussion > of the (possible) pending issues with

Re: [Acme] I-D Action: draft-ietf-acme-tls-alpn-01.txt

LS ALPN Challenge Extension > Author : Roland Bracewell Shoemaker > Filename: draft-ietf-acme-tls-alpn-01.txt > Pages : 8 > Date: 2018-05-30 > > Abstract: > This document specifies a new challenge for the Automated Certif

Re: [Acme] draft-ietf-acme-ip and draft-ietf-acme-caa

Ah, my bad on draft-ietf-acme-ip, I have a new version to submit but am still making a few changes, I thought the expiry notice was for my individual submission not the WG doc. I’ll submit the new version this afternoon. > On Apr 21, 2018, at 8:59 AM, Paul Hoffman wrote:

Re: [Acme] acme-ip reverse-dns discussion

> On Mar 28, 2018, at 3:15 AM, Eric Rescorla <e...@rtfm.com> wrote: > > > > On Wed, Mar 21, 2018 at 1:55 PM, Roland Bracewell Shoemaker > <rol...@letsencrypt.org> wrote: > The argument for removing this was that there are no technical issues with > the m

[Acme] acme-ip reverse-dns discussion

Hey all, Following on from the meeting today I wanted to start a discussion on what to do moving forward with regard to the reverse-dns method defined in draft-ietf-acme-ip. There were arguments on both sides about whether the method should be retained or removed with I’ll quickly paraphrase

Re: [Acme] Draft agenda

There isn’t much interesting to say about the IP validation document at the moment, I can put together a quick status slide and send it over. > On Mar 9, 2018, at 1:56 PM, Salz, Rich wrote: > > We are meeting Weds, 15:20-16:50 90 minutes > > Agenda bashing + Blue sheets

Re: [Acme] ALPN based TLS challenge

I’ll be at the meeting in London and would be happy to give a quick introduction/overview of the method if adopted. > On Feb 23, 2018, at 8:31 AM, Salz, Rich wrote: > > >> Here is the ID: >> https://datatracker.ietf.org/doc/draft-shoemaker-acme-tls-alpn/ > > Should the

Re: [Acme] ALPN based TLS challenge

Here is the ID: https://datatracker.ietf.org/doc/draft-shoemaker-acme-tls-alpn/ > On Feb 22, 2018, at 8:38 PM, Salz, Rich wrote: > > Yes, like Martin said, submit the individual draft and we can call for > adoption. > ___ Acme

[Acme] ALPN based TLS challenge

Hey all, After the issues with the SNI based TLS challenges were discovered there was interest from a number of parties in developing another challenge that did validation at the TLS layer. After some discussion about possibilities we’ve come up with a new challenge type based on ALPN which we

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

. I'd suggest the incredibly imaginative TLS-ALPN (or tls-alpn-01). On 01/11/2018 04:49 PM, Roland Bracewell Shoemaker wrote: > This seems like a silver bullet for the problems we’ve been seeing. Given > that blindly responding to an unknown ALPN value would be an RFC violation > this s

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

This seems like a silver bullet for the problems we’ve been seeing. Given that blindly responding to an unknown ALPN value would be an RFC violation this seems safe (although, hey, who knows what servers/cloud providers actually do). Definitely interested in the results of the scan. There could

[Acme] Discussion of draft-ietf-acme-ip

Hey all, First off I'd like to apologize for requesting an agenda item then not making it to the meeting to discuss it. It seems that while I had the right time in my calendar I managed to get the wrong day. The point of the draft is to provide a method for validating the control of IP addresses

Re: [Acme] Draft Agenda Uploaded

If possible I’d like to give a quick overview of the IP validation draft, the only feedback I’ve received on the last version was editorial unless there is any further thoughts on the technical aspects I’d be interested in seeing if there is consensus for moving this towards LC. Given it’s a

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

On 07/16/2017 10:14 PM, Ilari Liusvaara wrote: > On Sun, Jul 16, 2017 at 04:29:20PM -0700, Roland Bracewell Shoemaker wrote: >> There was some previous discussion about possibly using a slightly >> simpler DNS based verification method on the list last time I posted >>

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

he Automated Certificate Management Environment > of the IETF. > > Title : ACME IP Identifier Validation Extension > Author : Roland Bracewell Shoemaker > Filename: draft-ietf-acme-ip-00.txt > Pages : 7 >

Re: [Acme] Potential future incompatiblity between HTTP-01 and CABForum BRs

I'm not sure why the contents of the http-01 challenge could not be considered a 'request token'? A favorable interpretation that would require no changes would be that the random token (in ACME speak) is only half of the 'request token' (CABF speak) that is required for validation and therefore

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

: New Version Notification for draft-shoemaker-acme-ip-00.txt > Date: Mon, 27 Mar 2017 13:30:19 -0700 > From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> > To: Roland Bracewell Shoemaker <rol...@letsencrypt.org > <mailto:rol...@letsencrypt.org>&

Re: [Acme] Split up errors and add an error field to orders

+1 this seems like a good change. I've left one typo comment on the PR (code -> type). Splitting the tables up based on where the errors may be encountered is useful but adding the new 'error' field to the order object makes this slightly confusing. Will the errors on the order be from the first

Re: [Acme] Clarifying what to do with revocation requests with disallowed reasonCodes

, Feb 14, 2017 at 5:53 PM, Roland Bracewell Shoemaker > <rol...@letsencrypt.org <mailto:rol...@letsencrypt.org>> wrote: > > The current draft leaves it ambiguous as to what the server should do > when a it receives a revocation request containing a reasonCode that i

[Acme] Remove extraneous key equivalence method

The spec currently defines an entirely new JWK key equivalence method which is then only used once. Instead of adding this new method (which seems to just be a the JWK thumbprint computation minus the use of a digest) I propose we just re-work the key roll-over method to work without having to

[Acme] Clarifying what to do with revocation requests with disallowed reasonCodes

The current draft leaves it ambiguous as to what the server should do when a it receives a revocation request containing a reasonCode that it disallows. I suggest we add a simple 'MUST reject request' clause to the relevant section to resolve this ambiguity. PR:

Re: [Acme] Editorial fixes in GitHub

On 01/24/2017 07:07 AM, Daniel McCarney wrote: > I've reviewed each and left comments or positive +1's in the form of > approved > Github reviews. > > I'm in favour of removing the SCT link relation. It's unnecessary and as > Richard pointed out, easy to add back if it turns out the other SCT

Re: [Acme] Application/Authorization statuses

s are supposed to > mean and when a server should send them, and some guidance for what > a client should do if it receives them - even though that should be > a bit more obvious now if we prune away the more ambiguous ones. > > > > On Fri, Aug 26, 2016 at 6:12 P

[Acme] IDN encoding

I'd be interested in hearing peoples thoughts about this PR which adds language about how IDNs should be encoded by clients who wish to use them as identifier values. https://github.com/ietf-wg-acme/acme/pull/184 ___ Acme mailing list Acme@ietf.org

Re: [Acme] Proactive vs On-Finalization Certificate Issuance

On 08/25/2016 02:41 PM, Andrew Ayer wrote: > On Thu, 25 Aug 2016 13:57:25 -0400 > Daniel McCarney wrote: > >> In the earlier "Re: [Acme] Preconditions" thread[2] Andrew Ayer seems >> to agree >> that there should be only one issuance method to simplify client >>

[Acme] Registration status changes

draft-03 introduces a 'status' field on the registration object with the values 'good' or 'deactivated'. I propose two changes to this, using 'valid' instead of 'good', which better matches the other statuses used elsewhere in the specification and adding language to the new registration section