On Fri, Jul 20, 2018 at 12:05:05AM +0300, 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 d
Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-acme-14: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
On Wed, Aug 29, 2018 at 04:55:09PM +, Salz, Rich wrote:
> I read the link you posted, thanks.
>
> As long as we’re not breaking the HTTP spec, I agree that SHOULD seems to get
> the most interop. As long as we’re getting signed reponses back, I don’t
> think it matters much where the redire
On Wed, Aug 29, 2018 at 08:58:59PM -0500, Ben Campbell wrote:
>
>
> > On Aug 29, 2018, at 8:10 PM, Richard Barnes wrote:
> >
> >
> > I am not an ART AD, but there is not yet an internationalization
> > directorate, and seeing statements like "inputs for digest computations
> > MUST be encoded
On Wed, Aug 29, 2018 at 09:10:06PM -0400, Richard Barnes wrote:
> 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
of
> 0-RTT
>
> - Clarified what contents are expected in the "challenges" array
>
> Some more comments inline below. Comments addressed by PR / overcome by
> events trimmed.
>
>
> On Thu, Aug 30, 2018 at 8:06 PM Benjamin Kaduk wrote:
>
> > >
On Fri, Aug 31, 2018 at 01:46:24PM -0400, Richard Barnes wrote:
> 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:
> > >
> > > > Do you want to mention that the caaIdentities element gives
you
> suggest
> changes?
I mean, I think we *are* implicitly placing requirements on all (HTTP|DNS)
server operators, namely, to avoid the "several ways that these assumptions
can be violated, both by misconfiguration and by attacks". So the only
sort of text that I would cons
On Sun, Sep 16, 2018 at 05:35:37PM +0200, Felix Fontein wrote:
> Hi,
>
> > > >[...] Secondly, the entropy requirement
> > > >prevents ACME clients from implementing a "naive" validation
> > > > server that automatically replies to challenges without
> > > > participating in the creation of
On Sun, Sep 16, 2018 at 10:41:42AM -0500, Benjamin Kaduk wrote:
> On Sun, Sep 16, 2018 at 05:35:37PM +0200, Felix Fontein wrote:
> > Hi,
> >
> > > > >[...] Secondly, the entropy requirement
> > > > >prevents ACME clients from implementi
On Sun, Sep 16, 2018 at 10:42:26PM +0200, Felix Fontein wrote:
> Hi,
>
> > > > > > >[...] Secondly, the entropy requirement
> > > > > > >prevents ACME clients from implementing a "naive"
> > > > > > > validation server that automatically replies to challenges
> > > > > > > without particip
> This would be § 4.4.2 of RFC 8446
>
> Thanks. Added a ref to RFC 8446.
>
> > Well now I'm really confused. If I look at the example exchanges for the
> HTTP challenge.
>
> Apologies. I forgot that the HTTP-01 challenge type does send the token in
> the
> req
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 think I understand why "no
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:
> > > On Fri, Sep 14, 2018 at 03:59:07PM -0400, Daniel McCarney wrote:
> >
On Sun, Oct 21, 2018 at 05:25:40PM +, Salz, Rich wrote:
> * It does not seem to be related to ACME - that is, what you’re
> describing is more broadly a set of concerns with the methods that may be
> used to validate a domain.
>
> Perhaps ACME isn’t the right place for this, perhaps it s
On Thu, Jun 06, 2019 at 07:52:33AM +0100, Hugo Landau wrote:
> Sorry, I somehow missed this one.
>
> > --
> > DISCUSS:
> > --
> >
> > I think we need to have som
On Fri, Jul 12, 2019 at 02:03:14AM +, Rob Stradling wrote:
> On 11/07/2019 20:50, Yoav Nir wrote:
> > Hi, all
> >
> > We are putting together the agenda for IETF 105.
>
> > If you have some other business for the WG meeting, please bring it up now.
>
> Do the 6 "Reported" errata for RFC8555
I don't have much to add, but...
On Tue, Jul 16, 2019 at 05:44:39PM +0100, Stephen Farrell wrote:
>
> Hiya,
>
> On 15/07/2019 17:00, Ted Hardie wrote:
> > Howdy,
> >
> > A reply in-line.
> >
> > On Sun, Jul 14, 2019 at 2:07 PM Stephen Farrell
> > wrote:
> >
> >>
> > So, if I were personally
On Thu, Oct 03, 2019 at 12:59:47PM +, Thomas Fossati wrote:
> Hi Ben,
>
> First of all thank you very much for this excellent review.
>
> On your DISCUSS points:
>
> On 02/10/2019, 19:06, "Benjamin Kaduk via Datatracker"
> wrote:
> > RFC 8555
Hi Jacob,
On Wed, Oct 02, 2019 at 10:52:55AM -0700, Jacob Hoffman-Andrews wrote:
> On 9/30/19 6:07 PM, Benjamin Kaduk via Datatracker wrote:
> > the provider. When the TLS SNI challenge was designed it was assumed
> > that a user would only be able to respond to TLS traf
On Mon, Sep 30, 2019 at 09:17:40AM +, Thomas Fossati wrote:
> Hi Alexey,
>
> > I was talking about rules for adding new values to these 2
> > subregistries. E.g. “Expert Review”, “Specification Required”,
> > “IETF Review”, etc.
>
> Ah, thanks for the clarification!
>
> I don't see a reason
On Thu, Oct 03, 2019 at 05:33:49PM +, Thomas Fossati wrote:
> Hi Ben,
>
> Upon further review, I agree with your assessment on the first part of
> your DISCUSS, which is a relief.
>
> I'm addressing your COMMENTs [1] and the second part of your DISCUSS
> [2] that are for the most part straigh
On Tue, Oct 08, 2019 at 10:07:12AM +, Thomas Fossati wrote:
> Hi Ben,
>
> On 05/10/2019, 02:07, "Benjamin Kaduk" wrote:
> > On Thu, Oct 03, 2019 at 05:33:49PM +, Thomas Fossati wrote: I'm
> > trying to think about the risk that a future use case for
&g
Authors, should this be marked Verified?
Thanks,
Ben
On Fri, Feb 14, 2020 at 10:18:53AM -0800, RFC Errata System wrote:
> The following errata report has been submitted for RFC8555,
> "Automatic Certificate Management Environment (ACME)".
>
> --
> You may rev
That does seem quite likely, thanks for pointing it out, Roland.
With respect to the report itself (noting that the proposed change is from
"200 (OK)" to "204 (No Content)"), I note that the response status code is
not considered to be a "header field" and so the quoted text from RFC 7231
does not
A bit further afield than many of the current use-cases, but perhaps
interesting to think about...
-Ben
On Fri, Jun 05, 2020 at 08:37:30PM +, Brian Sipos wrote:
> All,
> On the AD advice to give more thought to the security aspects of "how does a
> TCPCL PKIX certificate come to be?" I have
On Tue, Aug 18, 2020 at 02:16:12PM -0600, Matt Holt wrote:
> Hi,
>
> After working heavily with ACME clients for the past 5 years (including
> "ACMEv1" before RFC 8555) I've come to realize some unfortunate
> ambiguities/inefficiencies in RFC 8555 with regards to server behavior after
> a chall
Hi Alexey,
On Thu, Nov 05, 2020 at 11:07:02AM +, Alexey Melnikov wrote:
> Hi Ben,
>
> I am sending you a partial reply, as I am still editing the document
> based on some of your more detailed comments:
Sure, happy to handle things in batches.
> On 05/11/2020 08:03, Ben
Ben,
>
> On 06/11/2020 22:29, Benjamin Kaduk wrote:
> > Hi Alexey,
> >
> > On Thu, Nov 05, 2020 at 11:07:02AM +, Alexey Melnikov wrote:
> >> Hi Ben,
> >>
> >> I am sending you a partial reply, as I am still editing the document
> >> b
Hi Alexey,
On Thu, Nov 12, 2020 at 04:28:39PM +, Alexey Melnikov wrote:
> Hi Ben,
>
> On 05/11/2020 08:03, Benjamin Kaduk via Datatracker wrote:
> > The more straightforward point is that the procedure in section 3
> > indicates that token-part2 is returned to the A
Hi Fraser,
On Sat, Nov 14, 2020 at 02:47:03PM +1000, Fraser Tweedale wrote:
> On Thu, Nov 12, 2020 at 03:48:25PM -0800, Benjamin Kaduk wrote:
> > On a related note, the thread with Fraser, combined with our live
> > discussion earlier today, made me realize that we really should s
Hi Sebastian,
On Fri, Nov 20, 2020 at 07:05:08PM +0100, Sebastian Nielsen wrote:
> The certificates can have different extended key usages, either digital
> signature or encryption - and thus an email client will automatically pick
> the right certificate.
>
> However, the reason the same key sho
Hi Brian,
On Fri, Apr 16, 2021 at 09:28:14PM +, Brian Sipos wrote:
> Ryan,
> Thank you for the review comments. My responses are inline with prefix
> "[BS1]".
>
> > With admittedly very little context for this specific use case, a few
> > things stand out:
>
> > Section 2 states "Any identi
dress are listed below, along with the
> reasons why we decided to avoid changing the existing text.
>
> On 08/04/2021, 05:47, "Benjamin Kaduk via Datatracker"
> wrote:
> > Section 2.3.2
> > [...]
> >
> >* MUST NOT contain the "notBefore"
e below for the detail.
>
> On 10/06/2021, 08:00, "Benjamin Kaduk" wrote:
> > Section 3
> >
> >Although most of this document, and in particular Section 2 is
> >focused on the protocol between the NDC and to IdO, the protocol does
> >affect th
With apologies for focusing on a different aspect than you are attempting
to focus on...
On Sun, Nov 07, 2021 at 12:00:20AM +0900, Seo Suchan wrote:
> After RFC8823 I though it would be trivial to apply its process for TLS
> certificate by verify email of various authoized Email address (like
>
Forwarding this last-call announcement as it may be of interest to folks on
these lists.
Please send comments to last-c...@ietf.org.
Thanks,
Ben
- Forwarded message from The IESG -
Date: Tue, 09 Nov 2021 03:53:17 -0800
From: The IESG
To: IETF-Announce
Cc: mjethanand...@gmail.com, dr
Is there particular guidance from Section 10 that you had in mind to
justify the following of the redirect?
In light of the role of errata reports as indicating errors in the
specification at the time it was published, I think the processing options
here are either "hold for document update" or "r
On Thu, Feb 10, 2022 at 02:31:15PM -0500, Michael Richardson wrote:
>
> J.C. Jones wrote:
> > Hence, I propose we add an optional field to the ARI response
> > structure, "explanationURL", which when populated should be presented
> > in any user-visible context (logging, alerting, etc
On Thu, Apr 20, 2023 at 07:46:43AM -0400, Deb Cooley wrote:
> ACME,
>
> We are considering converting draft-ietf-acme-integrations from
> informational to standards track. If anyone objects, please reply on this
> list by 5 May 2023.
Could we say a little more in this thread about why we want to
On Sat, Apr 22, 2023 at 05:56:35PM -0400, Michael Richardson wrote:
>
> Benjamin Kaduk wrote:
>
> >> We are considering converting draft-ietf-acme-integrations from
> >> informational to standards track. If anyone objects, please reply on
> th
Hi all,
This draft is marked as "Replaces: draft-ietf-acme-scoped-dns-challenges".
Is the intent only to replace that document to the extent that it
previously defined the dns-account-01 challenge (but to continue to
progress draft-ietf-acme-scoped-dns-challenges for the dns-02 challenge)?
I think
Hi Deb,
That matches my understanding of the proposal.
(I always get a bit nervous about using "Verified" for new text that points to
references that didn't exist at the time of the publication of the original
RFC, but maybe that's just me. And I guess draft-ietf-dnsop-svcb-httpssvc was
around t
On Wed, Apr 16, 2025 at 12:44:32PM -0400, Erik Nygren wrote:
> So perhaps:
>
> "(The HTTP client MUST NOT resolve and/or MUST ignore any HTTPS DNS RRs
> [RFC 9460].
> It also MUST NOT automatically apply an HSTS behavior to auto-upgrade to
> the HTTPS scheme.)". ?
A "MUST NOT ... and/or MUST ..
Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-caa-07: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-caa-09: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-ip-07: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-tls-alpn-06: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-star-09: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-star-10: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-email-smime-10: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-email-smime-13: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-star-delegation-07: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-star-delegation-08: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-authority-token-07: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-authority-token-tnauthlist-08: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however
56 matches
Mail list logo
