discussion, but strong consensus to adopt this by the WG.
> Chairs will confirm on the list.
>
>> And also Jon Peterson et al
>> https://tools.ietf.org/html/draft-peterson-acme-telephone-00
>
> Also similar discussion. General agreement to also adopt this, and keep
Little difference from the last draft, mostly small cleanups.
There was some previous discussion about how to handle policy decisions
for issuing certificates for IP addresses. It was suggested that this
draft should contain some stronger language that would allow default
denial of certificate iss
Sorry for the lag on getting this out. Given the discussions at IETF 101 and on
the list the main change in this version is the removal of the reverse-dns
challenge type. While I still think there is some value in at least having a
technical definition of the method there is enough opposition th
?
> On May 19, 2018, at 4:58 AM, Ilari Liusvaara wrote:
>
> On Fri, May 18, 2018 at 03:16:32PM -0700, Roland Shoemaker wrote:
>> Sorry for the lag on getting this out. Given the discussions at IETF
>> 101 and on the list the main change in this version is the removal of
>>
The validation certificate should only ever be served for requests that
negotiate the amce-tls/1 application protocol, which browsers or equivalent
user software should never do. This allows the server (or load balancer) to
continue serving normal traffic to users while also serving validation t
As previously discussed on the list the two property names defined in
draft-ietf-acme-caa, "validation-methods” and "account-uri”, do not conform to
the ABNF syntax in RFC 6844 as they contain hyphens. 6844-bis fixes this by
expanding the ABNF to be less restrictive but for now this doesn’t real
draft-ietf-acme-tls-alpn-01: No changes since last meeting other than a handful
of minor editorial changes. The draft method is currently implemented in the
Let’s Encrypt staging environment and is planned to be deployed in the
production environment in the coming weeks.
draft-ietf-acme-ip-02:
Oh, and I don’t think there needs to be any time devoted to either draft as
nothing major has been added/changed since the last meeting.
> On Jun 27, 2018, at 2:39 PM, Roland Shoemaker wrote:
>
> draft-ietf-acme-tls-alpn-01: No changes since last meeting other than a
> hand
I know this is quite late but could we reserve some time for a discussion of
the (possible) pending issues with regard to the parameter format mismatch
between ACME-CAA and 6844 and possible solutions.
Thanks!
Roland
___
Acme mailing list
Acme@ietf.org
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 standardized. ACME-IP defines how to use IP addresses with existing
challenges and we’d like to include guidance on how to do so wit
Ah, awesome. Well that makes life a lot easier! I’ll work to get a version of
ACME-IP that includes this up today or tomorrow.
> On Jul 19, 2018, at 2:05 PM, Ilari Liusvaara wrote:
>
> On Thu, Jul 19, 2018 at 01:03:14PM -0700, Roland Shoemaker wrote:
>> One thing that I for
Works for me, I’ll push a version with this change this afternoon.
Corey: thanks for catching this! I went looking for a reference on whether this
was allowed but apparently completely glazed over the relevant line in 6066.
> On Jul 25, 2018, at 10:59 AM, Salz, Rich
> wrote:
>
> Use ip-addr.a
Thanks for taking a look. I’ve opened
https://github.com/rolandshoemaker/acme-tls-alpn/pull/6/files to address most
of these comments.
For (4) the plan is to simply version it as suggested, that’s why we went with
a two part OID with the base and then a versioned extension. If we need to
rotat
Yup, thanks for spotting this.
> On Aug 13, 2018, at 10:36 AM, Ilari Liusvaara
> wrote:
>
> On Mon, Aug 13, 2018 at 10:23:44AM -0700, internet-dra...@ietf.org wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Au
The decision to format the OID this way was an early one that I’m not
completely attached to. That said the existing solution does still feel cleaner
to me than doing the versioning directly under id-pe. Given it’s unlikely that
the version with be incremented by anything other than a document f
+1, will do.
> On Aug 15, 2018, at 12:54 PM, Russ Housley wrote:
>
> Roland:
>
> Thanks for the update. In addition to the changes that I requested, you
> added:
>
> The extnValue of the id-pe-acmeIdentifier extension is the ASN.1 DER
> encoding of the Authorization structure.
>
> Aut
Comments inline:
> On Dec 24, 2018, at 12:32 PM, Eric Rescorla wrote:
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D4180
>
>
> IMPORTANT
> S 3.
> > used to refer to fully qualified domain names. If a ACME server
> > wishes to request proof that a u
this further?
> On Jan 26, 2019, at 6:21 AM, Eric Rescorla wrote:
>
>
>
> On Thu, Jan 24, 2019 at 11:50 AM Roland Shoemaker
> wrote:
> Comments inline:
>
> > On Dec 24, 2018, at 12:32 PM, Eric Rescorla wrote:
> >
> > Rich vers
This revision contains a few small changes that address issues brought up
during the AD review.
> On Feb 14, 2019, at 1:02 PM, internet-dra...@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Automated Ce
I’ve been on vacation and was unaware any time had been assigned for TLS-ALPN,
and also have no meaningful update to provide: the only movement since the last
meeting is the most recent AD review, which doesn’t suggest any major
structural changes.
> On Jul 21, 2019, at 8:21 PM, Yoav Nir wrote
Hey Roman,
I’ve address most of the comments below and have a draft of the changes here:
https://github.com/rolandshoemaker/acme-tls-alpn/compare/in-proc?w=1
There are a few comments I’m not sure I agree with which I’ve responded to
inline below, if this all looks good to you I’ll push up a new
Thanks for the review. Good catch on the FQDN, this looks like it was just an
error in the example. I’ll push up a revision addressing this.
> On Sep 29, 2019, at 8:38 AM, Alexey Melnikov via Datatracker
> wrote:
>
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-ac
Hey Warren,
Thanks for the review of this document. Overall I don’t find the suggested
scenario particularly compelling in terms of indicating any security problems
with the suggested document. The threat model defined in 8555 indicates that
ACME is not able to mitigate scenarios where an attac
Hey Éric,
Thanks for the review. To answer your two questions:
1. Assuming you are referring to the “type” field of the standard ACME
identifier object the use of “ip” was thought to be a bit more verbose as to
what the identifier contained vs. “address”. There could be some confusion with
usi
Hey Benjamin,
Thanks for the review, I’ve replied to your two comments inline:
> On Sep 30, 2019, at 6:06 PM, Benjamin Kaduk via Datatracker
> wrote:
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-acme-ip-07: Yes
>
> When responding, please keep the subject line
Hey all,
This revision addresses comments by Adam Roach and Alexey Melnikov.
> On Oct 1, 2019, at 10:38 AM, internet-dra...@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Automated Certificate Managemen
Hey Martin,
Thanks for the thorough review, I agree with all of the suggestions and will be
incorporating the changes into the next revision. Following up on one point
about Section 7, I believe you may actually be thinking about another issue we
had with the http-01 ACME challenge. The issue h
Hey all,
This revision addresses the comments made in the ARTART, GENART, and SECDIR
reviews as well as comments made by Benjamin Kaduk, Adam Roach, and Barry Leiba.
Thanks to all for their thorough reviews.
Roland
> On Oct 1, 2019, at 1:35 PM, internet-dra...@ietf.org wrote:
>
>
> A New Inte
Hey all,
At Let's Encrypt we've been thinking about designing some kind of renewal
information API as an extension to ACME for a while now. Recent events have
brought this back to the forefronts of our minds. Below I've attached a
proposal I've written up detailing our proposal. I'd really like to
To save people some confusion, I think the reporter is referring to RFC
7231 (Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content) rather
than 7321 (Cryptographic Algorithm Implementation Requirements and Usage
Guidance).
On Wed, Mar 25, 2020 at 3:44 PM RFC Errata System
wrote:
> The f
Hey Matt,
In general I think this is a good idea. It's a concept that has been
discussed in a handful of venues in the past, and would certainly be a good
thing to have.
That said I'm not _entirely_ sure that ACME is the right place to specify
it. I think tying such a mechanism too closely to ACM
With the recent passage of SC27 at the CA/Browser Forum there are now
acceptable mechanisms for validating v3 Onion addresses for inclusion in DV
certificates. As such it would be good to extend ACME to be able to make
use of these methods. I've written a short draft that covers what is likely
to b
I would be extremely uncomfortable specifying a mechanism like this. It
would be a large divergence from the existing ACME specification, and would
create significant traps for implementers to fall into. Specifically this
would break assumptions in most existing implementations, principally that
an
On Thu, Jul 9, 2020 at 6:01 AM Ryan Sleevi wrote:
>
>
> On Thu, Jul 9, 2020 at 8:30 AM Ilari Liusvaara
> wrote:
>
>> On Wed, Jul 08, 2020 at 08:03:40PM +0200, Sebastian Nielsen wrote:
>> > Couldn’t it be done in the way that the ACME server creates a nonce.
>>
>> I am not sure why the client non
I think the disconnect here is between CAs and Relying Applications (i.e.
browsers) using CAA. The CA should use CAA to validate if they have
authority to issue, but the relying application must not because the CAA
records are only applicable at the time of issuance and there is no
guarantee that t
I've posted a small PR that allows users to specify the reason when
requesting the revocation of a certificate which is a prerequisite for
Boulder to be able to generate meaningful CRLs.
https://github.com/ietf-wg-acme/acme/pull/140
___
Acme mailing lis
The proposed simplification looks good to me and would make the Boulder
implementation much cleaner overall.
I also agree the ambiguity about which header the 'jwk' field is
provided in should be cleared up, it seems like there is no reason not
to require it in the protected header.
On 06/22/2016
(Playing devils advocate) Why not just remove the nonce system entirely?
The main use of the nonce system is to protect against TLS termination
at a CDN (or MITM middleboxes) which could, if malicious, replay
requests. Why not instead just recommend local termination of TLS and
that implementing c
I agree with Ted that generic URI support should be documented but that mailto
should be the only one explicitly referred to.
This was the intention of the original ticket I filled, although maybe not as
coherently.
On Jul 28, 2016, 3:17 PM -0700, Ted Hardie , wrote:
> Hi Richard
>
> On Thu, Ju
ot;explicitly referred to", do you mean in the examples? I
> would prefer to keep a non-mailto example there, if we're clear that the
> server can reject it.
>
>
> On Thu, Jul 28, 2016 at 6:21 PM, Roland Shoemaker (mailto:rol...@letsencrypt.org)> wrote:
> > I a
>From the view point of Let's Encrypt/Boulder: Our original plan for
major specification changes has been to provide multiple versioned API
endpoints which implement different verions of ACME. Currently we only
provide acme-v01.api.letsencrypt.org which implements an amalgam of the
first four draft
Given the recent validation rule change at CABF it looks like the
/.well-known/acme-challenge path will need to be registered before the
specification is finalized (a new CABF rule requires that the validation
path used is approved by IANA) if CA's such as Let's Encrypt wish to
continue using ACME
I propose we remove the 'author', 'revoke', and 'ct-sct' link relations.
'author' seems to provide no concrete value, and 'revoke' is already
provided by the 'directory' endpoint. The 'ct-sct' relation is also
somewhat pointless as the SCT will be provided by the CA via the
certificate or a OCSP re
How would people feel about adding some language to the account key
roll-over section that says that any cached (already valid)
authorizations for identifiers should be deactivated on roll-over? This
would reduce the risk of an attacker gaining control of an account and
all associated authorization
I'd argue that removing the challenge version numbers adds unnecessary
complexity to the specification and any existing implementations going
forward.
Existing servers and clients will need to have some kind of mapping from
the draft names to the final un-versioned names and any protocol
revisions
Internally at LE we have been having discussions around how the spec can
most effectively reduce the harm of account key compromise and it seems
like it could be a good topic to bring up at the upcoming IETF meeting.
We've come up with two distinct but not mutually exclusive ideas on this
topic:
Probably of interesting to some people here, would love to hear your
thoughts.
Forwarded Message
Subject: New Version Notification for draft-shoemaker-acme-ip-00.txt
Date: Mon, 27 Mar 2017 13:30:19 -0700
From: internet-dra...@ietf.org
To: Roland Bracewell Shoemaker , Roland
I'd be interested in getting draft-shoemaker-acme-ip (current draft:
https://www.ietf.org/id/draft-shoemaker-acme-ip-00.txt with a revision
coming in the very near future) adopted by the WG. We are currently
considering implementing the extension defined in it in the Let's Encrypt
server software B
The original draft of draft-ietf-acme-ip contained a description of how to
use the "dns-01" challenge for IPs, using the reverse DNS zone, but
opposition to it was brought up at the IETF meeting in 2018, due to the
perception of management issues with the zone, and unwillingness to use it
for secur
49 matches
Mail list logo
