[Acme] Draft-ietf-acme-onion comments.

[Deb Cooley]

 Before I click the button to put this draft into IETF last call, I have a
few easy comments:


Section 2:  The way to avoid an error by idnits is to say:  "described in
BCP 14 [RFC2119] [RFC8174]"  where the two RFCs in [] are linked.

Section 3.1.2:  Someone on the IESG may comment about needing text to
describe why one might not follow redirects, or why a server might not
honor those. (SHOULDs in the second paragraph).

Section 3.2, nonce:  "A response generating using this nonce MUST NOT be
accepted by the ACME server if the nonce was generated more than 30 days
ago."
1.  Typo: 'response generating'?  should be 'response generated'? or
something else?
2.  How will the server (?) know the nonce was generated more than 30 days
ago?  (and if there is a time stamp on the nonce, how will the server know
that the client isn't lying?) (and if the server generates the nonce, but
the client doesn't respond w/in 30 days, then this needs to be more clear)

Section 3.2, caSigningNonce:  bytes?  Maybe bits?...or maybe binary? Or is
it obvious?

Section 3.2, 'Client respond with ...:  Typo - either 'clients respond' or
'client responds'.

Section 6.1, last sentence:  There is a 'MUST not'.  I'm assuming this
should be 'MUST NOT'.  (again an idnits flag)


Thanks for doing the work on this draft!

Deb
___
Acme mailing list -- acme@ietf.org
To unsubscribe send an email to acme-le...@ietf.org

[Acme] Re: More detailed checking interval in ARI

[Deb Cooley]

Aaron,

You can issue a new version of the draft, even as it sits in my queue.  I'd
prefer you do that before I start my review.

Deb

On Mon, Nov 4, 2024 at 11:18 PM Aaron Gable  wrote:

> Thanks Yoav!
>
> I've already spoken with Jacob about this change offline, and plan to
> bring it up as part of my timeslot this week. You're absolutely right that
> it doesn't affect any of the bits on the wire; it's just instructions on
> client behavior. I'm in favor of incorporating this language (or a slightly
> edited version of it); I'm just unfamiliar with the process for
> incorporating changes like this as we move out of WGLC and into IESG.
>
> Aaron
>
> On Mon, Nov 4, 2024 at 12:34 PM Yoav Nir  wrote:
>
>> Thanks for that.
>>
>> If I’m reading this correctly, this is all clarification, not
>> bits-on-the-wire changes. Changes like that can be added after WGLC if they
>> don’t raise objections.
>>
>> I see that you are not registered for the IETF meeting, so it probably
>> doesn’t make sense to discuss it at the ACME session, but we’ll mention
>> that the PR exists, and the discussion can continue on the mailing list.
>>
>> Yoav
>>
>> On 29 Oct 2024, at 22:09, Jacob Hoffman-Andrews > 40letsencrypt@dmarc.ietf.org> wrote:
>>
>> Hi all, and especially to Yoav and Aaron for getting the ARI draft
>> through Last Call.
>>
>> I'm very sorry to make a substantive proposal _after_ Last Call, but
>> after talking to a client author I became concerned that we're not being
>> explicit enough about how frequently clients should check. I've just
>> uploaded this PR:
>>
>> https://github.com/aarongable/draft-acme-ari/pull/82
>>
>> For convenience, I'm reproducing the added sections below:
>>
>> ## Schedule for checking RenewalInfo objects
>>
>> RenewalInfo objects must be fetched frequently so that clients learn
>> about renewal quickly. But requests must not overwhelm the server. This
>> protocol uses the Retry-After header to indicate to clients how often to
>> retry. Note that in other HTTP applications, Retry-After often indicates
>> the earliest time to retry a request. In this protocol, it indicates both
>> the earliest time and a target time.
>>
>> Clients SHOULD fetch a certificate's RenewalInfo object immediately after
>> issuance. After that, clients SHOULD fetch the certificate's RenewalInfo as
>> soon as possible after the time indicated in the Retry-After header
>> (backoff on errors takes priority, though). Clients SHOULD set reasonable
>> limits on the value in the Retry-After header. For instance, values under 1
>> minute should be treated as if they were one minute and values over one day
>> should be treated as if they were one day.
>>
>> Clients SHOULD stop checking RenewalInfo after a certificate is expired.
>> Clients SHOULD stop checking RenewalInfo after they consider a certificate
>> to be replaced (for instance, after a new certificate for the same
>> identifiers has been received and configured).
>>
>> ### Error handling
>>
>> Temporary errors include, for instance:
>>
>>   - Connection timeout
>>   - Request timeout
>>   - 5xx HTTP errors.
>>
>> On receiving a temporary error, clients SHOULD do exponential backoff
>> with a capped number of tries. If all tries are exhausted, clients SHOULD
>> treat the request as a long-term error.
>>
>> Long term errors include, for instance:
>>
>>   - Retry-After is invalid or not present
>>   - RenewalInfo object is invalid
>>   - DNS lookup failure
>>   - Connection refused
>>   - Non-5xx HTTP error
>>
>> On receiving a long term error, clients SHOULD perform the next
>> RenewalInfo fetch as soon as possible after six hours have passed (or some
>> other locally configured default).
>>
>> ### Server choice of Retry-After
>>
>> Servers set the Retry-After header based on their requirements on how
>> quickly to perform a revocation. For instance, a server that needs to
>> revoke certificates within 24 hours of notification of a problem might
>> choose to reserve twelve hours for investigation, six hours for clients to
>> fetch RenewalInfo, and six hours for clients to perform a renewal. Setting
>> a small value for Retry-After means that clients can respond more quickly,
>> but also incurs more load on the server. Servers should estimate their
>> expected load based on the number of clients, keeping in mind that third
>> parties may also monitor RenewalInfo endpoints.
>> ___
>> Acme mailing list -- acme@ietf.org
>> To unsubscribe send an email to acme-le...@ietf.org
>>
>>
>> ___
>> Acme mailing list -- acme@ietf.org
>> To unsubscribe send an email to acme-le...@ietf.org
>>
> ___
> Acme mailing list -- acme@ietf.org
> To unsubscribe send an email to acme-le...@ietf.org
>
___
Acme mailing list -- acme@ietf.org
To unsubscribe send an email to acme-le...@ietf.org

[Acme] IETF 119 briefings and agenda items

[Deb Cooley]

acme!

Meeting week is almost here, hopefully your travel plans are going
smoothly.  Don't forget to post your briefings under the meeting materials
link (or email them to the chairs).

I'm happy to add a discussion item for discussing an 8555bis document, or
it can be covered in AOB.

[Yoav will be remote, and Tomofumi will be local (be kind - working group
chair initiation by fire).  I will also be remote and officially your SecAD
by then.]

Deb
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] IETF 119 Agenda

[Deb Cooley]

Amir,

We will miss you, but have a happy Nowruz!   Look forward to seeing/hearing
you at IETF 120.

If you want to send a short status, we can present it for you.  But that is
completely up to you.

Deb

On Thu, Mar 7, 2024 at 1:22 PM Amir Omidi  wrote:

> I am not going to be able to present or attend this time around. (It's
> Nowruz, and to anyone else who celebrates it, happy Nowruz!)
>
> I will probably be presenting in person in Vancouver for the next session.
>
> For folks who haven't seen it yet, please take a look at the updated draft
> for dns-account-01, and let me know if you have any questions or concerns
> about this so far!
> https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/
>
> Cheers!
>
>
> On Thu, Mar 7, 2024 at 11:31 AM Deb Cooley  wrote:
>
>> Attached is an agenda update.  I added a couple of presentations (TY),
>> and fixed some typos.
>>
>> If the presenters can post their briefings to the meeting link (found on
>> the acme datatracker page), it would be much appreciated.  [if there are
>> issues, then please send to the chairs - I've cc'd the alias on this
>> message.]
>>
>> Deb
>>
>> 
>>
>> Automated Certificate Management Environment (acme)
>>
>> IETF 119, Thursday, 21 March 2024 1530-1700 (AUS Eastern Time  (0530-0700
>> UTC) , Room: M1
>>
>> Preliminary Agenda v2
>>
>> Note Well, technical difficulties and administrivia (chairs) – 10 min
>>
>> Document Status (chairs) – 10 min
>>
>> Work items
>>
>>  - draft-ietf-acme-dtnnodeid (Sipos - remote) 5 min
>>  - draft-ietf-acme-ari (Gable - remote) - 10 min
>>  - draft-acme-device-attest (Weeks - remote) - 10 min
>>  - draft-ietf-acme-onion (Misell - remote) - 10 min
>>  - draft-sweet-iot-acme (Sweet - remote) - 10 min
>>  - draft-vanbrouwershaven-acme-auto-discovery and
>>  - draft-vanbrouwershaver-acme-client-discovery (Ounsworth) - 15 min
>>
>> AOB - 10 min
>>
>> -
>>
>> On Thu, Mar 7, 2024 at 7:30 AM Deb Cooley  wrote:
>>
>>> This is what I have currently.  We have a 90 min time slot (no idea
>>> why), so there is time to talk about other work/drafts.  I'm happy to make
>>> updates.
>>>
>>> Deb
>>>
>>> -
>>> Automated Certificate Management Environment (acme)
>>>
>>> IETF 119, Thursday, 21 March 2024 1530-1700 (AUS Eastern Time
>>>  (0530-0700 UTC) , Room: M1
>>>
>>> Preliminary Agenda
>>>
>>> Note Well, technical difficulties and administrivia (chairs) – 10 min
>>>
>>> Document Status (chairs) – 10 min
>>>
>>> Work items
>>>
>>>  - draft-ietf-ari (Gable) - 10 min
>>>  - draft-acme-device-attest (Weeks) - 10 min
>>>  - draft-ietf-acme-onion (Misell - remote) - 10 min
>>>  - draft-vanbrouwershaven-acme-auto-discovery and
>>>  - draft-vanbrouwershaver-acme-client-discovery (vanBrouwershaven,
>>> Ounsworth) - 15 min
>>>
>>> AOB - 25 mins
>>> --
>>>
>>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] IETF 119 Agenda

[Deb Cooley]

Attached is an agenda update.  I added a couple of presentations (TY), and
fixed some typos.

If the presenters can post their briefings to the meeting link (found on
the acme datatracker page), it would be much appreciated.  [if there are
issues, then please send to the chairs - I've cc'd the alias on this
message.]

Deb


Automated Certificate Management Environment (acme)

IETF 119, Thursday, 21 March 2024 1530-1700 (AUS Eastern Time  (0530-0700
UTC) , Room: M1

Preliminary Agenda v2

Note Well, technical difficulties and administrivia (chairs) – 10 min

Document Status (chairs) – 10 min

Work items

 - draft-ietf-acme-dtnnodeid (Sipos - remote) 5 min
 - draft-ietf-acme-ari (Gable - remote) - 10 min
 - draft-acme-device-attest (Weeks - remote) - 10 min
 - draft-ietf-acme-onion (Misell - remote) - 10 min
 - draft-sweet-iot-acme (Sweet - remote) - 10 min
 - draft-vanbrouwershaven-acme-auto-discovery and
 - draft-vanbrouwershaver-acme-client-discovery (Ounsworth) - 15 min

AOB - 10 min
-

On Thu, Mar 7, 2024 at 7:30 AM Deb Cooley  wrote:

> This is what I have currently.  We have a 90 min time slot (no idea why),
> so there is time to talk about other work/drafts.  I'm happy to make
> updates.
>
> Deb
>
> -
> Automated Certificate Management Environment (acme)
>
> IETF 119, Thursday, 21 March 2024 1530-1700 (AUS Eastern Time  (0530-0700
> UTC) , Room: M1
>
> Preliminary Agenda
>
> Note Well, technical difficulties and administrivia (chairs) – 10 min
>
> Document Status (chairs) – 10 min
>
> Work items
>
>  - draft-ietf-ari (Gable) - 10 min
>  - draft-acme-device-attest (Weeks) - 10 min
>  - draft-ietf-acme-onion (Misell - remote) - 10 min
>  - draft-vanbrouwershaven-acme-auto-discovery and
>  - draft-vanbrouwershaver-acme-client-discovery (vanBrouwershaven,
> Ounsworth) - 15 min
>
> AOB - 25 mins
> --
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] IETF 119 Agenda

[Deb Cooley]

This is what I have currently.  We have a 90 min time slot (no idea why),
so there is time to talk about other work/drafts.  I'm happy to make
updates.

Deb

-
Automated Certificate Management Environment (acme)

IETF 119, Thursday, 21 March 2024 1530-1700 (AUS Eastern Time  (0530-0700
UTC) , Room: M1

Preliminary Agenda

Note Well, technical difficulties and administrivia (chairs) – 10 min

Document Status (chairs) – 10 min

Work items

 - draft-ietf-ari (Gable) - 10 min
 - draft-acme-device-attest (Weeks) - 10 min
 - draft-ietf-acme-onion (Misell - remote) - 10 min
 - draft-vanbrouwershaven-acme-auto-discovery and
 - draft-vanbrouwershaver-acme-client-discovery (vanBrouwershaven,
Ounsworth) - 15 min

AOB - 25 mins
--
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] IETF 119

[Deb Cooley]

If you would like to present at IETF 119 (either virtual or IRL), please
let the chairs know. The details of the meeting day/time are below.

We currently have requests for the discovery drafts, and I'm guessing the
attestation draft (although I'd like that confirmed).

 IETF 119  acme Session 1 (1:00 requested)
  Thursday, 21 March 2024, Session III 1530-1700 Australia/Brisbane
(0530-0700 UTC)
  Room Name: M1 [Breakout 3] (size: 125)


Deb and Yoav
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] acme-device-attest expired

[Deb Cooley]

I know Brandon has been busy, but I don't know his plans for this draft.
Maybe his use case has changed?  I've cc'd him on this message.

Note:  acme is a 'working group', to get a draft through the process people
have to be willing to work on the draft (vice merely following).  Also
drafts can certainly have multiple authors, perhaps an offer of helping as
an author might work.

Deb

On Tue, Feb 20, 2024 at 11:01 AM Prachi Jain 
wrote:

> Hello,
>
> I have been closely following this document as well and would like to know
> the status of the same.
>
> Thanks,
> Prachi
>
>
> On Sun, Feb 18, 2024 at 1:57 AM Thomas Fossati  wrote:
>
>> Hi, all,
>>
>> The acme-device-attest draft is expired.
>>
>> Just checking: what are the plans?
>>
>> cheers, thanks!
>>
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Deb Cooley]

The ADs can edit the language of an errata.  If we can agree on the
language, they can modify the errata and then mark it as Verified.  Below
is what I have for this:

--

Errata old:

Section 7.4.1, It should say:

If a server receives a newAuthz request for an identifier where the
authorization object already exists,
whether created by CA provisioning on the ACME server or by the ACME
server handling a previous newAuthz
request from a client, the server returns a 200 (OK) response with the
existing authorization URL in the
Location header field and the existing JSON authorization object in the body.

--

Errata new:

Section 7.4.1

It should say:
If the server has an existing authorization for the identifier,
depending on server policy, the server may return a 200 (OK)
response with the existing authorization URL in the Location header
field and the existing JSON authorization object in the body.
--

Is this correct?  Or does it need to be tweaked?

Deb


On Thu, Jan 4, 2024 at 1:29 PM Jacob Hoffman-Andrews  wrote:

> > That’s fair. The text should probably state something along the lines of
>
>  >
>
> > “If the server has an existing authorization for the identifier,
> depending on server policy, the server may return a 200 (OK) response with
> the existing authorization URL in the Location header field and the
> existing JSON authorization object in the body.”
>
> This sounds good to me. Thanks for the update.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Deb Cooley]

I'm going to extend this WGLC a couple of more days to 2 Feb 2024.  I'm
hoping to see a couple of more reviews, please.

Deb Cooley

On Fri, Jan 12, 2024 at 7:00 AM Deb Cooley  wrote:

> This is the beginning of a two week WGLC for this draft, which will end on
> 26 Jan.
>
> Please review and comment.
>
> Deb C
> ACME WG Chair
>
> On Thu, Jan 11, 2024 at 4:26 PM  wrote:
>
>> Internet-Draft draft-ietf-acme-dtnnodeid-12.txt is now available. It is a
>> work
>> item of the Automated Certificate Management Environment (ACME) WG of the
>> IETF.
>>
>>Title:   Automated Certificate Management Environment (ACME)
>> Delay-Tolerant Networking (DTN) Node ID Validation Extension
>>Author:  Brian Sipos
>>Name:draft-ietf-acme-dtnnodeid-12.txt
>>Pages:   31
>>Dates:   2024-01-11
>>
>> Abstract:
>>
>>This document specifies an extension to the Automated Certificate
>>Management Environment (ACME) protocol which allows an ACME server to
>>validate the Delay-Tolerant Networking (DTN) Node ID for an ACME
>>client.  A DTN Node ID is an identifier used in the Bundle Protocol
>>(BP) to name a "singleton endpoint", one which is registered on a
>>single BP node.  The DTN Node ID is encoded as a certificate Subject
>>Alternative Name (SAN) of type otherName with a name form of
>>BundleEID and as an ACME Identifier type "bundleEID".
>>
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-12.html
>>
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-acme-dtnnodeid-12
>>
>> Internet-Drafts are also available by rsync at:
>> rsync.ietf.org::internet-drafts
>>
>>
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Deb Cooley]

Also a late review (sigh).  All of mine are typos, so they should be easy
to fix.


Section 1.4, Endpoint ID def:  typo:  I think you need a comma here:  'An
endpoint can be a singleton or not [,] so an Endpoint ID can also...'

Section 2, para 1, sentence 2:  typo: 'an Bundle Endpoint' sb 'a Bundle
Endpoint'.

Section 2, para 4, last sentence:  typo: 'via scheme-specific means [is]
authorized'?

Deb Cooley
no hats

On Mon, Jan 29, 2024 at 7:18 PM Stephen Farrell 
wrote:

>
> Hiya,
>
> On 12/01/2024 12:00, Deb Cooley wrote:
> > This is the beginning of a two week WGLC for this draft, which will end
> on
> > 26 Jan.
> >
> > Please review and comment.
>
> Sorry for the slightly late review.
>
> I previously reviewed -09 of this and think the changes since then,
> (perhaps partly in response to that review), nicely capture the nature
> of the experiment being done here, are well-stated in the draft and
> are sufficient for publication of an experimental RFC. (As a nit, some
> of those changes have enhanced visibility in the text version but not
> in the HTML - I like the way the text version calls our those bits of
> text myself fwiw, e.g. in the last para before 1.1.)
>
> I mostly reviewed the diff from -09 to -12 and haven't implemented
> either a client or server for this but the nitty details look fairly
> sane for an experimental RFC.
>
> If there were one thing I'd suggest adding, it'd be to describe a
> DTN scenario where the multi-perspective thing was ineffective, from
> the vantage point(s) of a CA. I think that might help people doing
> experiments figure out some things to look out for, or might help
> some CA decide to play-ball in an experiment if they don't have to
> discover the problem themselves. (A known problem there is a DTN where
> all traffic between the CA and DTN nodes has to go via one (set of)
> agents all under the control of a potential attacker.) I don't think
> such text is required for publication, but spelling it out in 3.5 or
> the security considerations would be nicer I think.
>
> I see Rob has commented that he doesn't see how this draft can garner
> IETF consensus. I don't get that objection(*) as ISTM the IETF can of
> course reach consensus to enable experiments related to DTN security and
> key management, which are both fairly tricky topics where improvements
> will (I think) benefit from experimentation of this kind. (Or to put
> it negatively, without experiments like this, we'll likely not see
> improvements in DTN security and key management.)
>
> So, yes, I think this is ready to move along to IETF LC and to become
> an experimental RFC.
>
> Cheers,
> S.
>
> (*) WRT IETF consensus, we're not there yet since IETF LC hasn't
> started, so it's puzzling to object that we can't get that when
> WGLC is only now under way.
>
>
>
> >
> > Deb C
> > ACME WG Chair
> >
> > On Thu, Jan 11, 2024 at 4:26 PM  wrote:
> >
> >> Internet-Draft draft-ietf-acme-dtnnodeid-12.txt is now available. It is
> a
> >> work
> >> item of the Automated Certificate Management Environment (ACME) WG of
> the
> >> IETF.
> >>
> >> Title:   Automated Certificate Management Environment (ACME)
> >> Delay-Tolerant Networking (DTN) Node ID Validation Extension
> >> Author:  Brian Sipos
> >> Name:draft-ietf-acme-dtnnodeid-12.txt
> >> Pages:   31
> >> Dates:   2024-01-11
> >>
> >> Abstract:
> >>
> >> This document specifies an extension to the Automated Certificate
> >> Management Environment (ACME) protocol which allows an ACME server
> to
> >> validate the Delay-Tolerant Networking (DTN) Node ID for an ACME
> >> client.  A DTN Node ID is an identifier used in the Bundle Protocol
> >> (BP) to name a "singleton endpoint", one which is registered on a
> >> single BP node.  The DTN Node ID is encoded as a certificate Subject
> >> Alternative Name (SAN) of type otherName with a name form of
> >> BundleEID and as an ACME Identifier type "bundleEID".
> >>
> >> The IETF datatracker status page for this Internet-Draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/
> >>
> >> There is also an HTML version available at:
> >> https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-12.html
> >>
> >> A diff from the previous version is available at:
> >> https://author-tools.ietf.org/iddiff?url2=draft-ietf-acme-dtnnodeid-12
> >>
> >> Internet-Drafts are also available by rsync at:
> >> rsync.ietf.org::internet-drafts
> >>
> >>
> >> ___
> >> Acme mailing list
> >> Acme@ietf.org
> >> https://www.ietf.org/mailman/listinfo/acme
> >>
> >
> >
> > ___
> > Acme mailing list
> > Acme@ietf.org
> > https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Errata Held for Document Update] RFC8555 (6843)

[Deb Cooley]

Again 'hold for update' is the only logical choice.  We aren't fixing vague
language with an errata.  When this RFC comes up for update, I hope you
will participate.

Deb

On Mon, Jan 15, 2024 at 7:41 AM Rob Sayre  wrote:

> On Mon, Jan 15, 2024 at 3:42 AM Deb Cooley  wrote:
>
>>   Items being brought up for discussion need to have specific and
>> concrete examples within scope.
>>
>
> I think the issue is that the spec is not specific or concrete:
>
> "Because many web servers
> allocate a default HTTPS virtual host to a particular low-privilege
> tenant user in a subtle and non-intuitive manner, the challenge must
> be completed over HTTP, not HTTPS."
>
> That sentence is very vague, and also seems to preclude HSTS as specified
> in RFC 6797.*
>
> I can understand that HTTP (rather than HTTPS) might need to be used
> sometimes, but requiring it seems to conflict with HSTS, and enable the
> exact attack HSTS aims to address. The erratum suggests a redirect, but
> HSTS also aims to avoid that. At first, I thought there might be a
> bootstrapping problem. But, if that were the case, the redirect in the
> erratum wouldn't work either.
>
> thanks,
> Rob
>
> * https://datatracker.ietf.org/doc/html/rfc6797
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Errata Held for Document Update] RFC8555 (6843)

[Deb Cooley]

Given the discussion and lack of consensus it is clear to me that 'hold for
update' is the right call for this errata.

In addition, we need to keep our discussions polite on this list, there
will be no bullying here.  Items being brought up for discussion need to
have specific and concrete examples within scope.

Deb
ACME chair

On Mon, Jan 15, 2024 at 12:54 AM Rob Sayre  wrote:

>
>
> On Sun, Jan 14, 2024 at 9:12 PM Aaron Gable  wrote:
>
>> On Sun, Jan 14, 2024, 10:12 Rob Sayre  wrote:
>>
>>> On Sun, Jan 14, 2024 at 3:01 AM Deb Cooley  wrote:
>>>
>>>> I had this marked as 'hold for update' (vs. 'verified').  I can't tell
>>>> from the discussion how you think we should be handling it.
>>>>
>>>
>>> The erratum says "the challenge must be initiated over HTTP, not
>>> HTTPS.", which is a little better than the current draft, in my opinion.
>>>
>>
>> To be clear, the document being discussed is not a draft, it's a full RFC
>> which was finalized five years ago.
>>
>
> That's twice now. Just stop with this stuff. Do you seriously think I
> don't understand IETF procedures?
>
> While you're correct that HSTS preload lists (there are multiple) are not
>> just for browsers, they are just for the applications and platforms that
>> maintain them. ACME clients do not generally run on such platforms, they
>> usually run on server operating systems. They are under no obligation to
>> use any HSTS preload list (which are not part of the HSTS spec), if there
>> even was an obvious list for them to use.
>>
>
> Your protocol is insecure.
>
> thanks,
> Rob
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Errata Held for Document Update] RFC8555 (6843)

[Deb Cooley]

I had this marked as 'hold for update' (vs. 'verified').  I can't tell from
the discussion how you think we should be handling it.

I'm also not sure why .dev domains are being discussed.  How are .dev
domains obtaining test certificates (because one should not be issuing
operational certificates, right?).

Deb

On Thu, Jan 11, 2024 at 10:21 PM Rob Sayre  wrote:

> On Thu, Jan 11, 2024 at 7:15 PM Amir Omidi  wrote:
>
>> There is nothing blocking .dev domains responding over http. To be
>> specific, a TLD can not block a protocol like that.
>>
>
> Right, but one should not expect to get a redirect response. The server
> shouldn't answer (many of them do, which is a bug). I filed the bug on iOS
> for this one. They did fix it in short order. :)
>
> thanks,
> Rob
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Deb Cooley]

This is the beginning of a two week WGLC for this draft, which will end on
26 Jan.

Please review and comment.

Deb C
ACME WG Chair

On Thu, Jan 11, 2024 at 4:26 PM  wrote:

> Internet-Draft draft-ietf-acme-dtnnodeid-12.txt is now available. It is a
> work
> item of the Automated Certificate Management Environment (ACME) WG of the
> IETF.
>
>Title:   Automated Certificate Management Environment (ACME)
> Delay-Tolerant Networking (DTN) Node ID Validation Extension
>Author:  Brian Sipos
>Name:draft-ietf-acme-dtnnodeid-12.txt
>Pages:   31
>Dates:   2024-01-11
>
> Abstract:
>
>This document specifies an extension to the Automated Certificate
>Management Environment (ACME) protocol which allows an ACME server to
>validate the Delay-Tolerant Networking (DTN) Node ID for an ACME
>client.  A DTN Node ID is an identifier used in the Bundle Protocol
>(BP) to name a "singleton endpoint", one which is registered on a
>single BP node.  The DTN Node ID is encoded as a certificate Subject
>Alternative Name (SAN) of type otherName with a name form of
>BundleEID and as an ACME Identifier type "bundleEID".
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-12.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-acme-dtnnodeid-12
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Deb Cooley]

 My question to you would be:  which RFC will make the most impact?  Seems
like your comments weren't really targeted at ACME per se, but at how to
measure entropy using Base64 encoding?  I have not read RFC 4086 closely,
but an RFC like that would impact all of them.

Just my thoughts...
Deb Cooley

On Fri, Jan 5, 2024 at 7:43 AM  wrote:

> Thanks for that.
>
> Well, I stand by my detailed comments of (checks dates) two years ago.
> Which I had forgotten I ever even made!
>
> I know, covid and all, but lately in the past few years I’ve
> been sensing a vibe of why-even-bother-submitting errata anyway. (and
> sitting in a Tokyo airport transit lounge, heavily jetlagged, is really not
> the place for me to do any detailed analysis.)
>
> Perhaps reframing it as some security concern, since entropy, might prompt
> wider review? security types are quite keen on this stuff, and do tend to
> like rigour in specifications to close off implementation misunderstandings
> loopholes.
>
> best
>
> Lloyd Wood
> lloyd.w...@yahoo.co.uk
>
> On Friday, January 5, 2024, 21:14, Deb Cooley 
> wrote:
>
> I did some reading, some consulting, and some pondering.  I want to reject
> this errata.
>
> 1.  The original paragraph:
>
> token (required, string):  A random value that uniquely identifies
>   the challenge.  This value MUST have at least 128 bits of entropy.
>   It MUST NOT contain any characters outside the base64url alphabet
>   and MUST NOT include base64 padding characters ("=").  See
>   [RFC4086] for additional information on randomness requirements.
>
> In my opinion this is sufficient.  It specifies how much entropy (w/ a ref), 
> and specifies what cannot be included (padding, non-base54 characters).
>
> Let me know if you have other thoughts.
>
> Deb
>
>
> On Thu, Jan 4, 2024 at 7:41 AM Deb Cooley  wrote:
>
> opinions?  Does entropy have to be measured as a base64 encoded value?
>
> Deb
>
> On Mon, May 2, 2022 at 4:31 AM RFC Errata System <
> rfc-edi...@rfc-editor.org> wrote:
>
> The following errata report has been submitted for RFC8555,
> "Automatic Certificate Management Environment (ACME)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6950
>
> --
> Type: Technical
> Reported by: Lloyd Wood 
>
> Section: GLOBAL
>
> Original Text
> -
> token (required, string):  A random value that uniquely identifies
>   the challenge.  This value MUST have at least 128 bits of entropy.
>
> Corrected Text
> --
> token (required, string):  A random value that uniquely identifies
>   the challenge.  This value MUST have at least 128 bits of entropy,
> which in the
>   base64url alphabet means a minimum string length of 22 characters if
> the full
>   scope of the base64url alphabet is in use in the token, by:
> log2(64^22) = 132 bits of entropy
>
>
>
> Notes
> -
> This standards-track document doesn't specify the string ramifications for
> entropy; I'd expect it to be called out to implementers, just the once, and
> then referred to later at other tokens.
>
> If entropy is log2 the number of possible characters (64 if full base64url
> set of chars is in use) then
> log2 (64^21) = 126
> log2 (64^22) = 132
>
> so a minimum of 22 characters are needed to get a minimum of 128 bits of
> entropy in the token.
>
> But, if the random value is specified using a subset of the base64url, say
> because the implementer doesn't like or use CAPITALS or (most likely) the
> punctuation symbols, then the token must necessarily be longer to meet the
> local implementer entropy requirement (though just losing only the
> punctuation marks means you're still good and meet the requirement with 22
> characters). Not sure that matters so much on the wire.
>
> I also have editing nits about base64url being defined clearly in ABNF
> just for Replay-Nonce:, but then both 'base64 alphabet' and 'base64url
> alphabet' are in use in the document, and base64url references are to
> RFC4648 via RFC7515, but those are to Base64url, not to base64url... it all
> seems a bit inconsistent editingwise. So all the references to 'base64
> alphabet' should be to 'base64url alphabet' as defined in the doc, but it
> should really be 'Base64url alphabet' to be consistent with references?
>
> (I really think that it should have been called 'Base-64_url alphabet' way
> back when to enphasise the punctuation use, but that ship has sailed.)
&

Re: [Acme] [Editorial Errata Reported] RFC8823 (7508)

[Deb Cooley]

This one came is as Editorial and was changed to Technical.  I think we
should make it Editorial.

There needs to be a complete list of places where .com and .org are
swapped.

At that point it can be 'Verified'.

Deb



On Tue, Oct 10, 2023 at 7:52 PM Chris Smiley  wrote:

>
> Hi Roman,
>
> We are unable to verify this erratum that the submitter marked as
> editorial.
> Please note that we have changed the “Type” of the following errata
> report to “Technical”. As Stream Approver, please review and set the
> Status and Type accordingly (see the definitions at
> https://www.rfc-editor.org/errata-definitions/).
>
> You may review the report at:
> https://www.rfc-editor.org/errata/eid7508
>
> Please see https://www.rfc-editor.org/how-to-verify/ for further
> information on how to verify errata reports.
>
> Further information on errata can be found at:
> https://www.rfc-editor.org/errata.php.
>
> Thank you.
>
> RFC Editor/cs
>
>
>
> > On May 4, 2023, at 5:01 PM, RFC Errata System 
> wrote:
> >
> > The following errata report has been submitted for RFC8823,
> > "Extensions to Automatic Certificate Management Environment for End-User
> S/MIME Certificates".
> >
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid7508
> >
> > --
> > Type: Editorial
> > Reported by: Richard Wang 
> >
> > Section: 3.1 and 3.2
> >
> > Original Text
> > -
> > Figure 1:
> >  Message-ID: 
> >  From: acme-genera...@example.org
> >  To: ale...@example.com
> >
> > Figure 2:
> >   Message-ID: <111-2-...@example.com>
> >   In-Reply-To: 
> >   From: ale...@example.com
> >   To: acme-genera...@example.org
> >
> > Corrected Text
> > --
> > Figure 1:
> >  Message-ID: 
> >  From: acme-genera...@example.com
> >  To: ale...@example.org
> >
> > Figure 2:
> >   Message-ID: <111-2-...@example.org>
> >   In-Reply-To: 
> >   From: ale...@example.org
> >   To: acme-genera...@example.com
> >
> > Notes
> > -
> > Accoording to RFC8555, the domain example.com used for ACME server, the
> example.org used for the Client.
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --
> > RFC8823 (draft-ietf-acme-email-smime-14)
> > --
> > Title   : Extensions to Automatic Certificate Management
> Environment for End-User S/MIME Certificates
> > Publication Date: April 2021
> > Author(s)   : A. Melnikov
> > Category: INFORMATIONAL
> > Source  : Automated Certificate Management Environment
> > Area: Security
> > Stream  : IETF
> > Verifying Party : IESG
> >
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Deb Cooley]

I did some reading, some consulting, and some pondering.  I want to reject
this errata.

1.  The original paragraph:

token (required, string):  A random value that uniquely identifies
  the challenge.  This value MUST have at least 128 bits of entropy.
  It MUST NOT contain any characters outside the base64url alphabet
  and MUST NOT include base64 padding characters ("=").  See
  [RFC4086] for additional information on randomness requirements.

In my opinion this is sufficient.  It specifies how much entropy (w/ a
ref), and specifies what cannot be included (padding, non-base54
characters).

Let me know if you have other thoughts.

Deb


On Thu, Jan 4, 2024 at 7:41 AM Deb Cooley  wrote:

> opinions?  Does entropy have to be measured as a base64 encoded value?
>
> Deb
>
> On Mon, May 2, 2022 at 4:31 AM RFC Errata System <
> rfc-edi...@rfc-editor.org> wrote:
>
>> The following errata report has been submitted for RFC8555,
>> "Automatic Certificate Management Environment (ACME)".
>>
>> --
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid6950
>>
>> --
>> Type: Technical
>> Reported by: Lloyd Wood 
>>
>> Section: GLOBAL
>>
>> Original Text
>> -
>> token (required, string):  A random value that uniquely identifies
>>   the challenge.  This value MUST have at least 128 bits of entropy.
>>
>> Corrected Text
>> --
>> token (required, string):  A random value that uniquely identifies
>>   the challenge.  This value MUST have at least 128 bits of entropy,
>> which in the
>>   base64url alphabet means a minimum string length of 22 characters
>> if the full
>>   scope of the base64url alphabet is in use in the token, by:
>> log2(64^22) = 132 bits of entropy
>>
>>
>>
>> Notes
>> -
>> This standards-track document doesn't specify the string ramifications
>> for entropy; I'd expect it to be called out to implementers, just the once,
>> and then referred to later at other tokens.
>>
>> If entropy is log2 the number of possible characters (64 if full
>> base64url set of chars is in use) then
>> log2 (64^21) = 126
>> log2 (64^22) = 132
>>
>> so a minimum of 22 characters are needed to get a minimum of 128 bits of
>> entropy in the token.
>>
>> But, if the random value is specified using a subset of the base64url,
>> say because the implementer doesn't like or use CAPITALS or (most likely)
>> the punctuation symbols, then the token must necessarily be longer to meet
>> the local implementer entropy requirement (though just losing only the
>> punctuation marks means you're still good and meet the requirement with 22
>> characters). Not sure that matters so much on the wire.
>>
>> I also have editing nits about base64url being defined clearly in ABNF
>> just for Replay-Nonce:, but then both 'base64 alphabet' and 'base64url
>> alphabet' are in use in the document, and base64url references are to
>> RFC4648 via RFC7515, but those are to Base64url, not to base64url... it all
>> seems a bit inconsistent editingwise. So all the references to 'base64
>> alphabet' should be to 'base64url alphabet' as defined in the doc, but it
>> should really be 'Base64url alphabet' to be consistent with references?
>>
>> (I really think that it should have been called 'Base-64_url alphabet'
>> way back when to enphasise the punctuation use, but that ship has sailed.)
>>
>> To me, 'base64 alphabet' is the a-zA-Z subset of base64... I think the
>> document could be much clearer in this regard, and I hope any doc revisions
>> taking into account all the other errata raised consider this too.
>>
>> My thanks to Lee Maguire for pointing much of this out.
>>
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>>
>> --
>> RFC8555 (draft-ietf-acme-acme-18)
>> --
>> Title   : Automatic Certificate Management Environment (ACME)
>> Publication Date: March 2019
>> Author(s)   : R. Barnes, J. Hoffman-Andrews, D. McCarney, J.
>> Kasten
>> Category: PROPOSED STANDARD
>> Source  : Automated Certificate Management Environment
>> Area: Security
>> Stream  : IETF
>> Verifying Party : IESG
>>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Deb Cooley]

opinions?  Does entropy have to be measured as a base64 encoded value?

Deb

On Mon, May 2, 2022 at 4:31 AM RFC Errata System 
wrote:

> The following errata report has been submitted for RFC8555,
> "Automatic Certificate Management Environment (ACME)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6950
>
> --
> Type: Technical
> Reported by: Lloyd Wood 
>
> Section: GLOBAL
>
> Original Text
> -
> token (required, string):  A random value that uniquely identifies
>   the challenge.  This value MUST have at least 128 bits of entropy.
>
> Corrected Text
> --
> token (required, string):  A random value that uniquely identifies
>   the challenge.  This value MUST have at least 128 bits of entropy,
> which in the
>   base64url alphabet means a minimum string length of 22 characters if
> the full
>   scope of the base64url alphabet is in use in the token, by:
> log2(64^22) = 132 bits of entropy
>
>
>
> Notes
> -
> This standards-track document doesn't specify the string ramifications for
> entropy; I'd expect it to be called out to implementers, just the once, and
> then referred to later at other tokens.
>
> If entropy is log2 the number of possible characters (64 if full base64url
> set of chars is in use) then
> log2 (64^21) = 126
> log2 (64^22) = 132
>
> so a minimum of 22 characters are needed to get a minimum of 128 bits of
> entropy in the token.
>
> But, if the random value is specified using a subset of the base64url, say
> because the implementer doesn't like or use CAPITALS or (most likely) the
> punctuation symbols, then the token must necessarily be longer to meet the
> local implementer entropy requirement (though just losing only the
> punctuation marks means you're still good and meet the requirement with 22
> characters). Not sure that matters so much on the wire.
>
> I also have editing nits about base64url being defined clearly in ABNF
> just for Replay-Nonce:, but then both 'base64 alphabet' and 'base64url
> alphabet' are in use in the document, and base64url references are to
> RFC4648 via RFC7515, but those are to Base64url, not to base64url... it all
> seems a bit inconsistent editingwise. So all the references to 'base64
> alphabet' should be to 'base64url alphabet' as defined in the doc, but it
> should really be 'Base64url alphabet' to be consistent with references?
>
> (I really think that it should have been called 'Base-64_url alphabet' way
> back when to enphasise the punctuation use, but that ship has sailed.)
>
> To me, 'base64 alphabet' is the a-zA-Z subset of base64... I think the
> document could be much clearer in this regard, and I hope any doc revisions
> taking into account all the other errata raised consider this too.
>
> My thanks to Lee Maguire for pointing much of this out.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8555 (draft-ietf-acme-acme-18)
> --
> Title   : Automatic Certificate Management Environment (ACME)
> Publication Date: March 2019
> Author(s)   : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten
> Category: PROPOSED STANDARD
> Source  : Automated Certificate Management Environment
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Deb Cooley]

Is this still accurate?  I'll mark it as 'Verified' and hold it for update.

Note:  I'm stripping the addresses on these a little - c...@letsencrypt.org
is bouncing, and Ben isn't Sec AD currently.  Oh and the chairs have to
approve posts with more than a few addresses listed

Deb



On Thu, Feb 24, 2022 at 1:30 PM Jacob Hoffman-Andrews  wrote:

> I agree with James' reading. The intent was to allow HTTP->HTTPS redirects
> during validation, and that is common practice today. The errata makes the
> language a little clearer around that, so I vote "hold for document update."
> --
> *From:* James Kasten 
> *Sent:* Wednesday, February 9, 2022 7:25 AM
> *To:* Benjamin Kaduk 
> *Cc:* Richard Barnes ; Jacob Hoffman-Andrews ;
> Daniel McCarney ; Roman Danyliw ;
> deco...@nsa.gov ; debcool...@gmail.com <
> debcool...@gmail.com>; Yoav Nir ; IETF ACME <
> acme@ietf.org>; RFC Errata System 
> *Subject:* Re: [Technical Errata Reported] RFC8555 (6843)
>
> Hi Ben,
>
> Thanks for the response.
>
> Following redirects for the http-01 challenge is already recommended by
> the RFC's Section 8.3
> .
> ```
> The server SHOULD follow redirects when dereferencing the URL.
> Clients might use redirects, for example, so that the response can be
> provided by a centralized certificate management server.  See
> Section 10.2 
> for security considerations related to redirects.
> ```
>
> Section 10.4 
> also contains an additional warning or emphasis regarding redirects with
> SSRF, so I included a generic reference to both for completeness.
> ```
> However, if the attacker first sets the domain to one
> they control, then they can send the server an HTTP redirect (e.g., a
> 302 response) which will cause the server to query an arbitrary URL.
> ...
> ```
>
> I believe this errata resolves ambiguity in the current text. Popular ACME
> CAs and clients are relying upon "http-01" challenge redirects from HTTP to
> HTTPS today. As an author who is familiar with the origin of this text, my
> intent was for it to read as "must be initiated" rather than "must be
> completed" over HTTP. I am happy to hear others' thoughts. I do believe
> deviating from this interpretation is extremely harmful for the HTTPS
> ecosystem which I can elaborate on if desired.
>
> Best,
> James
>
> On Tue, Feb 8, 2022 at 10:54 PM Benjamin Kaduk  wrote:
>
> 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 "rejected".
>
> -Ben
>
> On Tue, Feb 08, 2022 at 12:23:23PM -0800, RFC Errata System wrote:
> > The following errata report has been submitted for RFC8555,
> > "Automatic Certificate Management Environment (ACME)".
> >
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid6843
> >
> > --
> > Type: Technical
> > Reported by: James Kasten 
> >
> > Section: 8.3
> >
> > Original Text
> > -
> > Because many web servers
> > allocate a default HTTPS virtual host to a particular low-privilege
> > tenant user in a subtle and non-intuitive manner, the challenge must
> > be completed over HTTP, not HTTPS.
> >
> >
> > Corrected Text
> > --
> > Because many web servers
> > allocate a default HTTPS virtual host to a particular low-privilege
> > tenant user in a subtle and non-intuitive manner, the challenge must
> > be initiated over HTTP, not HTTPS.
> >
> > Notes
> > -
> > Completing the entire http-01 challenge over HTTP is unnecessary. The
> threat of default HTTPS virtual hosts is remediated by "initiating" the
> http-01 challenge over HTTP. Validation servers which redirect from HTTP to
> HTTPS should be permitted following the rest of the guidance within Section
> 10, Security Considerations.
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --
> > RFC8555 (draft-ietf-acme-acme-18)
> > --
> > Title   : Automatic Certificate Management Environment (ACME)
> > Publication Date: March 2019
> > Author(s)   : R. Barnes, J. Hoffman-Andrews, D. McCarney, J.
> Kasten
> > Category: PROPOSED STANDARD
> > Source  : Automated Certificate Management Environment
> > Area: Security
> > Stream  

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

[Deb Cooley]

Today's Errata  This looks editorial to me.  Opinions?

Deb

On Wed, Dec 23, 2020 at 11:22 AM RFC Errata System <
rfc-edi...@rfc-editor.org> wrote:

> The following errata report has been submitted for RFC8555,
> "Automatic Certificate Management Environment (ACME)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6364
>
> --
> Type: Technical
> Reported by: Evangelos Karatsiolis 
>
> Section: 7.1.4
>
> Original Text
> -
>wildcard (optional, boolean):  This field MUST be present and true
>   for authorizations created as a result of a newOrder request
>   containing a DNS identifier with a value that was a wildcard
>   domain name.  For other authorizations, it MUST be absent.
>   Wildcard domain names are described in Section 7.1.3.
>
> Corrected Text
> --
>wildcard (optional, boolean):  This field MUST be present and true
>   for authorizations created as a result of a newOrder request
>   containing a DNS identifier with a value that was a wildcard
>   domain name.  For other authorizations, it MUST be absent or
>   false.  For pre-authorizations, it MUST be absent or false.
>   Wildcard domain names are described in Section 7.1.3.
>
> Notes
> -
> This section states that the wildcard field must be absent for other
> authorizations, but the example in this section has an explicitly set
> wildcard field with value false. The proposed change allows both options,
> either omitting it or explicitly setting it to false. Also a sentence has
> been added to explicitly describe the behavior for pre-authorizations.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8555 (draft-ietf-acme-acme-18)
> --
> Title   : Automatic Certificate Management Environment (ACME)
> Publication Date: March 2019
> Author(s)   : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten
> Category: PROPOSED STANDARD
> Source  : Automated Certificate Management Environment
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Deb Cooley]

Thanks.  I'll mark this as 'Rejected'.  If Owen wants to resubmit it taking
this into account, he can.

Deb

On Wed, Jan 3, 2024 at 3:28 PM Jacob Hoffman-Andrews  wrote:

> This overspecifies things. When someone requests to create a new
> authorization object (or requests to create a new order object that would
> necessitate creation of new authorization objects), it is up to server
> policy whether to reuse an existing authorization or not. For instance a
> server might have a policy of never reusing authorization objects (that is,
> doing validation from scratch every time), or it might have a policy of
> reusing only pending authorization objects, or only ones created in the
> last N hours or days.
>
> So I think we should not accept this errata as it stands.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Deb Cooley]

I'll mark it as Verified (it was Editorial already).

TY

On Wed, Jan 3, 2024 at 3:32 PM Jacob Hoffman-Andrews  wrote:

> This is about indenting and I suspect email display clients are eating the
> leading spaces. Here's what it looks like with underscores:
>
> Old:
>
> ​___submit another order containing only the eight identifiers not listed
> ​___in the problem document.
>
> HTTP/1.1 403 Forbidden
> Content-Type: application/problem+json
> Link: ;rel="index"
>
> New:
>
> ​___submit another order containing only the eight identifiers not listed
> ​___in the problem document.
>
> ​___HTTP/1.1 403 Forbidden
> ​___Content-Type: application/problem+json
> ​___Link: ;rel="index"
>
> In other words, the HTTP response block is incorrectly outdented. The
> report is correct, but also I suspect any revision will involve a fresh
> editing pass that would catch indentation errors. Happy to accept or reject
> the errata.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Deb Cooley]

This is the last errata I'll pester you with today.  This one seems
sensible.  Please confirm or enlighten me.

Deb

On Fri, Oct 23, 2020 at 7:07 PM RFC Errata System 
wrote:

> The following errata report has been submitted for RFC8555,
> "Automatic Certificate Management Environment (ACME)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6317
>
> --
> Type: Technical
> Reported by: Matthew Holt 
>
> Section: 7.5.1
>
> Original Text
> -
> The server is said to "finalize" the authorization when it has
> completed one of the validations.
>
> Corrected Text
> --
> The server is said to "finalize" the authorization when it has
> successfully completed one of the validations or failed all of
> them.
>
> Notes
> -
> The current handling of failed challenges is ambiguous, or at least
> inefficient.
>
> To get a certificate, a client creates an Order. The client then has to
> validate all Authorizations ("authzs"). For each Authorization, the client
> needs to successfully complete one of the offered Challenges. One
> successful Challenge is sufficient to validate the authz. However,
> currently in practice, one failed Challenge is sufficient to invalidate the
> authz, and thus the entire Order. To try another Challenge, the client then
> has to first deactivate the other Authorizations (expensive) and create a
> new Order (also expensive), then repeat the whole process, remembering what
> was already tried.
>
> It is proposed that an Authorization MUST NOT be finalized until all
> possible challenges have failed. The client could then simply try the next
> Challenge. In other words, a single failed Challenge should not invalidate
> an authz; an authz should be "pending" until all offered challenges have
> failed or one has succeeded.
>
> The spec should be clear that a single failed challenge is not sufficient
> to finalize an authz which has multiple possible challenges.
>
> ACME servers see many, many failed validations. ACME clients need to keep
> more state. This change will speed up ACME transactions, lower costs for
> CAs, reduce code complexity, and make ACME more reliable on the whole.
>
> Real-world experience:
> https://github.com/mholt/acmez/commit/80adb6d5e64a3d36a56c58c66965b131ea366b8c
> Mailing list discussion:
> https://mailarchive.ietf.org/arch/msg/acme/wIHaqikTCZ59zrWsUUus8lZ4VSg/
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8555 (draft-ietf-acme-acme-18)
> --
> Title   : Automatic Certificate Management Environment (ACME)
> Publication Date: March 2019
> Author(s)   : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten
> Category: PROPOSED STANDARD
> Source  : Automated Certificate Management Environment
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Deb Cooley]

Yet another errata  My old eyes don't see what the change is.  All the
brackets look lined up the same in both original and corrected.  If someone
can point out where the change is, we can move this along. Or we reject
it.

Deb

On Tue, Apr 14, 2020 at 9:19 AM RFC Errata System 
wrote:

> The following errata report has been submitted for RFC8555,
> "Automatic Certificate Management Environment (ACME)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6104
>
> --
> Type: Editorial
> Reported by: Theodor Nolte 
>
> Section: 6.7.1
>
> Original Text
> -
>in the problem document.
>
> HTTP/1.1 403 Forbidden
> Content-Type: application/problem+json
> Link: ;rel="index"
>
> {
> "type": "urn:ietf:params:acme:error:malformed",
> "detail": "Some of the identifiers requested were rejected",
> "subproblems": [
> {
> "type": "urn:ietf:params:acme:error:malformed",
> "detail": "Invalid underscore in DNS name \"_example.org\"",
> "identifier": {
> "type": "dns",
> "value": "_example.org"
> }
> },
> {
> "type": "urn:ietf:params:acme:error:rejectedIdentifier",
> "detail": "This CA will not issue for \"example.net\"",
> "identifier": {
> "type": "dns",
> "value": "example.net"
> }
> }
> ]
> }
>
> Corrected Text
> --
>in the problem document.
>
>HTTP/1.1 403 Forbidden
>Content-Type: application/problem+json
>Link: ;rel="index"
>
>{
>"type": "urn:ietf:params:acme:error:malformed",
>"detail": "Some of the identifiers requested were rejected",
>"subproblems": [
>{
>"type": "urn:ietf:params:acme:error:malformed",
>"detail": "Invalid underscore in DNS name \"_example.org
> \"",
>"identifier": {
>"type": "dns",
>"value": "_example.org"
>}
>},
>{
>"type": "urn:ietf:params:acme:error:rejectedIdentifier",
>"detail": "This CA will not issue for \"example.net\"",
>"identifier": {
>"type": "dns",
>"value": "example.net"
>}
>}
>]
>}
>
> Notes
> -
> The code block of the HTTP reply is not aligned.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8555 (draft-ietf-acme-acme-18)
> --
> Title   : Automatic Certificate Management Environment (ACME)
> Publication Date: March 2019
> Author(s)   : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten
> Category: PROPOSED STANDARD
> Source  : Automated Certificate Management Environment
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Deb Cooley]

This errata also had no responses.  In this case, I'd suggest rejecting it,
or making it editorial.  I don't think it affects how anyone would
implement or interpret the RFC.  But again, I'd like confirmation (or
correction).

Deb


On Tue, Apr 14, 2020 at 9:19 AM RFC Errata System 
wrote:

> The following errata report has been submitted for RFC8555,
> "Automatic Certificate Management Environment (ACME)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6103
>
> --
> Type: Technical
> Reported by: Theodor Nolte 
>
> Section: 7.1.
>
> Original Text
> -
>o  A "newAccount" resource (Section 7.3)
>
>o  A "newOrder" resource (Section 7.4)
>
> Corrected Text
> --
>o  A "newAccount" resource (Section 7.3)
>
>o  A "newAuthz" resource (Section 7.4)
>
>o  A "newOrder" resource (Section 7.4)
>
> Notes
> -
> The item for the "newAuthz" resource is missing in the list of resources.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8555 (draft-ietf-acme-acme-18)
> --
> Title   : Automatic Certificate Management Environment (ACME)
> Publication Date: March 2019
> Author(s)   : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten
> Category: PROPOSED STANDARD
> Source  : Automated Certificate Management Environment
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Deb Cooley]

Happy New Year!

I'm going through acme's errata.  This one was reported, but crickets on
any responses from the authors (or others).  It looks like a sensible
addition to me, but I'd like confirmation.

Thanks
Deb

On Mon, Sep 23, 2019 at 8:50 AM RFC Errata System 
wrote:

> The following errata report has been submitted for RFC8555,
> "Automatic Certificate Management Environment (ACME)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5861
>
> --
> Type: Technical
> Reported by: owen friel 
>
> Section: 7.4.1
>
> Original Text
> -
>
>
> Corrected Text
> --
> If a server receives a newAuthz request for an identifier where the
> authorization object already exists, whether created by CA provisioning on
> the ACME server or by the ACME server handling a previous newAuthz request
> from a client, the server returns a 200 (OK) response with the existing
> authorization URL in the Location header field and the existing JSON
> authorization object in the body.
>
> Notes
> -
> The above text (or similar) should be appended to the end of section 7.4.1
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8555 (draft-ietf-acme-acme-18)
> --
> Title   : Automatic Certificate Management Environment (ACME)
> Publication Date: March 2019
> Author(s)   : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten
> Category: PROPOSED STANDARD
> Source  : Automated Certificate Management Environment
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] WGLC for draft-ietf-acme-onion

[Deb Cooley]

The ACME WG discussed this document at IETF 118, and the people in the room
felt it was ready for WG Last Call.

Title: ACME Extensions for ".onion" Special-Use Domain Names

URL:  https://datatracker.ietf.org/doc/draft-ietf-acme-onion/

Please express whether you think this document is ready for publication as
a standards-track RFC by 18 December 2023 (3+ weeks to dodge various
holidays).

For the ACME WG chairs
Deb
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] ACME minutes for IETF 118

[Deb Cooley]

These are posted here:
https://datatracker.ietf.org/doc/minutes-118-acme-202311081200/

If you have comments/proposed changes, please reply here, or to the chairs.

Deb Cooley
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [EXTERNAL] agenda items for IETF 118 and important dates

[Deb Cooley]

I'm getting ready to put the acme agenda together.  I have only two
briefing that have been requested...  Obviously we can add people late, but
it is nicer to know in advance.

Also the Meetecho interface has changed.  There are videos and resources
available.  I was going to request a test session so I can see what the
chair features look like.  If any of the speakers (especially remote
speakers) want to tag along, I'd be good with that.  If you have times you
prefer, just email the chair alias.  My thought was maybe on Friday late
afternoon (US East Coast time), Monday before the sessions (Prague time),
or Monday lunch (Prague time).

Deb

On Thu, Oct 12, 2023 at 12:01 PM Mike Ounsworth 
wrote:

> Hi Deb,
>
>
>
> We have just pushed draft-vanbrouwershaven-acme-auto-discovery-02: we
> have just pushed a -02 [1]. Since 117 there have been some great offline
> discussions making progress on the technical issues, so we can give a short
> presentation to update the community.
>
>
>
> The main technical issue we’re working through is “account
> disambiguation”; consider a large enterprise subscriber that has multiple
> departments which are all authorized to issue for *.company.com, but
> let’s say that only DepartmentA is authorized to issue S/MIME, and only
> DepartmentB is authorized to issue EV. The acme-auto-discovery mechanism
> will result in an issuance request from the ACME protocol account
> controlled by the cloud provider, so we need a robust way to tie that back
> to the pre-existing substcriber Org/Department account in the CA. This is
> turning out to be tricky, but we’ll be happy to present progress at 118.
>
>
>
>
>
> [1]:
> https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/
>
> ---
>
> *Mike* Ounsworth
>
>
>
> *From:* Acme  *On Behalf Of * Deb Cooley
> *Sent:* Monday, October 9, 2023 9:22 AM
> *To:* IETF ACME 
> *Cc:* acme-...@ietf.org;  
> *Subject:* [EXTERNAL] [Acme] agenda items for IETF 118 and important dates
>
>
>
> All, The preliminary agenda has acme scheduled to meet on Wednesday from
> 1300-1400 (Prague time).   The agenda will be final on Friday (13 Oct).
> If you would like to present during that time slot, please contact the
> chairs ( acme-chairs@ ietf. org
>
> All,
>
>
>
> The preliminary agenda has acme scheduled to meet on Wednesday from
> 1300-1400 (Prague time).  The agenda will be final on Friday (13 Oct).  If
> you would like to present during that time slot, please contact the chairs
> ( acme-cha...@ietf.org ).
>
>
>
> Also the Internet Draft submission cut-off is 23 Oct 2023 midnight (UTC),
> so if you want your draft updated prior to the workshop, now is the time.
> Obviously new work falls into this timeline as well.
>
>
>
> A couple of notes:
>
> 1.  draft-ietf-acme-dtnnodeid-11 - the chairs will coordinate w/ the AD.
> mea culpa.
>
> 2.  draft-vanbrouwershaven-acme-auto-discovery-01 - we would like to see
> this draft updated before the call for adoption.
>
>
> Deb (and Yoav)
> acme chairs
>
>
> *Any email and files/attachments transmitted with it are intended solely
> for the use of the individual or entity to whom they are addressed. If this
> message has been sent to you in error, you must not copy, distribute or
> disclose of the information it contains. Please notify Entrust immediately
> and delete the message from your system.*
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] agenda items for IETF 118 and important dates

[Deb Cooley]

All,

The preliminary agenda has acme scheduled to meet on Wednesday from
1300-1400 (Prague time).  The agenda will be final on Friday (13 Oct).  If
you would like to present during that time slot, please contact the chairs
( acme-cha...@ietf.org ).

Also the Internet Draft submission cut-off is 23 Oct 2023 midnight (UTC),
so if you want your draft updated prior to the workshop, now is the time.
Obviously new work falls into this timeline as well.

A couple of notes:
1.  draft-ietf-acme-dtnnodeid-11 - the chairs will coordinate w/ the AD.
mea culpa.
2.  draft-vanbrouwershaven-acme-auto-discovery-01 - we would like to see
this draft updated before the call for adoption.


Deb (and Yoav)
acme chairs
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Proposal: ACME Profiles

[Deb Cooley]

Aaron,

Also (very) late to the game, and my experience is mostly with private CAs:

We have used certificate profiles for decades, but not with ACME.  These
profiles are currently specified in a document called 'certificate
profiles'.  Even in our most widely used systems (that issue to more than
TLS), there aren't more than 20-30 profiles.  Generally, we specify the
algorithm/key size choices w/in a single profile (currently one can choose
RSA 2K or above and ECDSA w/ P384, for example).  Certificate validity is
done the same way (less than x time).  What does vary are the KU and EKU
fields for each profile, where some EKUs are mandatory and some are
optional.  These profiles have very simple names.  When a request is made,
as long as the CSR matches the options we have given them in the profile,
the cert is issued.

I think this old school method should scale to ACME without too much
trouble.  There would need to be a default profile for your old
clients/accounts.
And the profile offerings can be set by what EKUs are chosen (where there
are both mandatory EKUs and optional EKUs).  Having this profile ability
will allow the use of ACME CAs in more areas than just TLS.

My last comment is that this should be kept simple.  Most server operators
struggle today, and get it wrong.  The simpler we can keep it, the more
likely they will be to configure it correctly - enabling secure
communications.

Deb




On Tue, Sep 19, 2023 at 8:33 PM Matthew McPherrin  wrote:

> My personal opinion here is that adding a profile field to the Order
> object is likely to hamper client adoption, and as Ben just said, makes
> configuration more difficult if CAs don't have matching profiles.
>
> An alternative approach that I believe has been used is adding URL
> parameters to the directory URL, as Aaron mentioned in his initial email.
>
> The returned URLs in the directory can reflect those parameters, eg, on
> the newOrder endpoint, as required.
>
> The directory endpoint should only do so if the parameters are known.
>
> The directory url can contain metadata to advertise what parameters are
> available.
>
> So potentially an interactive client can display a UI of options to a user.
>
> Automated use-cases or older ACME clients would simply configure the
> directory URL as desired, with the query parameters included.
>
> I believe that adding parameters to directory URLs requires no additional
> standardization work, and Let's Encrypt can add a profile parameter
> immediately.
>
> What we may want to standardize is a method for advertising what query
> parameters are available, as well as a mechanism for returning warnings or
> errors about invalid or deprecated flags in the directory.
>
> Thanks, Matthew
>
> On Tue, Sep 19, 2023 at 7:17 PM Ben Burkert  wrote:
>
>> Hello,
>>
>> Apologies for chiming in late here; I'm with a startup that is just
>> coming out of stealth mode so I have been quietly following these
>> discussions. I bring this up because we build & operate ACME powered CAs
>> on behalf of users, and we've already introduced our own concept similar
>> to profiles. We focus entirely on the private CA market, but we have an
>> interest in seeing this concept standardized in a way that works well
>> for both the public & private ACME CAs.
>>
>> The way we solve this is at the intermediate CA level, which we refer to
>> as a SubCA. Each SubCA is an intermediate CA that issues end entity
>> certs, and a template that sets a common set of properties of the end
>> entity certs that it issues. For example, when creating a SubCA you can
>> specify the expiry time (as a duration), key usage and other extensions,
>> and allowed DNS/IP naming rules (which can turn into name constraints on
>> the intermediate).
>>
>> This works for us because creating new intermediate CA is easy to do in
>> our model. Also, we require EAB tokens on all ACME requests, and we
>> scope those tokens to specific SubCAs. This means clients effectively
>> pick a profile by picking a SubCA when creating EAB tokens.
>>
>> So we have something similar that works well for us today. But even so,
>> there are a whole bunch of business reasons I could go into about why we
>> would like to see a standardized profile concept. A lot of the reasons
>> probably aren't relevant to public CAs though, so I'll stick with my
>> thoughts related to public CAs.
>>
>> The "combinatorial explosion" of profiles seems like a bigger issue for
>> client authors and end users than for the CAs. If i'm trying to setup
>> multi-CA resiliency, today I only have to add some fallback directory
>> URLs and duplicate the manual or automated work to fulfill challenges.
>> But with profiles, does that mean I have to go to each CA and figure out
>> the right set of profiles? I don't like the added friction of having to
>> manually perform this intersection of policies.
>>
>> I think Rufus' idea about allowing profiles to point to other CAs could
>> address some of the "combinatorial ex

Re: [Acme] IETF 117 Agenda items

[Deb Cooley]

If you have requested an agenda time, please submit briefings as soon as
possible (if you haven't already done so - TY Q).  We are meeting early in
the week (!).

You should be able to submit them to the ACME data tracker section, or you
can send it to the chairs and we can post it.

Deb Cooley

On Mon, Jul 3, 2023 at 7:40 AM Deb Cooley  wrote:

> The acme timeslot is 1730-1830 on Monday (!)
>
> Please send in your agenda topics along with how much time you think you
> will need to: acme-cha...@ietf.org by 11 July 2023.
>
> The ID submission cutoff is 10 July.  If you want to up-issue your drafts
> before the meeting, be aware of this date. (It usually re-opens early
> during the meeting week).
>
> Hoping to see you all IRL in San Francisco!
>
> Deb Cooley
> for the acme chairs
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Deb Cooley]

Apologies for missing this ask.  Indeed I can add you to the agenda.  Who
is briefing and how long do you think you need?

Deb

On Tue, Jul 18, 2023 at 7:54 PM Mike Ounsworth  wrote:

> @chairs since the agenda doesn't look particularly full, and we asked
> before the cutoff, could we get this on the agenda please?
>
> ---
> Mike Ounsworth
>
> -Original Message-
> From: Acme  On Behalf Of Mike Ounsworth
> Sent: Thursday, July 6, 2023 9:54 AM
> To: acme@ietf.org
> Cc: Paul van Brouwershaven 
> Subject: [Acme] FW: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
>
> Hi ACME!
>
> This is new business that we would like to add to the agenda for 117.
>
> Thanks,
> ---
> Mike Ounsworth & Paul van Brouwershaven
>
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Thursday, July 6, 2023 9:39 AM
> To: Mike Ounsworth ; Paul van Brouwershaven <
> paul.vanbrouwersha...@entrust.com>
> Subject: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
>
> __
>
> A new version of I-D, draft-vanbrouwershaven-acme-auto-discovery-00.txt
> has been successfully submitted by Paul van Brouwershaven and posted to
> the IETF repository.
>
> Name:   draft-vanbrouwershaven-acme-auto-discovery
> Revision:   00
> Title:  Auto-discovery mechanism for ACME client configuration
> Document date:  2023-07-06
> Group:  Individual Submission
> Pages:  16
> URL:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH3yeoTcrC$
> Status:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH39B9nSJz$
> Html:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH3-CaBB-W$
> Htmlized:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH37daXF_h$
>
>
> Abstract:
>A significant impediment to the widespread adoption of the Automated
>Certificate Management Environment (ACME) [RFC8555] is that ACME
>clients need to be pre-configured with the URL of the ACME server to
>be used.  This often leaves domain owners at the mercy of their
>hosting provider as to which Certification Authorities (CAs) can be
>used.  This specification provides a mechanism to bootstrap ACME
>client configuration from a domain's DNS CAA Resource Record
>[RFC8659], thus giving control of which CA(s) to use back to the
>domain owner.
>
>Specifically, this document specifies two new extensions to the DNS
>CAA Resource Record: the "discovery" and "priority" parameters.
>Additionally, it registers the URI "/.well-known/acme" at which all
>compliant ACME servers will host their ACME directory object.  By
>retrieving instructions for the ACME client from the authorized
>CA(s), this mechanism allows for the domain owner to configure
>multiple CAs in either load-balanced or fallback prioritizations
>which improves user preferences and increases diversity in
>certificate issuers.
>
>
>
>
> The IETF Secretariat
>
>
> Any email and files/attachments transmitted with it are intended solely
> for the use of the individual or entity to whom they are addressed. If this
> message has been sent to you in error, you must not copy, distribute or
> disclose of the information it contains. Please notify Entrust immediately
> and delete the message from your system.
> ___
> Acme mailing list
> Acme@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!d0ZjHZK3lFPhUQfdjAxymn-H3OhnRAb4rcV3IIj5JYeqEaYfSa9Kl0wLB66UtTUn9f4M43NSwZ0dnFc0JtwNW0dZY9AH39SGJXVL$
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Practical concerns of draft-ietf-acme-ari

[Deb Cooley]

 Only one small point:


snip..
> 4) Crafting the URL is convoluted. As Peter Cooper described it, "The core
> > issue is that the URL you need to construct is based on an OCSP
structure
> > identifying the certificate, which requires taking one's existing
> > certificate and parsing out the serial number and issuer, and also
taking
> > the intermediate certificate that signed it and getting its public key
too.
> > So rather than just, like, using the fingerprint of the existing leaf or
> > something similarly simple that a lot of tooling can already give you,
one
> > needs to really dig into both the leaf, and the intermediate, and hash
> > various pieces thereof, and then take all that to build a new ASN.1
> > structure." Why are we striving for near-parity with an OCSP request??
This
> > should be orthogonal to OCSP, right?
> >
>
> This is great feedback. We picked this request format specifically because
> we thought it would be easy. It's good to know that we were wrong, and
> investigate what other request formats would work better.

Looking at the code of the client I wrote, some of the data processing
seems to be shared with OCSP (e.g., extracting the key from the SPKI),
but the final serialization is different, because OCSP is de facto still
stuck on SHA-1.

The single most annoying part of the process is the hash of the issuer
key. For that, you need the issuer certificate, while everything else
can be pulled from the subject certificate.

And the issuer key hash is not in practice even needed, because issuer
name is de facto key for the issuer key. A lot of stuff would likely
break if one had two different keys for the same issuer name.
snip.

Issuer key hash:  Is this not in the Authority Key ID extension?  Or is
this extension not used?

If these things are not the same, my recommendation would be to use
Authority Key ID value as a way to ID the issuing CA.

Deb Cooley, no hats


On Thu, Jul 20, 2023 at 2:16 AM Ilari Liusvaara 
wrote:

> On Wed, Jul 19, 2023 at 03:05:52PM -0700, Aaron Gable wrote:
> > Hi Matt,
> >
> > On Fri, Jun 23, 2023 at 9:21 AM Matthew Holt  wrote:
> >
> > > But when a renewal window does change, what does that mean? Well,
> > > something is wrong. Either the certificate is being revoked, or the CA
> > > anticipates downtime or availability issues.
> > >
> >
> > This is not true. Explicitly, by the spec, the renewal window changing
> > means nothing. The situations you list are the motivations for writing
> the
> > spec in the first place, but they are not the only motivations for
> changing
> > the window in any given case. In fact, Let's Encrypt is currently
> > considering adding random jitter to the renewal window every time it is
> > requested, specifically to prevent interpretations like this, and to
> > naturally even-out renewal spikes through Brownian motion.
>
> However, clients might not react nicely to doing that while in window
> or very near it.
>
> E.g., the client might be deterministically generating renewal time
> from window (the client I wrote does this). This works nicely if the
> renewal window does not shift around. However, it becomes heavily
> biased toward beginning of the window if the window shifts around.
>
>
> > > 3) ARI does not scale well. Some ACME clients manage 10K+ certificates,
> > > and in that case the client would have to check the ARI for at least 24
> > > certificates per hour to get through them in a month. Deferring to the
> > > Retry-After header may result in insufficient throughput. The current
> > > expectation or convention is to check every certificate every 6-12
> hours,
> > > or tens of thousands of checks per day. One endpoint per certificate
> > > multiple times per day is quite saturating. This is a considerable
> burden
> > > for both ACME clients and servers. I would like to explore options
> that do
> > > not involve 2+ HTTP requests per certificate.
> > >
> >
> > Totally agreed, we don't love the heavy-polling nature of ARI as it
> stands
> > either. It's a lot of requests, and that's a large part of why we've
> > striven to keep the response size so small. The original version of this
> > was just a single timestamp. It's grown to two timestamps and an optional
> > URL thanks to community feedback, but I'd be happy to reduce the response
> > size again if we decide that prioritizing efficiency is more important
> than
> > prioritizing third-party certificate monitoring tools.
>
> The reason for having a window is third-party monitoring too

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

[Deb Cooley]

Please mark this as verified.

thanks,
Deb Cooley

On Tue, Jul 18, 2023 at 7:27 PM Paul Breed  wrote:

> RFC7518 is pretty clear.
> Maybe the correct action is just to Remove the comment in its entirety.
>
>
> On Thu, Jul 13, 2023 at 4:09 PM Corey Bonnell 
> wrote:
>
>> “Fixed length fields such as found in ECDSA keys should be their natural
>> length and
>>leading zero octets should not be stripped.”
>>
>>
>>
>> I would consider strengthening this to say MUST/MUST NOT instead of
>> “should” to avoid any ambiguity that there is no allowance for stripping
>> leading zero octets.
>>
>>
>>
>> Thanks,
>>
>> Corey
>>
>>
>>
>> *From:* Acme  *On Behalf Of * Richard Barnes
>> *Sent:* Thursday, July 13, 2023 12:38 PM
>> *To:* RFC Errata System 
>> *Cc:* j...@eff.org; c...@letsencrypt.org; jdkas...@umich.edu; r...@cert.org;
>> paul.wout...@aiven.io; deco...@radium.ncsc.mil; debcool...@gmail.com;
>> ynir.i...@gmail.com; p...@rasdoc.com; acme@ietf.org
>> *Subject:* 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)".
>>
>> --
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid7565
>>
>> --
>> Type: Technical
>> Reported by: Paul Breed 
>>
>> Section: 8.1
>>
>> Original Text
>> -
>>  The "Thumbprint" step indicates the computation specified in
>>[RFC7638], using the SHA-256 digest [FIPS180-4].  As noted in
>>[RFC7518] any prepended zero octets in the fields of a JWK object
>>MUST be stripped before doing the computation.
>>
>> Corrected Text
>> --
>> The "Thumbprint" step indicates the computation specified in
>>[RFC7638], using the SHA-256 digest [FIPS180-4].  As noted in
>>[RFC7518] any additional prepended zero octets in the fields of a JWK
>> object
>>MUST be stripped before doing the computation.
>>Fixed length fields such as found in ECDSA keys should be their
>> natural length and
>>leading zero octets should not be stripped.
>>
>> Notes
>> -
>> This comment was really aimed at the leading 0 octet sometimes used with
>> RSA, but the comment is not RSA specific. ECDSA keys can have fixed length
>> fields (X,Y) where there can be leading zeros.  This led me astray in
>> implementing an ECDSA thumbprint routine for ACME. The result was that
>> 1/128 ECDSA keys failed to generate t humbp[rint as leading zeros were
>> removed.
>>
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>>
>> --
>> RFC8555 (draft-ietf-acme-acme-18)
>> --
>> Title   : Automatic Certificate Management Environment (ACME)
>> Publication Date: March 2019
>> Author(s)   : R. Barnes, J. Hoffman-Andrews, D. McCarney, J.
>> Kasten
>> Category: PROPOSED STANDARD
>> Source  : Automated Certificate Management Environment
>> Area: Security
>> Stream  : IETF
>> Verifying Party : IESG
>>
>>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] IETF 117 Agenda items

[Deb Cooley]

 The acme timeslot is 1730-1830 on Monday (!)

Please send in your agenda topics along with how much time you think you
will need to: acme-cha...@ietf.org by 11 July 2023.

The ID submission cutoff is 10 July.  If you want to up-issue your drafts
before the meeting, be aware of this date. (It usually re-opens early
during the meeting week).

Hoping to see you all IRL in San Francisco!

Deb Cooley
for the acme chairs
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Practical concerns of draft-ietf-acme-ari

[Deb Cooley]

We are happy to have more participation in the acme working group.  The
IETF is based on development of standards by rough consensus.  If you are
willing to roll up your sleeves and participate (by reviewing/commenting on
the drafts, and contributing to discussion) we are happy to have you.  It
is not called the 'acme server' working group.  The working group is only
as sleepy as we make it.

I will say that reading pages of a single message serves only to bury the
lead.  Crafting opinions that are clear and concise get quicker results.
We are all busy people.

Deb Cooley
deco...@nsa.gov
Co-chair of acme

On Fri, Jun 23, 2023 at 1:44 PM Michael Sweet  wrote:

> FWIW, I agree with Matthew's comments and conclusions.
>
> In a somewhat-related situation for printing, we have an event
> notification interface (RFC 3996) where the printer can report back a time
> interval (in seconds) when the client should re-contact the printer to get
> more events.  This is flexible enough to handle both printer/server load
> and to let the client now when it should anticipate more events, i.e., the
> printer is printing something, the event subscription is for
> 'job-completed', and the printer can estimate when the print job will
> complete - this is analogous to an ACME certificate's expiration/renewal
> date/time.
>
> Personally, the servers I maintain use Let's Encrypt and have a weekly
> cron job that checks whether the server's certificate needs to be renewed.
> If the ACME server could provide a "retry after" response then my servers
> (ACME clients) could do a better job of scheduling the next update and not
> bug the ACME server so often...
>
>
> > On Jun 23, 2023, at 12:20 PM, Matthew Holt  wrote:
> >
> > Hi all,
> >
> > I don't normally participate in these mailing lists, and last time I did
> I feel like the lack of discussion was discouraging, as what little
> discussion did occur wasn't taken seriously and was laced with complacency.
> Just stating up front that I don't have much hope for this message to be
> acted upon. That said, multiple people have strongly encouraged _someone_
> to write the mailing list and bring the concerns of multiple ACME client
> developers to your attention.
> >
> > I speak for myself, but my views have been formed from a combination of
> personal experience developing ACME clients and discussion with other ACME
> client developers. So when I say "we" I do so loosely; sometimes it might
> just be me.
> >
> > First, I want to say: overall we like the idea of proactive ACME clients
> being able to know whether a certificate needs to be replaced sooner than
> expected, and we're glad to see an attempt at a solution drafted for
> standardization. But some of us do not think (current draft) ARI is The Way.
> >
> > Now that several ACME client authors have had the opportunity to
> implement the spec, we've noticed some issues, both with fundamental flaws
> in the concept of ARI and some in implementation. Initially these concerns
> were raised at the Let's Encrypt forums:
> >
> > -
> https://community.letsencrypt.org/t/can-ari-conforming-clients-be-granted-exemptions-to-relevant-rate-limits/195600?u=mholt
> > -
> https://community.letsencrypt.org/t/thoughts-from-starting-to-play-with-ari/200276?u=mholt
> > - https://community.letsencrypt.org/t/ari-rate-limits/198720?u=mholt
> > -
> https://community.letsencrypt.org/t/ari-retry-after-header/195471?u=mholt
> >
> > And the overwhelming response seems to be, "Meh, take it to the mailing
> list." (Except for one response by LE staff about rate limits, which was
> appreciated, at least.) So here we are.
> >
> > Cutting to the chase:
> >
> > With respect to ARI, ACME servers and clients have conflicts of
> interest. The ACME client's goal is to keep the site up (with renewed and
> unrevoked certificates); the optimal way to do this is to start renewing
> early and retry often. The ACME server's goal is to keep the service up;
> the optimal way to do this is to suppress clients that overload your
> capacity. Obviously, these two goals are in opposition with each other.
> Proactive clients can spike demand, which can cause service interruptions.
> But service interruptions make clients more paranoid to retry even more
> often until it works, and so on. ARI narrows the timeframe in which a
> conforming client can retry failed renewals, which reduces reliability more
> as time goes on. Without ARI, this window is a reasonable ~60 days. With
> ARI, however, the window is reduced to just a few minutes, hours, or days.
> The less time until expiration, the l

Re: [Acme] Call for adoption of draft-misell-acme-onion-02

[Deb Cooley]

There is sufficient interest to adopt this draft.

Thank you,
Deb

On Fri, Jun 9, 2023 at 5:06 PM Seo Suchan  wrote:

> for CAA mechanism for tor, I'm don't think acme working group is right
> place to talk about it: as they effect non-acme CA that sign certificate
> for onion, shouldn't it need to be handled on lamps subject (as there is
> where CAA rfc was discussed)
> 2023-06-10 오전 1:55에 Aaron Gable 이(가) 쓴 글:
>
> Hi all,
>
> I support the draft for adoption. Specifically, I think it's a good thing
> to standardize the onion-csr-01 challenge type. I have two classes of
> comments that I look forward to discussing in-depth after adoption:
> 1) Obviously it's valuable for this draft to standardize a method that is
> already accepted by the CA/BF. But in the long term there's no need to use
> a CSR as the transport mechanism for a random token, a public key, and a
> signature -- moving away from x509 for this would be nice in the long term.
> Probably out-of-scope for this document, but worth discussing.
> 2) The primary benefit of the onion-csr-01 method is that it allows the CA
> to perform domain control validation without operating a Tor client.
> However, this benefit is obviated entirely by the need to operate a Tor
> client to check for CAA in the hidden service descriptor. It seems likely
> that there are CAs which have avoided implementing HTTP-01 and TLS-ALPN-01
> for .onion due to the need to operate a Tor client; these same CAs may have
> been willing to implement ONION-CSR-01, but now will not due to the CAA
> mechanism.
>
> Thanks,
> Aaron
>
> On Sun, Jun 4, 2023 at 4:07 AM Deb Cooley  wrote:
>
>> This will be a two week call for adoption ending on 16 June.   Please
>> speak up either for or against adopting this draft.
>>
>> Thanks,
>> Deb
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
> ___
> Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Call for adoption of draft-misell-acme-onion-02

[Deb Cooley]

 This will be a two week call for adoption ending on 16 June.   Please
speak up either for or against adopting this draft.

Thanks,
Deb
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] DNS-ACCOUNT-01 Updates

[Deb Cooley]

What is confusing is having a numerical value as part of the draft title.
Currently:  draft-ietf-acme-dns-account-01-01 which is only going to be
worse as the draft moves through version numbers.  My suggestion would be
to name it without the use of a numerical value.  This gets rid of both
problems.  The only question is what to actually call it.

Deb Cooley (no hats)
deco...@radium.ncsc.mil



On Fri, May 19, 2023 at 8:38 AM Sean Dilda  wrote:

> I don't spend a lot of time on the Let's Encrypt forums, but I do maintain
> an internal ACME server and work with the IT staff that manage certs/acme
> client installs.   Most of my users are only vaguely aware that their ACME
> client creates an account as part of the process.  Given that, I suspect
> they would find the name 'DNS-ACCOUNT-01' confusing as it wouldn't be clear
> to them which account is being referred to.  They would likely assume it
> would be the account on their DNS provider.I think 'DNS-02' as a newer
> version of the DNS challenge type would be less confusing.
> --
> *From:* Acme  on behalf of Amir Omidi  40google@dmarc.ietf.org>
> *Sent:* Thursday, May 18, 2023 5:03 PM
> *To:* Seo Suchan 
> *Cc:* acme@ietf.org 
> *Subject:* Re: [Acme] DNS-ACCOUNT-01 Updates
>
> I think what decision happens here will probably end up setting the
> precedent on either these digits are "version numbers" of the "base
> challenge types" (Not sure what to call them), and they act as a
> replacement of them. Or that they are another flavor of the
> technologies/protocols used in those challenges. I do not have strong
> opinions here either way.
>
> Another factor to consider is how would support/Q&A forums feel about the
> name choice of DNS-ACCOUNT-01 vs DNS-02. For example, if there is anyone
> here who's keeping an eye on the Let's Encrypt's community forum do you
> think DNS-02 would make things easier or harder for users adopting ACME
> based certificate issuance and the folks helping them out? If harder, do
> you think DNS-ACCOUNT-01 would be a better option here?
>
> On Sat, May 13, 2023 at 5:24 AM Seo Suchan  wrote:
>
> I kinda think TLS-SNI-02 was made as version 2 of TLS-SNI-01, but it
> doesn't matter as they are no longer a thing
> 2023-05-13 오전 3:43에 Q Misell 이(가) 쓴 글:
>
>
> I'm also in favour of calling it DNS-02. I highly doubt there will be many
> (if any) versions of challenges beyond version 1. It makes more sense to me
> to read DNS-02 and DNS challenge type 2, not a upgraded edition of version
> 1.
> --
>
> Any statements contained in this email are personal to the author and are
> not necessarily the statements of the company unless specifically stated.
> AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
> Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
> registered in Wales under № 12417574
> <https://urldefense.com/v3/__https://find-and-update.company-information.service.gov.uk/company/12417574__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLMzA2bpN$>.
> ICO register №: ZA782876
> <https://urldefense.com/v3/__https://ico.org.uk/ESDWebPages/Entry/ZA782876__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLKSmK3R2$>.
> UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524.
> South Korean VAT №: 522-80-03080. Glauca Digital and the Glauca logo are
> registered trademarks in the UK, under № UK3718474 and № UK3718468,
> respectively.
>
>
> On Fri, 12 May 2023 at 17:58, Aaron Gable  40letsencrypt@dmarc.ietf.org> wrote:
>
> For what it's worth, I'm in favor of calling it DNS-02. Despite your
> totally correct descriptions of the disadvantages of this new method, I
> *do* still view it as a generally-improved version of DNS-01. It's
> obviously backwards-incompatible, hence the new major version number, but
> it is generally an improvement that creates more flexibility for clients at
> little cost. I also find the name "DNS-ACCOUNT-01" to be slightly
> unfortunate, as no "dns accounts" are involved -- it makes sense once you
> understand the method, but the name gives little to no hint to how the
> method works on its own.
>
> Aaron
>
> On Thu, May 11, 2023 at 4:52 PM Antonios Chariton 
> wrote:
>
> Hello everyone,
>
> I’m sending this e-mail to the list to update you all on DNS-ACCOUNT-01
> and the news we have since the presentation in IETF 116.
>
> You can all help by reviewing the text[0], these updates, and sharing your
> opinion in this thread h

Re: [Acme] change from Informational to Proposed Standard

[Deb Cooley]

apologies, this got away from me.  I believe that is enough agreement on
the list.  Please resubmit as proposed standard.

Deb (and Yoav).

On Sat, Apr 22, 2023 at 8:58 PM Benjamin Kaduk  wrote:

> 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 this
> > >> list by 5 May 2023.
> >
> > > Could we say a little more in this thread about why we want to
> make this
> > > change?  The draft currently states explicitly "[t]his draft is
> informational
> > > and makes no changes to the referenced specifications"; what new
> behaviors
> > > is it important to have at standards-track level of maturity?
> >
> > There are no new protocols, but there are MUST requirements on existing
> > protocols, and we wound up with BCP14 words.
> > I.e. you MUST do X within exchange Y (even though protocol Y has it as
> MAY or SHOULD)
>
> Got it, thanks.
>
> Yes, PS makes sense to me given that clarification.
>
> -Ben
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] change from Informational to Proposed Standard

[Deb Cooley]

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.

Thanks,
Deb and Yoav
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [EXTERNAL] Re: note takers

[Deb Cooley]

Thank you all!

Deb

On Wed, Mar 29, 2023 at 12:17 AM Mike Ounsworth 
wrote:

> I’m also happy to take notes.
>
>
>
> ---
>
> *Mike* Ounsworth
>
>
>
> *From:* Acme  *On Behalf Of * Aaron Gable
> *Sent:* Wednesday, March 29, 2023 8:33 AM
> *To:* Deb Cooley 
> *Cc:* Amir Omidi ; IETF ACME ;
> acme-cha...@ietf.org
> *Subject:* [EXTERNAL] Re: [Acme] note takers
>
>
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
> --
>
> I've done it before; I'm happy to fill in during Amir's talk.
>
>
>
> On Tue, Mar 28, 2023 at 4:30 PM Deb Cooley  wrote:
>
> Thank you for volunteering.  Usually we can get a second person to fill in
> during your talk (hint, we need another volunteer).
>
>
>
> Deb
>
>
>
> On Tue, Mar 28, 2023 at 5:00 PM Amir Omidi  wrote:
>
> I can participate in taking notes assuming we have the audio transcripts I
> can use to fill any gaps later (note I’ve not done note taking at IETF
> before).
>
>
>
> I will need coverage during the short period I’ll be talking. However
> Antonis is going to do the majority of the presentation so it should only
> be a few minutes.
>
>
>
> On Tue, Mar 28, 2023 at 14:47 Deb Cooley  wrote:
>
> We are looking for volunteers to take notes for Thursday's meeting.  It
> isn't a hard job... but we can't meet w/out someone doing that job.
>
>
>
> Thanks in advance,
>
>
>
> Deb (and Yoav)
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!diHAgThRX_Iq3MRJ7RUXEIyr_kCpsgU_s3iUhEAUGSVZGTsh_ohRtIwd7ps_NUc7xZpzIBgCIv1SOg7yzllciTaczukCBp_OCpx9$>
>
> --
>
> Amir Omidi (he/them)
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!diHAgThRX_Iq3MRJ7RUXEIyr_kCpsgU_s3iUhEAUGSVZGTsh_ohRtIwd7ps_NUc7xZpzIBgCIv1SOg7yzllciTaczukCBp_OCpx9$>
>
> *Any email and files/attachments transmitted with it are confidential and
> are intended solely for the use of the individual or entity to whom they
> are addressed. If this message has been sent to you in error, you must not
> copy, distribute or disclose of the information it contains. Please notify
> Entrust immediately and delete the message from your system.*
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] note takers

[Deb Cooley]

Thank you for volunteering.  Usually we can get a second person to fill in
during your talk (hint, we need another volunteer).

Deb

On Tue, Mar 28, 2023 at 5:00 PM Amir Omidi  wrote:

> I can participate in taking notes assuming we have the audio transcripts I
> can use to fill any gaps later (note I’ve not done note taking at IETF
> before).
>
> I will need coverage during the short period I’ll be talking. However
> Antonis is going to do the majority of the presentation so it should only
> be a few minutes.
>
> On Tue, Mar 28, 2023 at 14:47 Deb Cooley  wrote:
>
>> We are looking for volunteers to take notes for Thursday's meeting.  It
>> isn't a hard job... but we can't meet w/out someone doing that job.
>>
>> Thanks in advance,
>>
>> Deb (and Yoav)
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
> --
> Amir Omidi (he/them)
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] note takers

[Deb Cooley]

We are looking for volunteers to take notes for Thursday's meeting.  It
isn't a hard job... but we can't meet w/out someone doing that job.

Thanks in advance,

Deb (and Yoav)
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] IETF 116

[Deb Cooley]

For your convenience, here is the (draft) agenda:
-
Automated Certificate Management Environment (acme)

IETF 116, Thursday, 30 March 2023 0600-0700 UTC, Room: G314-315

Preliminary Agenda

Note Well, technical difficulties and administrivia (chairs) – 5 min

Document Status (chairs) – 10 min

Work items

 - draft-ietf-acme-ari-01 (Gable) - 15 min
 - draft-ietf-acme-dns-account-01-00 (Omidi, Chariton) - 15 min

AOB - 15 min
--
 Yell if you have comments/additions/corrections.  It can be easily
updated.

Also, if you agreed to speak, please upload your briefing materials to the
datatracker page.

Deb and Yoav
acme chairs

On Sat, Feb 25, 2023 at 7:36 AM Deb Cooley  wrote:

> The preliminary acme timeslot is 1500-1600 on Thursday.
>
> Please send in your agenda topics along with how much time you think you
> will need to: acme-cha...@ietf.org by 14 Mar 2023.
>
> We should have one chair in person and one remote (unless things go
> sideways).
>
> Deb Cooley
> for the acme chairs
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] IETF 116

[Deb Cooley]

The preliminary acme timeslot is 1500-1600 on Thursday.

Please send in your agenda topics along with how much time you think you
will need to: acme-cha...@ietf.org by 14 Mar 2023.

We should have one chair in person and one remote (unless things go
sideways).

Deb Cooley
for the acme chairs
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Comment on draft-ietf-acme-subdomains-06: How about using wildcard certificates for subdomains?

[Deb Cooley]

RFC8555 already addresses wildcards, no?

Deb Cooley
ACME chair
deco...@radium.ncsc.mil


On Tue, Jan 31, 2023 at 7:11 AM Yanlei(Ray)  wrote:

> Hi，
>
>
>
> I'm new to this group and sorry for the late comment. I just saw this
> draft and have an idea after reading. I'd like to know from you experts
> whether it's reasonable.
>
>
>
> The illustration in Section 5 uses Subject Alternative Name (SAN) to list
> every subdomain name in a certificate.
>
> I wonder if this mechanism can be replaced by using a wildcard certificate?
>
> Compared with using the Subject Alternative Name (SAN), a wildcard
> certificate can simplify the complexity and reduce the costs for securing a
> number of subdomains.
>
> As the sub-domain name changes, the client with SAN has to re-apply its
> certificate, but the client with wildcard certificate does not need to
> change its certificate.
>
> I think wildcard certificates have been commonly used in subdomains
> management.
>
> As illustrated in Section 5:
>
>   ++  +--+ +-+
>
>   | Client |  | ACME | | DNS |
>
>   +---++  +---+--+ +--+--+
>
>   |||
>
> STEP 1: Pre-Authorization of ancestor domain
>
>   |   .||
>
>   |   .||
>
>   |   .||
>
> STEP 2: Place order for sub1.example.org
>
>   |   .||
>
>   |   .||
>
>   |   .||
>
> STEP 3: Place order for sub2.example.org.
>
>   |   .||
>
>   |   .||
>
>   |   .||
>
>
>
> If there are multiple subdomains, the client has to place an order
> multiple times for every subdomain.
>
> If using a wildcard certificate, the client only needs to place an order
> once for the wildcard certificate.
>
> Then the client can configure its subdomain servers with the same wildcard
> certificate.
>
>   ++  +--+ +-+
>
>   | Client |  | ACME | | DNS |
>
>   +---++  +---+--+ +--+--+
>
>   |||
>
> STEP 1: Pre-Authorization of ancestor domain
>
>   |   .||
>
>   |   .||
>
>   |   .||
>
> STEP 2: Place order for *.example.org|
>
>   |||
>
>
>
>
>
> This is just a preliminary idea, and please correct me if I'm thinking
> wrongly.
>
>
>
> Regards,
>
> Lei YAN
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] draft-todo-chariton-dns-account-01

[Deb Cooley]

While I know it is the holidays for many, the call for adoption will end on
Thursday (4 Jan), so far we have seen no responses...

Deb

On Sat, Dec 10, 2022 at 6:00 AM Deb Cooley  wrote:

> This will be a 3/4 week call for adoption ending on 4 Jan 2023 (because of
> holidays).   Please speak up either for or against adopting this draft.
>
> Thanks,
> Deb and Yoav.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] draft-todo-chariton-dns-account-01

[Deb Cooley]

 This will be a 3/4 week call for adoption ending on 4 Jan 2023 (because of
holidays).   Please speak up either for or against adopting this draft.

Thanks,
Deb and Yoav.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Deb Cooley]

Adoption it is.  Stay tuned for the updated draft.

Deb

On Thu, Dec 1, 2022 at 2:46 PM Sean Turner  wrote:

> I read it and support adoption.
>
> spt
>
> > On Nov 15, 2022, at 13:01, Deb Cooley  wrote:
> >
> > This will be a three week call for adoption ending on 6 Dec. (because of
> holidays in the US).   Please speak up either for or against adopting this
> draft.
> >
> > Thanks,
> > Deb and Yoav.
> >
> > ___
> > Acme mailing list
> > Acme@ietf.org
> > https://www.ietf.org/mailman/listinfo/acme
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Deb Cooley]

This will be a three week call for adoption ending on 6 Dec. (because of
holidays in the US).   Please speak up either for or against adopting this
draft.

Thanks,
Deb and Yoav.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] minutes from today

[Deb Cooley]

 Are here:  https://notes.ietf.org/notes-ietf-115-acme?both

Comments, corrections can be sent to the chairs.  I'd like to post these
early next week.

Deb
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [URL Verdict: Neutral][Non-DoD Source] Re: IETF 115 Agenda items

[Deb Cooley]

That, of course, should be Thursday, 10 Nov 2022.

apologies.

On Tue, Nov 8, 2022 at 9:09 AM Deb Cooley  wrote:

> If you are briefing, please post your briefing to the datatracker, or send
> it to the chairs as soon as possible.
>
>
> Here is our current agenda:
> --
> Automated Certificate Management Environment (acme)
>
> IETF 115, Thursday, 28 July 2022 1530-1630 UTC, Room: Mezzanine 10-11
> (East Wing, First Floor)
>
> Preliminary Agenda
>
> Note Well, technical difficulties and administrivia (chairs) – 5 min
>
> Document Status (chairs) – 10 min
>
> Work items
>
>  - draft-ietf-acme-dtnnodeid-09 (Sipos) - 10 min
>
> New work
>
>  - draft-bweeks-acme-device-attest (Weeks) - 10 min
>  - draft-todo-chariton-dns-account-01 (Omidi, Chariton) - 15 min
>
> AOB - 10 min
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [URL Verdict: Neutral][Non-DoD Source] Re: IETF 115 Agenda items

[Deb Cooley]

 If you are briefing, please post your briefing to the datatracker, or send
it to the chairs as soon as possible.


Here is our current agenda:
--
Automated Certificate Management Environment (acme)

IETF 115, Thursday, 28 July 2022 1530-1630 UTC, Room: Mezzanine 10-11 (East
Wing, First Floor)

Preliminary Agenda

Note Well, technical difficulties and administrivia (chairs) – 5 min

Document Status (chairs) – 10 min

Work items

 - draft-ietf-acme-dtnnodeid-09 (Sipos) - 10 min

New work

 - draft-bweeks-acme-device-attest (Weeks) - 10 min
 - draft-todo-chariton-dns-account-01 (Omidi, Chariton) - 15 min

AOB - 10 min
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] IETF 115 Agenda items

[Deb Cooley]

 acme,

We have a meeting time scheduled for Thursday, Nov 10, 2022, 1530-1630
(meeting time/UTC)

Please send in your agenda topics along with how much time you think you
will need to: acme-cha...@ietf.org by 3 Nov 2022.

We should have one chair in person and one remote (unless things go
sideways).

Thanks,
Deb and Yoav
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Opsdir telechat review of draft-ietf-acme-dtnnodeid-10

[Deb Cooley]

Linda,

I'm now very confused.  The original topic was comments on a DTN acme
draft.  How did we get to discussing Virtual Network IDs of SD-WAN edge
devices?

Do you want to get X.509 certificates for these devices?  Or do you have
something else in mind to validate these devices?

Deb Cooley

On Fri, Oct 21, 2022 at 2:02 PM Linda Dunbar 
wrote:

> Roman,
>
> Thanks.
> I don't see how DTN wg is relevant, as the SD-WAN is NOT Delay Tolerant
> Network. More relevance is on the "certificate issuance mechanism" to
> validate if the IDs advertised by a remote node are legitime.
>
> Does ACME Wg work on "Certificate issuance mechanism" for remote node
> IDs?
>
> Linda
> On 10/21/22, 12:53 PM, "Roman Danyliw"  wrote:
>
> IMO, the simplest thing would be to pose this question on the DTN WG
> mailing list.  This very specific work is being done in the ACME WG because
> it has the expertise on the certificate issuance mechanism, but I see you
> applicability to SD-WAN as more general.
>
> Roman
>
> > -Original Message-
> > From: Linda Dunbar 
> > Sent: Friday, October 21, 2022 1:48 PM
> > To: Roman Danyliw ; ops-...@ietf.org
> > Cc: acme@ietf.org; draft-ietf-acme-dtnnodeid@ietf.org;
> last-c...@ietf.org
> > Subject: Re: Opsdir telechat review of draft-ietf-acme-dtnnodeid-10
> >
> > Roman,
> >
> > Can you give me a few names with who I can chat to find out more?
> >
> > Thank you
> >
> > Linda
> >
> > On 10/21/22, 12:38 PM, "Roman Danyliw"  wrote:
> >
> > Hi Linda!
> >
> > As I understand the scenario below, it would align to the work
> in this
> > document only to the degree that the SD-WAN network would be an
> underlay
> > to the DTN Bundle Protocol (via some as of yet undefined convergence
> layer)
> > and the Virtual Network IDs would have an easy mapping to the
> DTN-specific
> > addressing mechanism (Endpoint IDs per Section 4.2.5 of RFC9171).
> I'll let the
> > DTN experts correct me or provide more insight on the alignment.
> >
> > As an aside, there is a critical IANA issue with this document
> and it is being
> > pulled from the planned telechat docket.
> >
> > Roman
> >
> > > -Original Message-
> > > From: Linda Dunbar 
> > > Sent: Friday, October 21, 2022 12:46 PM
> > > To: Roman Danyliw ; ops-...@ietf.org
> > > Cc: acme@ietf.org; draft-ietf-acme-dtnnodeid@ietf.org;
> last-
> > c...@ietf.org
> > > Subject: Re: Opsdir telechat review of
> draft-ietf-acme-dtnnodeid-10
> > >
> > > Roman,
> > >
> > > Can the mechanism specified in the draft be used to validate
> the Virtual
> > > Network IDs of SD-WAN edge devices?
> > > For example, an SDWAN edge deployed in a remote site, say a
> shopping
> > mall,
> > > might advertise the routes and client VPN IDs to the BGP
> Route-Reflector
> > (RR).
> > > The RR needs to validate the Client's IDs are legitimate. Can
> the mechanism
> > > specified in the draft do the job?
> > >
> > > Thanks, Linda
> > >
> > >
> > > On 10/20/22, 10:36 PM, "Linda Dunbar" <
> linda.dun...@futurewei.com>
> > > wrote:
> > >
> > > Roman,
> > >
> > > With you bringing back the explanation, all makes sense to
> me now.
> > Wish
> > > your explanation is incorporated into the document.
> > > Thanks, Linda
> > >
> > > On 10/20/22, 6:53 PM, "Roman Danyliw" 
> wrote:
> > >
> > > Thanks for the re-review Linda.
> > >
> > > ACME WG: here is the thread from the IETF LC where
> proposed
> > changes
> > > were discussed:
> > >
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarc
> > > hive.ietf.org%2Farch%2Fmsg%2Flast-
> > >
> > call%2FnujBgHd6ZKHY6fG58ZWBKzFGVWs%2F&data=05%7C01%7Clinda.
> > >
> > dunbar%40futurewei.com%7C3d47157879904a302e3

[Acme] Publication has been requested for draft-ietf-acme-subdomains-04

[Deb Cooley via Datatracker]

Deb Cooley has requested publication of draft-ietf-acme-subdomains-04 as 
Proposed Standard on behalf of the ACME working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-acme-subdomains/


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Publication has been requested for draft-ietf-acme-integrations-10

[Deb Cooley via Datatracker]

Deb Cooley has requested publication of draft-ietf-acme-integrations-10 as None 
on behalf of the ACME working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Authority Token WGLC

[Deb Cooley]

As we agreed at the acme session at IETF 114, this is a limited WGLC for
both:

https://datatracker.ietf.org/doc/draft-ietf-acme-authority-token/
https://datatracker.ietf.org/doc/draft-ietf-acme-authority-token-tnauthlist/

I've added stir to the to line for good measure (and to broaden the pool of
reviewers a bit). We need to see if we can push these forward again.

The review deadline is 6 Sep 2022.

Deb Cooley
acme co-chair
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [EXT] Re: I-D Action: draft-ietf-acme-dtnnodeid-09.txt

[Deb Cooley]

A reminder:  we need a few more eyes on this draft to move it forward.

Deb (and Yoav)

On Thu, Jul 28, 2022 at 8:19 PM Deb Cooley  wrote:

> Dear ACME,
>
> We need to get some eyes on this draft - draft-ietf-acme-dtnnodeid.  If
> you have time, please take a look and let us know whether you think it is
> ready (or make comments).  We are hoping to get this draft finished!
>
> Deb Cooley
>
> On Tue, May 24, 2022 at 5:29 PM Sipos, Brian J. 
> wrote:
>
>> All,
>>
>> I haven’t seen any reviews of the last draft version -09. I hope that the
>> closer alignment with RFC 8823 makes its understanding and analysis easier.
>>
>>
>>
>> *From:* Acme  *On Behalf Of *Deb Cooley
>> *Sent:* Tuesday, May 24, 2022 7:39 AM
>> *To:* IETF ACME ; Brian Sipos 
>> *Cc:* Roman Danyliw ; Dorothy E Cooley <
>> deco...@radium.ncsc.mil>
>> *Subject:* [EXT] Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-09.txt
>>
>>
>>
>> *APL external email warning: *Verify sender acme-boun...@ietf.org before
>> clicking links or attachments
>>
>>
>>
>> Did we ever get reviews on the updated draft?  If not, can we get some
>> (or revive the) volunteers?
>>
>>
>>
>> Deb Cooley
>>
>>
>>
>> On Mon, Mar 21, 2022 at 7:12 AM Deb Cooley  wrote:
>>
>> It is on the agenda.  We will ask for volunteers to review.
>>
>>
>>
>> Deb
>>
>>
>>
>> On Sun, Mar 20, 2022 at 5:29 PM Roman Danyliw  wrote:
>>
>> Hi!
>>
>>
>>
>> We’re past IETF LC in terms of document processing and -08 and -09 appear
>> to have changed protocol behavior.  Since there hasn’t been any discussion
>> about this on the mailing list yet, I’d like to ask the WG to review these
>> changes (
>> https://www.ietf.org/rfcdiff?url1=draft-ietf-acme-dtnnodeid-07&url2=draft-ietf-acme-dtnnodeid-09).
>> Please raise any objections by Friday April 1.
>>
>>
>>
>> Helpfully, this document is on the ACME meeting agenda tomorrow at IETF
>> 113.
>>
>>
>>
>> Regards,
>>
>> Roman
>>
>>
>>
>> *From:* Acme  *On Behalf Of *Brian Sipos
>> *Sent:* Wednesday, March 2, 2022 11:27 PM
>> *To:* IETF ACME 
>> *Subject:* Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-09.txt
>>
>>
>>
>> All,
>>
>> I have posted an update to the Node ID Validation document which updates
>> references to now-published DTN RFCs (yay!) and adds algorithm agility for
>> the Key Authorization Digest to avoid the validation method being stuck on
>> SHA-256. It does add a publication dependency on the COSE hash document,
>> but that is in AUTH48 (though it's been stuck in that state for some time
>> now).
>>
>> Comments are welcome and can be discussed at the next IETF.
>>
>> Brian S.
>>
>>
>>
>> On Wed, Mar 2, 2022 at 7:35 PM  wrote:
>>
>>
>> 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   : Automated Certificate Management Environment
>> (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension
>> Author  : Brian Sipos
>> Filename: draft-ietf-acme-dtnnodeid-09.txt
>> Pages   : 31
>> Date: 2022-03-02
>>
>> Abstract:
>>This document specifies an extension to the Automated Certificate
>>Management Environment (ACME) protocol which allows an ACME server to
>>validate the Delay-Tolerant Networking (DTN) Node ID for an ACME
>>client.  The DTN Node ID is encoded as a certificate Subject
>>Alternative Name (SAN) of type otherName with a name form of
>>BundleEID and as an ACME Identifier type "bundleEID".
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-09.html
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-dtnnodeid-09
>>
>>
>> Internet-Drafts are also available by rsync at rsync.ietf.org:
>> :internet-drafts
>>
>>
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [EXT] Re: I-D Action: draft-ietf-acme-dtnnodeid-09.txt

[Deb Cooley]

Dear ACME,

We need to get some eyes on this draft - draft-ietf-acme-dtnnodeid.  If you
have time, please take a look and let us know whether you think it is ready
(or make comments).  We are hoping to get this draft finished!

Deb Cooley

On Tue, May 24, 2022 at 5:29 PM Sipos, Brian J. 
wrote:

> All,
>
> I haven’t seen any reviews of the last draft version -09. I hope that the
> closer alignment with RFC 8823 makes its understanding and analysis easier.
>
>
>
> *From:* Acme  *On Behalf Of *Deb Cooley
> *Sent:* Tuesday, May 24, 2022 7:39 AM
> *To:* IETF ACME ; Brian Sipos 
> *Cc:* Roman Danyliw ; Dorothy E Cooley <
> deco...@radium.ncsc.mil>
> *Subject:* [EXT] Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-09.txt
>
>
>
> *APL external email warning: *Verify sender acme-boun...@ietf.org before
> clicking links or attachments
>
>
>
> Did we ever get reviews on the updated draft?  If not, can we get some (or
> revive the) volunteers?
>
>
>
> Deb Cooley
>
>
>
> On Mon, Mar 21, 2022 at 7:12 AM Deb Cooley  wrote:
>
> It is on the agenda.  We will ask for volunteers to review.
>
>
>
> Deb
>
>
>
> On Sun, Mar 20, 2022 at 5:29 PM Roman Danyliw  wrote:
>
> Hi!
>
>
>
> We’re past IETF LC in terms of document processing and -08 and -09 appear
> to have changed protocol behavior.  Since there hasn’t been any discussion
> about this on the mailing list yet, I’d like to ask the WG to review these
> changes (
> https://www.ietf.org/rfcdiff?url1=draft-ietf-acme-dtnnodeid-07&url2=draft-ietf-acme-dtnnodeid-09).
> Please raise any objections by Friday April 1.
>
>
>
> Helpfully, this document is on the ACME meeting agenda tomorrow at IETF
> 113.
>
>
>
> Regards,
>
> Roman
>
>
>
> *From:* Acme  *On Behalf Of *Brian Sipos
> *Sent:* Wednesday, March 2, 2022 11:27 PM
> *To:* IETF ACME 
> *Subject:* Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-09.txt
>
>
>
> All,
>
> I have posted an update to the Node ID Validation document which updates
> references to now-published DTN RFCs (yay!) and adds algorithm agility for
> the Key Authorization Digest to avoid the validation method being stuck on
> SHA-256. It does add a publication dependency on the COSE hash document,
> but that is in AUTH48 (though it's been stuck in that state for some time
> now).
>
> Comments are welcome and can be discussed at the next IETF.
>
> Brian S.
>
>
>
> On Wed, Mar 2, 2022 at 7:35 PM  wrote:
>
>
> 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   : Automated Certificate Management Environment
> (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension
> Author  : Brian Sipos
> Filename: draft-ietf-acme-dtnnodeid-09.txt
> Pages   : 31
> Date: 2022-03-02
>
> Abstract:
>This document specifies an extension to the Automated Certificate
>Management Environment (ACME) protocol which allows an ACME server to
>validate the Delay-Tolerant Networking (DTN) Node ID for an ACME
>client.  The DTN Node ID is encoded as a certificate Subject
>Alternative Name (SAN) of type otherName with a name form of
>BundleEID and as an ACME Identifier type "bundleEID".
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-09.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-dtnnodeid-09
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] draft-aaron-acme-ari call for adoption

[Deb Cooley]

At the working group session today, we did a quick count for those who
agreed to adopt this draft.  This message is to follow up on this list.  If
anyone disagrees with adoption of this draft, please speak up by 12 August.

Many thanks,

Deb Cooley
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] meeting notes for IETF 114

[Deb Cooley]

We are looking for someone to take notes for the acme mtg today.

Deb Cooley
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] IETF 114 Agenda items

[Deb Cooley]

Here is the agenda.  It is a little light, I'd propose cancelling except we
have new work being proposed.  If you would like a few minutes to talk, let
us know asap, and we will put you on the agenda.

---
Automated Certificate Management Environment (acme)

IETF 114, Thursday, 28 July 2022 1600-1700 EDT (2000-2100 UTC), Room:
Philadelphia North (Mezzanine)

Agenda

Note Well, technical difficulties and administrivia (chairs) – 5 min

Document Status (chairs) – 10 min

Work items

 - draft-ietf-acme-dtnnodeid-09 (Sipos) - 10 min

New work

 - draft-bweeks-acme-device-attest (Weeks) - 15 min

AOB - 10 min


On Tue, Jul 5, 2022 at 2:20 PM Deb Cooley  wrote:

> acme,
>
> We have a meeting time scheduled for Thursday, July 28, 2022, 1600-1700
>
> Please send in your agenda topics along with how much time you think you
> will need to: acme-cha...@ietf.org by 15 July 2022.
>
> We might have both chairs in person (unless things go sideways).  Almost
> like the before times.
>
> Thanks,
> Deb and Yoav
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] IETF 114 Agenda items

[Deb Cooley]

 acme,

We have a meeting time scheduled for Thursday, July 28, 2022, 1600-1700

Please send in your agenda topics along with how much time you think you
will need to: acme-cha...@ietf.org by 15 July 2022.

We might have both chairs in person (unless things go sideways).  Almost
like the before times.

Thanks,
Deb and Yoav
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Call for adoption of draft-aaron-acme-ari-02

[Deb Cooley]

Thanks to Rich, Melinda and Peter for voicing your opinion to adopt this
draft.  We would like it if a few more people would read this draft and
state whether you think it should be adopted (or not).  After the positive
response in Vienna we were a little surprised to see so few responses here.

For your ACME WG Chairs,
Deb

On Wed, Jun 29, 2022 at 1:24 PM Peter Thomassen  wrote:

> Hi Aaron,
>
> On 6/18/22 01:48, Aaron Gable wrote:
> > You can find prior discussion in these threads:
> > -
> https://mailarchive.ietf.org/arch/msg/acme/b-RddSX8TdGYvO3f9c7Lzg6I2I4/ <
> https://mailarchive.ietf.org/arch/msg/acme/b-RddSX8TdGYvO3f9c7Lzg6I2I4/>,
> the very original proposal, which discusses are variety of motivations and
> alternate implementations
> > -
> https://mailarchive.ietf.org/arch/msg/acme/UMRzzS6yh-D6ViwjYt0fgx213qY/ <
> https://mailarchive.ietf.org/arch/msg/acme/UMRzzS6yh-D6ViwjYt0fgx213qY/>,
> my revival of the idea, which addresses some of the concerns in the
> original thread
>
> Thank you for these pointers.
>
> > It's not my experience that RFCs in this space dedicate significant
> space in their text to discussing alternative designs, but if others would
> like to see a section like that added to the draft I'm happy to oblige.
>
> I don't think much argument is needed, but I think it would be helpful to
> add at least one compelling use case to the introduction that hints at the
> insufficiency of the obvious alternatives that would come to mind (that is,
> client-side jittering). Perhaps like this (drop-in for the last paragraph):
>
> Being able to indicate to the client a period in which the issuing CA
> suggests renewal would allow proactive smearing of load (as client-side
> jittering would), but also enable dynamic changes to the certificate
> validity period, such as in the event of mass-revocation of a large
> number of certificates, and help restore normality after such an event
> by having clients quickly redistribute from the sudden renewal spike to
> a moreuniform renewal schedule.
>
> This document specifies a mechanism by which ACME servers may provide
> suggestedrenewal windows to ACME clients.
>
> > Yes, of course clients could simply implement smearing on their own. But
> they have little motivation to do so -- there's no standard documenting how
> they should do so, and it's statistically rare that any one out of hundreds
> of millions of clients is the one affected by a given load spike. They can
> just retry and be fine. Having a standard for this provides a template or
> framework to encourage clients to all implement this in the same way.
>
> I'm afraid there will be little motivation for updating legacy clients,
> regardless of whether the update would bring client-side ARI support (as
> documented by a standard) or client-side smearing (which could also be
> standardized).
>
> It's the typical upgrade-with-backwards-compatibility problem: Unless ACME
> servers would REQUIRE clients to support ARI (which would be a breaking
> change), clients might not upgrade. If they do, chances are that they have
> a proper update process, in which case they'd receive any update,
> regardless of which solution is standardized.
>
> So, regarding client-side deployability, I think that ARI has no advantage
> over client-side smearing.
>
> > Suppose that a CA revokes and replaces 100M certificates in a single
> day. Suppose further that, as you suggest, they smear their validity
> periods by 1%, meaning that clients will try to renew somewhere between 59
> and 61 days after the incident. How many renewal cycles will it take for
> that 100M-cert-tall load spike to flatten back out into the whole 60 days
> of smooth issuance it previously covered?
>
> Convinced!
>
> > Suppose that a CA suffers an incident and knows that they will have to
> revoke and replace 100M certificates in the next 24 hours. They could
> configure ARI to give all clients a renewal window in the past, encouraging
> every client that checks in to immediately renew their certificate,
> minimizing the real-world impact of a mass revocation event. And then they
> go immediately to the case described above, to prevent additional fallout.
>
> That's very convincing, too. I think it would help if the intro gave a
> glimpse of these use cases.
>
> > I hope this provides more insight into why we've gone this direction
> with the design, and why the draft is important!
>
> Surely, thanks! I hope I did not hold up the draft with my critical
> questions :-) Thank you for being open for discussion.
>
> I support adoption.
>
> Best,
> Peter
>
> --
> https://desec.io/
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] WG Last Call for draft-ietf-acme-integrations-08

[Deb Cooley]

 Let's do another WGLC, if that's ok.  Please respond by 15 July (after the
ID draft cutoff, but hopefully we won't need another version).

Title:  ACME Integrations

Authors: O.Friel, R.Barnes, R. Shekh-Yusef, M.Richardson

Datatracker: https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/


This document outlines multiple advanced use cases and integrations
that ACME facilitates without any modifications or
enhancements required to the base ACME specification.  The use cases
include ACMEintegration with EST, BRSKI and TEAP.

For the ACME WG Chairs,

Deb
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] WG Last Call for draft-ietf-acme-integrations-07

[Deb Cooley]

Thanks for the two reviews w/ comments.  When the authors have addressed
the comments, we can issue a short WGLC.

For the ACME chairs,
Deb Cooley

On Fri, May 27, 2022 at 9:44 AM Carl Wallace 
wrote:

> I’ll reply here to add one comment. The introduction of the potential for
> errors due to domains the RA is authorized for and those may be requested
> is not called out to any extent. It is likely something that is mostly
> addressed by authentication to the RA and could be noted as such in section
> 7.1.  Section 7.5 gets at the issue with the mapping for badIdentity, but
> it could be called out as something that occurs upon submission of request
> to the RA (vs mapping an ACME error back to the protocol of interest after
> failed interaction with the ACME server).
>
>
>
> *From: *Acme  on behalf of Russ Housley <
> hous...@vigilsec.com>
> *Date: *Thursday, May 26, 2022 at 10:25 AM
> *To: *Deb Cooley , Dorothy E Cooley <
> deco...@radium.ncsc.mil>
> *Cc: *IETF ACME 
> *Subject: *Re: [Acme] WG Last Call for draft-ietf-acme-integrations-07
>
>
>
> I have a few comments.  Only one of them will be difficult to sort out.
>
>
>
> Section 1, para 1: Please add a cite to [RFC5280] after "X.509 (PKIX)
> certificate".
>
>
>
> Section 1, last para: Please reword.  Something like:
>
>
>
>Optionally, ACME for subdomains [I-D.ietf-acme-subdomains] offers a
>
>useful optimization when ACME is used to issue certificates for large
>
>numbers of devices; it reduces the domain ownership proof traffic as
>
>well as the ACME traffic overhead.  This is accomplished by completing
>
>a challenge against the parent domain instead of a challenge against
>
>each explicit subdomain. Use of ACME for subdomains is not a
>
>necessary requirement.
>
>
>
> Section 2: Please add a reference for CSR.  Consider [RFC2986].
>
>
>
> Section 2: Please add a reference for RA.  Consider [RFC5280].
>
>
>
> Section 2: Please add a reference for TLV.  Consider [RFC7170].
>
>
>
> Section 4: Please fix the markdown typo: Refer to section {csr-attributes}
> for more details.
>
>
>
> Section 7.2 says:
>
>
>
>EST [RFC7030] is not clear on how the CSR Attributes response should
>
>be structured, and in particular is not clear on how a server can
>
>instruct a client to include specific attribute values in its CSR.
>
>[I-D.richardson-lamps-rfc7030-csrattrs] clarifies how a server can
>
>use CSR Attributes response to specify specific values for attributes
>
>that the client should include in its CSR.
>
>
>
>Servers MUST use this mechanism to tell the client what identifiers
>
>to include in CSR request. ...
>
>
>
> This is a MUST, but is is not really nailed down.  Can we get to a simple
> MUST statement here?  If not, can we at least narrow the possibilities?
>
>
>
> Section 7.2: s/The identifier must/The identifier MUST/
>
>
>
> Section 7.3: s/certificate MAY be omitted from the chain/certificate
> SHOULD be omitted from the chain/
>
>
>
> Section 7.3.2: Please provide references for PKCS#7 and PKCS#10.
>
>
>
> Section 7.4: s/id-kp-cmcRA extended key usage bit/id-kp-cmcRA extended key
> usage OID/ (multiple places)
>
>
>
> Russ
>
>
>
>
>
> On May 26, 2022, at 6:58 AM, Deb Cooley  wrote:
>
>
>
> Title:  ACME Integrations
>
>
>
> Authors: O.Friel, R.Barnes, R. Shekh-Yusef, M.Richardson
>
> Datatracker:
> https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/
> <https://datatracker.ietf.org/doc/draft-ietf-lamps-8410-ku-clarifications>
>
> This document outlines multiple advanced use cases and integrations that ACME 
> facilitates without any modifications or
> enhancements required to the base ACME specification.  The use cases include 
> ACMEintegration with EST, BRSKI and TEAP.
>
>
> Please respond to this WG last Call by 9 June 2022.
>
> For the ACME WG Chairs,
> Deb
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
>
>
> ___ Acme mailing list
> Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] WG Last Call for draft-ietf-acme-subdomains-03

[Deb Cooley]

We've seen two responses to the WGLC (one with nits).  Can we get a few
more reviews?  From people that are not authors?

For the ACME WG chairs,
Deb Cooley

On Mon, Jun 6, 2022 at 12:36 PM Deb Cooley  wrote:

> A couple of more days for this WGLC and crickets
>
> For the ACME WG chairs,
> DebCooley
>
> On Thu, May 26, 2022 at 7:03 AM Deb Cooley  wrote:
>
>> Title:  ACME for Subdomains
>>
>> Authors: O.Friel, R.Barnes, T.Hollebeek, M.Richardson
>>
>> Datatracker:
>> https://datatracker.ietf.org/doc/draft-ietf-acme-subdomains/
>>
>> This document outlines how ACME can be used by a client to obtain a 
>> certificate for a subdomain identifier
>> from a certification authority.
>>
>>
>> Please respond to this WG last Call by 9 June 2022.
>>
>> For the ACME WG Chairs,
>> Deb
>>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] WG Last Call for draft-ietf-acme-subdomains-03

[Deb Cooley]

A couple of more days for this WGLC and crickets

For the ACME WG chairs,
DebCooley

On Thu, May 26, 2022 at 7:03 AM Deb Cooley  wrote:

> Title:  ACME for Subdomains
>
> Authors: O.Friel, R.Barnes, T.Hollebeek, M.Richardson
>
> Datatracker:  https://datatracker.ietf.org/doc/draft-ietf-acme-subdomains/
>
>
> This document outlines how ACME can be used by a client to obtain a 
> certificate for a subdomain identifier
> from a certification authority.
>
>
> Please respond to this WG last Call by 9 June 2022.
>
> For the ACME WG Chairs,
> Deb
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] WG Last Call for draft-ietf-acme-subdomains-03

[Deb Cooley]

 Title:  ACME for Subdomains

Authors: O.Friel, R.Barnes, T.Hollebeek, M.Richardson

Datatracker:  https://datatracker.ietf.org/doc/draft-ietf-acme-subdomains/

This document outlines how ACME can be used by a client to obtain a
certificate for a subdomain identifier
from a certification authority.


Please respond to this WG last Call by 9 June 2022.

For the ACME WG Chairs,
Deb
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] WG Last Call for draft-ietf-acme-integrations-07

[Deb Cooley]

 Title:  ACME Integrations

Authors: O.Friel, R.Barnes, R. Shekh-Yusef, M.Richardson

Datatracker: https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/


This document outlines multiple advanced use cases and integrations
that ACME facilitates without any modifications or
enhancements required to the base ACME specification.  The use cases
include ACMEintegration with EST, BRSKI and TEAP.


Please respond to this WG last Call by 9 June 2022.

For the ACME WG Chairs,
Deb
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Deb Cooley]

Did we ever get reviews on the updated draft?  If not, can we get some (or
revive the) volunteers?

Deb Cooley

On Mon, Mar 21, 2022 at 7:12 AM Deb Cooley  wrote:

> It is on the agenda.  We will ask for volunteers to review.
>
> Deb
>
> On Sun, Mar 20, 2022 at 5:29 PM Roman Danyliw  wrote:
>
>> Hi!
>>
>>
>>
>> We’re past IETF LC in terms of document processing and -08 and -09 appear
>> to have changed protocol behavior.  Since there hasn’t been any discussion
>> about this on the mailing list yet, I’d like to ask the WG to review these
>> changes (
>> https://www.ietf.org/rfcdiff?url1=draft-ietf-acme-dtnnodeid-07&url2=draft-ietf-acme-dtnnodeid-09).
>> Please raise any objections by Friday April 1.
>>
>>
>>
>> Helpfully, this document is on the ACME meeting agenda tomorrow at IETF
>> 113.
>>
>>
>>
>> Regards,
>>
>> Roman
>>
>>
>>
>> *From:* Acme  *On Behalf Of * Brian Sipos
>> *Sent:* Wednesday, March 2, 2022 11:27 PM
>> *To:* IETF ACME 
>> *Subject:* Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-09.txt
>>
>>
>>
>> All,
>>
>> I have posted an update to the Node ID Validation document which updates
>> references to now-published DTN RFCs (yay!) and adds algorithm agility for
>> the Key Authorization Digest to avoid the validation method being stuck on
>> SHA-256. It does add a publication dependency on the COSE hash document,
>> but that is in AUTH48 (though it's been stuck in that state for some time
>> now).
>>
>> Comments are welcome and can be discussed at the next IETF.
>>
>> Brian S.
>>
>>
>>
>> On Wed, Mar 2, 2022 at 7:35 PM  wrote:
>>
>>
>> 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   : Automated Certificate Management Environment
>> (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension
>> Author  : Brian Sipos
>> Filename: draft-ietf-acme-dtnnodeid-09.txt
>> Pages   : 31
>> Date: 2022-03-02
>>
>> Abstract:
>>This document specifies an extension to the Automated Certificate
>>Management Environment (ACME) protocol which allows an ACME server to
>>validate the Delay-Tolerant Networking (DTN) Node ID for an ACME
>>client.  The DTN Node ID is encoded as a certificate Subject
>>Alternative Name (SAN) of type otherName with a name form of
>>BundleEID and as an ACME Identifier type "bundleEID".
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-09.html
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-dtnnodeid-09
>>
>>
>> Internet-Drafts are also available by rsync at rsync.ietf.org:
>> :internet-drafts
>>
>>
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Call for adoption of draft-aaron-acme-ari-02

[Deb Cooley]

 There has been some discussion of draft-aaron-acme-ari-02 on the mail
list, at working group meetings, and the technical concerns have been
addressed.

Should the ACME WG adopt “Automated Certificate Management Environment
(ACME) Renewal Information (ARI) Extension” in draft-aaron-acme-ari-02?

Please reply to this message within the next two weeks, by Tuesday, 7 June
2022 to voice your support or opposition to adoption.

On behalf of the ACME WG Chairs,
  Deb Cooley
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] note takers

[Deb Cooley]

All,

The finished notes for IETF 113 are at:
https://notes.ietf.org/notes-ietf-113-acme?view

Many, many thanks to Aaron Gable who took fantastic notes.

Comments?  Corrections?  Additions?  Speak now, because I'm going to
publish these soonish (like today).

Deb

On Mon, Mar 21, 2022 at 7:14 AM Deb Cooley  wrote:

> Don't wait until the last minute volunteer now to take notes.
>
> the acme chairs.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] ACME WG report

[Deb Cooley]

The ACME working group met on Monday afternoon with about 10 people in
person and another 12-15 online.

Work:
2 drafts are in IESG Evaluation:  ACME Authority Token + ACME Authority
Token TNAuthlist, small changes required.  Authors have been contacted.

1 experimental draft in IESG evaluation: draft-ietf-acme-dtnnodeid, needs
review by the working group.

2 drafts ready for WGLC: draft-ietf-acme-integrations and
draft-ietf-acme-subdomains after authors finish cleanup.

1 draft ready for working group adoption request: draft-aaron-acme-ari
after updating to the next revision.
and
1 draft in development:  draft-ietf-acme-client.


Deb and Yoav
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] note takers

[Deb Cooley]

Don't wait until the last minute volunteer now to take notes.

the acme chairs.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Deb Cooley]

It is on the agenda.  We will ask for volunteers to review.

Deb

On Sun, Mar 20, 2022 at 5:29 PM Roman Danyliw  wrote:

> Hi!
>
>
>
> We’re past IETF LC in terms of document processing and -08 and -09 appear
> to have changed protocol behavior.  Since there hasn’t been any discussion
> about this on the mailing list yet, I’d like to ask the WG to review these
> changes (
> https://www.ietf.org/rfcdiff?url1=draft-ietf-acme-dtnnodeid-07&url2=draft-ietf-acme-dtnnodeid-09).
> Please raise any objections by Friday April 1.
>
>
>
> Helpfully, this document is on the ACME meeting agenda tomorrow at IETF
> 113.
>
>
>
> Regards,
>
> Roman
>
>
>
> *From:* Acme  *On Behalf Of * Brian Sipos
> *Sent:* Wednesday, March 2, 2022 11:27 PM
> *To:* IETF ACME 
> *Subject:* Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-09.txt
>
>
>
> All,
>
> I have posted an update to the Node ID Validation document which updates
> references to now-published DTN RFCs (yay!) and adds algorithm agility for
> the Key Authorization Digest to avoid the validation method being stuck on
> SHA-256. It does add a publication dependency on the COSE hash document,
> but that is in AUTH48 (though it's been stuck in that state for some time
> now).
>
> Comments are welcome and can be discussed at the next IETF.
>
> Brian S.
>
>
>
> On Wed, Mar 2, 2022 at 7:35 PM  wrote:
>
>
> 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   : Automated Certificate Management Environment
> (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension
> Author  : Brian Sipos
> Filename: draft-ietf-acme-dtnnodeid-09.txt
> Pages   : 31
> Date: 2022-03-02
>
> Abstract:
>This document specifies an extension to the Automated Certificate
>Management Environment (ACME) protocol which allows an ACME server to
>validate the Delay-Tolerant Networking (DTN) Node ID for an ACME
>client.  The DTN Node ID is encoded as a certificate Subject
>Alternative Name (SAN) of type otherName with a name form of
>BundleEID and as an ACME Identifier type "bundleEID".
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-09.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-dtnnodeid-09
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] agenda

[Deb Cooley]

The agenda is posted (copied below)

A couple of notes:
1.  Meetecho will have two tools - a mobile phone icon for use at the venue
(without sound), and another icon for remote use.
2.  The microphone queue will be via Meetecho - even if one is actually in
the room.  (there will be a camera on the microphone - so remote people can
see it)
3.  For those presenting, please upload your briefings (or send to us and
we will upload)
4.  And of course, we are looking for a notes taker...

Your acme chairs, Yoav and Deb

--

Automated Certificate Management Environment (acme)

IETF 113, Monday, 21 March 2022 1300-1400 CET (1200-1300 UTC)
Note: Europe doesn't move to DST/Summertime until 27 Mar - huzzah!

MeetEcho link: https://wws.conf.meetecho.com/conference/?group=acme

Agenda

Note Well, technical difficulties and administrivia (chairs) – 5 min

Document Status (chairs) – 10 min

Work items

 - draft-ietf-acme-dtnnodeid-09 (Sipos) - 10 min
 - draft-aaron-acme-ari-01 (Gable) - 15min
 - draft-ietf-acme-integrations-06 (Shekh-Yusef) - 5 minutes
 - draft-ietf-acme-subdomains-02 (Richardson) - 5 minutes

AOB - 10 min
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] IETF 113 agenda items

[Deb Cooley]

 acme,

We have a meeting time scheduled for Monday, 21 March 2022, 1300-1400

Please send in your agenda topics along with how much time you think you
will need to: acme-cha...@ietf.org by 14 March 2022.

We will likely have one chair in person (unless things go sideways) and one
remote.  Should be fun.

Deb and Yoav
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] subdomain draft -01

[Deb Cooley]

Here are two ridiculously simple comments - both are merely typos.

Section 2:  CA definition typo:  s/Roots CAs/Root CAs.

Section 5, page 14, step 3:  Typo.  The server replies w/ an identifier of "
sub1.example.org" instead of “sub2.example.com”.


Deb Cooley

deco...@nsa.gov
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] acme-subdomains RFC8499 vs. CA/B terminology

[Deb Cooley]

Sounds like a good path forward.

Deb Cooley
deco...@nsa.gov

On Fri, Dec 10, 2021 at 9:04 AM Daniel Migault  wrote:

> I also prefer 8499 terminology.
> Yours,
> Daniel
>
> On Fri, Dec 10, 2021 at 4:40 AM Owen Friel (ofriel)  40cisco@dmarc.ietf.org> wrote:
>
>> I mentioned it at IETF 112 that we needed to decide on use of RFC8499 vs.
>> CA/B forum terminology in the document.
>>
>>
>>
>> As this document is not specific to Web PKI use cases, I prefer RFC8499
>> terminology.
>>
>>
>>
>> Martin expressed that preference too:
>> https://mailarchive.ietf.org/arch/msg/acme/Yh1YbtqZy9rwOmInU1KyJdADTE4/
>>
>>
>>
>> For acme-integrations, Deb also preferred RFC8499:
>> https://mailarchive.ietf.org/arch/msg/acme/Hj1PwYuO0zWdXG4HOPGOs8cVNw4/
>>
>>
>>
>> So unless I hear otherwise, I will publish a draft-01 with updated
>> RFC8499 terminology, that also addresses Daniels comments
>> https://mailarchive.ietf.org/arch/msg/acme/Px0d5MG5_fC490PmEUSRAcsCAF0/
>> , before the holiday break.
>>
>>
>>
>> Cheers,
>>
>> Owen
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
>
> --
> Daniel Migault
> Ericsson
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] comments on: draft-ietf-acme-integrations-05

[Deb Cooley]

No hats (oh that was fun!).


Most of these are very minor.  In full disclosure, I don't have a ton of
experience on either ACME message exchanges or TEAP:


Section 2:  I like the DNS terminology (I can’t say if they are correct).  For
me, they are clear and easy to understand.

Section 2:  CMS – spell this out the first time.

Section 3:  This might be picky, but sometimes it is difficult to
distinguish between ACME the protocol and ACME the CA.  For example, the
call flow chart has a node ‘ACME’, this is the CA, correct?  If you wanted
to clarify this, I think it would be as easy to change the node to ‘ACME
CA’.  Again, I will freely admit this might be picky…

Section 4, para 1:   Spell out MASA somewhere.  Maybe in the terms in
Section 2.  I know MASA is defined in BRSKI, but this would at least give
the reader a hint.

Section 6:

TLV?  (This means tag length value, but clearly that is wrong).

I know nothing about TEAP, but does the server initiate normally? (I’m used
to seeing client-initiated exchanges)

And this is not for this document, per se, but does TEAP use TLS1.2 (it
doesn’t look like TLS 1.3 – change cipher spec, for example)?


Deb Cooley

deco...@nsa.gov
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] draft minutes for IETF 112 acme meeting

[Deb Cooley]

Thank you to all who participated!

The draft minutes are here:  https://notes.ietf.org/notes-ietf-112-acme#

Please review and verify they are correct.  I'll post the final version,
probably later next week.

Deb and Yoav.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] IETF 112 acme agenda

[Deb Cooley]

Here is the agenda for Thursday's session.
Comments and revisions welcome.



Automated Certificate Management Environment (acme)

IETF 112, Thursday, 11 November 2021 1430-1530 UTC

MeetEcho link:
https://meetings.conf.meetecho.com/ietf112/?group=acme&short=&item=1

Agenda

Note Well, technical difficulties and administrivia (chairs) – 5 min
IETF Code of Conduct (chairs) - 5 min
Document Status (chairs) – 5 min

Work items

 - draft-ietf-acme-dtnnodeid-06 (Sipos) - 10 min
 - draft-aaron-acme-ari-00 (Gable) - 10 min
 - draft-ietf-acme-integrations (Friel, Shekh-Yusef, Richardson) - 10
minutes
 - draft-ietf-acme-subdomains (Friel, Barnes, Hollebeek, Richardson) - 10
minutes

AOB - 5 min
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Agenda items for IETF 112

[Deb Cooley]

 acme,

We have a meeting time scheduled for Thursday, 11 November 2021 from
1430-1530 (UTC).

Please send in your agenda topics along with how much time you think you
will need to: acme-cha...@ietf.org by 4 November 2021.

wishing we were actually in Madrid,
Deb and Yoav
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] acme interim

[Deb Cooley]

A quick reminder.  Our interim is on Wed at 1800-1900 UTC.  The agenda is
up on the data tracker as well as the meetecho link.

If you are briefing and would like slides posted, let us know (unless you
can merely post them yourself - rookie co-chair here).

Also if someone wants to volunteer to be a minute taker, we would be
forever grateful.

Deb (and Yoav)

On Fri, Sep 24, 2021 at 12:08 PM Deb Cooley  wrote:

> ACME Interim Meeting, Wednesday 29 Sep 2021 from 18:00 to 19:00 UTC
>
> Meetecho link:
> https://meetings.conf.meetecho.com/interim/?short=b6634a5b-f143-4a07-b745-d7854df55b5f
>
> Note Well, technical difficulties and administrivia – 5 minutes
> Delay-Tolerant Networking (DTN) Node ID Update - Brian Sipos - 5 minutes
> draft-ietf-acme-integrations Update - Friel, Shekh-Yusef, Richardson - 10
> minutes
> draft-friel-acme-subdomains Update - Friel, Shekh-Yusef, Richardson - 10
> minutes
> Automated Certificate Renewal Environment (ACME) Renewal Information (ARI)
> Extension - Aaron Gable - 20 minutes
> Any other business (AOB) and/or recap - All - 10 min
>
> I'll upload this too (as soon as I figure out how).
> Deb Cooley (and Yoav Nir)
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] acme interim

[Deb Cooley]

ACME Interim Meeting, Wednesday 29 Sep 2021 from 18:00 to 19:00 UTC

Meetecho link:
https://meetings.conf.meetecho.com/interim/?short=b6634a5b-f143-4a07-b745-d7854df55b5f

Note Well, technical difficulties and administrivia – 5 minutes
Delay-Tolerant Networking (DTN) Node ID Update - Brian Sipos - 5 minutes
draft-ietf-acme-integrations Update - Friel, Shekh-Yusef, Richardson - 10
minutes
draft-friel-acme-subdomains Update - Friel, Shekh-Yusef, Richardson - 10
minutes
Automated Certificate Renewal Environment (ACME) Renewal Information (ARI)
Extension - Aaron Gable - 20 minutes
Any other business (AOB) and/or recap - All - 10 min

I'll upload this too (as soon as I figure out how).
Deb Cooley (and Yoav Nir)
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] acme interim

[Deb Cooley]

I've made a request (to Meetecho and to IETF) for an acme interim meeting
on 29 Sep 1800-1900 UTC.

There is a tentative agenda:

Updates on current work items
Aaron Gable's work
New work proposals

If you have a current or proposed work item and would like to brief, please
send a note to the chairs.
If you have a new work proposal, please send a note to the chairs.

Many thanks and we will 'see' you on 29 Sep.

Deb Cooley


On Tue, Sep 7, 2021 at 5:58 AM Deb Cooley  wrote:

> Currently 3 people have voted on the Doodle poll.  Less than inspiring, in
> my opinion.  Please let us know if you can/want to attend.  If you would
> rather reply to this message instead of the poll, that is fine too.  You
> have until 10 Sep...
>
> Deb Cooley
>
> On Wed, Sep 1, 2021 at 9:55 AM Cooley, Dorothy E  40nsa@dmarc.ietf.org> wrote:
>
>> Possible agenda items might include:
>>
>> Aaron Gable's work (see his message to the list sent on 20 Aug)
>> Updates on current work items
>> New work proposals
>>
>> This is an attempt to re-energize the group.  If there is interest in
>> work, then it needs to be proposed or discussed.
>>
>> Deb Cooley
>> deco...@nsa.gov
>>
>>
>> -Original Message-
>> From: Cooley, Dorothy E
>> Sent: Tuesday, August 31, 2021 3:33 PM
>> To: 'acme@ietf.org' 
>> Subject: acme interim
>>
>> Attached is a doodle poll to choose an acme interim date (29 Sep-1 Oct).
>> Please vote for all the days/times you can support.  We'd like to have this
>> sorted by 10 Sep, if possible.
>>
>> https://doodle.com/poll/wbp3qkumfua6b2b5?utm_source=poll&utm_medium=link
>>
>> In addition, if you have topics/presentations you would like to add to
>> the interim agenda, then please let the chairs know.
>>
>> Thanks,
>>
>> Deb and Yoav
>>
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] acme interim

[Deb Cooley]

Currently 3 people have voted on the Doodle poll.  Less than inspiring, in
my opinion.  Please let us know if you can/want to attend.  If you would
rather reply to this message instead of the poll, that is fine too.  You
have until 10 Sep...

Deb Cooley

On Wed, Sep 1, 2021 at 9:55 AM Cooley, Dorothy E  wrote:

> Possible agenda items might include:
>
> Aaron Gable's work (see his message to the list sent on 20 Aug)
> Updates on current work items
> New work proposals
>
> This is an attempt to re-energize the group.  If there is interest in
> work, then it needs to be proposed or discussed.
>
> Deb Cooley
> deco...@nsa.gov
>
>
> -Original Message-
> From: Cooley, Dorothy E
> Sent: Tuesday, August 31, 2021 3:33 PM
> To: 'acme@ietf.org' 
> Subject: acme interim
>
> Attached is a doodle poll to choose an acme interim date (29 Sep-1 Oct).
> Please vote for all the days/times you can support.  We'd like to have this
> sorted by 10 Sep, if possible.
>
> https://doodle.com/poll/wbp3qkumfua6b2b5?utm_source=poll&utm_medium=link
>
> In addition, if you have topics/presentations you would like to add to the
> interim agenda, then please let the chairs know.
>
> Thanks,
>
> Deb and Yoav
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] minutes for IETF 111 posted

[Deb Cooley]

Minutes for IETF 111 have been posted @
https://datatracker.ietf.org/doc/minutes-111-acme/  (yes it took Deb a
couple of tries whatever)

If you have corrections/changes/modifications, please send them on the list.

Thank you,
Deb and Yoav
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Agenda items

[Deb Cooley]

This is your reminder to let us know if you are interested in presenting.
We need to get this sorted soon...

Deb Cooley
deco...@nsa.gov

On Thu, Jul 22, 2021 at 4:08 PM Deb Cooley  wrote:

> There are a couple of items that should probably be discussed.  If you are
> interested in being added to the agenda next week, let the chairs know
> soonest.
>
> *Current drafts (and their state):*
>
> draft-ietf-acme-integrations-04
> draft-friedl-acme-subdomains-05
>
> draft-biggs-acme-sso-01:  status?
>
> draft-ietf-acme-authority-token-06: recently updated and in AD evaluation.
> draft-ietf-acme-authority-tnauthlist-08:  waiting for the above
>
> draft-ietf-acme-dtnnodeid-04: submitted for AD evaluation (author
> unavailable for IETF 111)
>
> draft-ietf-acme-star-delegation-09:  in the RFC Editor's queue
>
> New work?  Or are we almost done here?
>
> Deb Cooley
> deco...@nsa.gov
>
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Agenda items

[Deb Cooley]

There are a couple of items that should probably be discussed.  If you are
interested in being added to the agenda next week, let the chairs know
soonest.

*Current drafts (and their state):*

draft-ietf-acme-integrations-04
draft-friedl-acme-subdomains-05

draft-biggs-acme-sso-01:  status?

draft-ietf-acme-authority-token-06: recently updated and in AD evaluation.
draft-ietf-acme-authority-tnauthlist-08:  waiting for the above

draft-ietf-acme-dtnnodeid-04: submitted for AD evaluation (author
unavailable for IETF 111)

draft-ietf-acme-star-delegation-09:  in the RFC Editor's queue

New work?  Or are we almost done here?

Deb Cooley
deco...@nsa.gov
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Changes in ACME WG leadership team

[Deb Cooley]

Thanks!  I’m looking forward to contributing. 

Many thanks to Rich Salz for many years of hard work!

Deb Cooley

> On Jul 9, 2021, at 2:57 PM, Yoav Nir  wrote:
> 
> Welcome aboard, Deb!
> 
> 
> 
>> On 9 Jul 2021, at 19:26, Roman Danyliw  wrote:
>> 
>> Hi!
>> 
>> To follow up on the announcement during IETF 109, after 6 years of leading 
>> the ACME WG from the very first BoF, Rich will be stepping down as co-chair. 
>>  Under his stewardship, a working group was formed, the core specifications 
>> were completed, and most importantly, they saw adoption.  The underlying 
>> ACME technology, and the services using it, have profoundly lowered the 
>> barrier to secure communication over the Internet.  
>> 
>> Rich: This achievement is due to your time, commitment and leadership.  A 
>> profound thank you!
>> 
>> I'm excited to announce that Deb Cooley has graciously agreed to serve as 
>> the co-chair with Yoav.  Deb brings top-sight of the security area having 
>> worked in a number WGs, and a deep understanding of certificate technologies 
>> and associated ecosystems.
>> 
>> Please join me in thanking Rich for his years of service in the WG, and 
>> welcoming Deb to the new role.
>> 
>> Regards,
>> Roman
>> 
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
> 

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] comments on: draft-ietf-acme-integrations-03.txt

[Deb Cooley]

 Sorry, I've been pulled in too many different directions.

That message flow would work, I think.  Getting a CSR, properly
constructed, signed, etc. from the pledge is key.  The CA can make changes
before issuing a certificate, but the RA cannot.  The two step process is
the only way I can see to automate what we do manually today.

Michael Richardson's 'civil serpents' made me laugh.  Although most of
those 'serpents' are military or contractors.  In the end, the easier we
can make it for them to do the 'right' thing, the better off we will be.

Deb Cooley

On Tue, Jun 15, 2021 at 2:50 AM Owen Friel (ofriel) 
wrote:

> Deb in your govt PKI world then, would the flow be something like:
>
>
>
>
>
> There is no CSR Attributes exchange that allows the RA to tell the Pledge
> to use a particular CN/SAN.
>
>
>
> Pledge sends CSR with, say, SAN=serialnumberx
>
>
>
> RA sends newOrder with identifier= serialnumberx
>
>
>
> ACME CA decides that the identity should be “
> serialnumberx.devices.some-gov-dept.example.org” (e.g. based on the RA
> identity)
>
>
>
> ACME returns an authorization challenge for “serialnumberx.devices.
> some-gov-dept.example.org” to the RA.
>
>
>
> The RA must then prove ownership of that DNS domain before the ACME CA
> will issue the cert.
>
>
>
>
>
>
>
>
>
> This is how we envisaged the enterprise/civilian workflow:
>
>
>
> RA owns the domain e.g. devices.ra.example.org
>
>
>
> Pledge connects to RA using its IDevID and sends CSR Attributes request
>
>
>
> RA extracts serial#=abc123 (or whatever) from IDevID and appends domain to
> it
>
>
>
> RA tells pledge in CSR Attributes response to include e.g. SAN=
> abc123.devices.ra.example.org in CSR
>
>
>
> Pledge sends CSR with SAN= abc123.devices.ra.example.org
>
>
>
> RA sends newOrder with identifier= abc123.devices.ra.example.org
>
>
>
> ACME returns an authorization challenge for abc123.devices.ra.example.org
>
>
>
> RA proves ownership of abc123.devices.ra.example.org and ACME issues cert.
>
>
>
> (or using acme-subdomains, proves ownership of devices.ra.example.org)
>
>
>
>
>
>
>
>
>
> *From:* Deb Cooley 
> *Sent:* 10 June 2021 17:52
> *To:* Michael Richardson 
> *Cc:* Owen Friel (ofriel) ; acme@ietf.org; Cooley,
> Dorothy E 
> *Subject:* Re: [Acme] comments on: draft-ietf-acme-integrations-03.txt
>
>
>
> Michael,
>
>
>
> In my world (government PKI systems), the RA doesn't get to do that.
> Either the CSR is accepted or it is rejected.  The CA has a profile it
> follows, if the CSR is missing things, the CA adds them before the
> certificate is signed.  The RA can do none of that.  In our case, most RAs
> are actually people, so there can be a back channel to the requestor which
> can be used to sort it all out.
>
>
>
> How this all happens in the case of 'little things', I don't know.  We do
> have a 'portal' for devices, but it would probably be quite 'heavy' for
> your use cases.
>
>
>
>
>
>
>
>
>
> On Tue, Jun 8, 2021 at 4:15 PM Michael Richardson 
> wrote:
>
>
> Owen Friel \(ofriel\)  wrote:
> deb> Again architecture:  If the EST Server sits in front of a large
> deb> organization, then domain validation is more interesting, and the
> deb> Get /csrattrs may or may not be able to recommend a SAN, right?  I
> deb> can see that policy oids could be provided, if that is a thing in
> deb> these systems.  [we use policy oids in US DOD, but that is
> possibly
> deb> uncommon elsewhere.]
>
> ofriel> That is also a fair point, for complex deployments its not
> clear
> ofriel> what policy the EST server may want to apply before assigning a
> ofriel> SAN. The text in section 3 currently states:
>
> “EST servers could use this mechanism to tell the client  what fields
> to
> include in the CSR Subject and Subject Alternative  Name fields”
>
> ofriel> We could beef up that statement and explicitly state that the
> ofriel> policy by which the EST determines the SAN to specify is
> ofriel> explicitly out of scope. And also note that policy OIDs could
> be
> ofriel> provided.
>
> I would love to hear from operators and designers of CAs about how a
> RA can communicate to the CA about things it doesn't like, or wishes to
> add,
> to a certificate request.
>
> The CSR is immutable, being signed by the EE requesting.
> ACME doesn't provide any out-of-CSR mechanism, nor does CMC or CMP (correc

Re: [Acme] comments on: draft-ietf-acme-integrations-03.txt

[Deb Cooley]

Michael,

In my world (government PKI systems), the RA doesn't get to do that.
Either the CSR is accepted or it is rejected.  The CA has a profile it
follows, if the CSR is missing things, the CA adds them before the
certificate is signed.  The RA can do none of that.  In our case, most RAs
are actually people, so there can be a back channel to the requestor which
can be used to sort it all out.

How this all happens in the case of 'little things', I don't know.  We do
have a 'portal' for devices, but it would probably be quite 'heavy' for
your use cases.




On Tue, Jun 8, 2021 at 4:15 PM Michael Richardson 
wrote:

>
> Owen Friel \(ofriel\)  wrote:
> deb> Again architecture:  If the EST Server sits in front of a large
> deb> organization, then domain validation is more interesting, and the
> deb> Get /csrattrs may or may not be able to recommend a SAN, right?  I
> deb> can see that policy oids could be provided, if that is a thing in
> deb> these systems.  [we use policy oids in US DOD, but that is
> possibly
> deb> uncommon elsewhere.]
>
> ofriel> That is also a fair point, for complex deployments its not
> clear
> ofriel> what policy the EST server may want to apply before assigning a
> ofriel> SAN. The text in section 3 currently states:
>
> “EST servers could use this mechanism to tell the client  what fields
> to
> include in the CSR Subject and Subject Alternative  Name fields”
>
> ofriel> We could beef up that statement and explicitly state that the
> ofriel> policy by which the EST determines the SAN to specify is
> ofriel> explicitly out of scope. And also note that policy OIDs could
> be
> ofriel> provided.
>
> I would love to hear from operators and designers of CAs about how a
> RA can communicate to the CA about things it doesn't like, or wishes to
> add,
> to a certificate request.
>
> The CSR is immutable, being signed by the EE requesting.
> ACME doesn't provide any out-of-CSR mechanism, nor does CMC or CMP (correct
> me if I'm wrong here!)...  Max and I talked a lot about this when design
> RFC8995,
> and we had to conclude that it was simply non-standard.
>
> In the case of ACP (RFC8994) use of BRSKI, like the Ford Model-T, the CSR
> may
> contain anything the Pledge wants to put in, it will get an otherName
> containing the encoded ACP IPv6 ULA.
>
> In implementing, I also realized that the GET /csrattrs is
> pseudo-idempotent.
> When first called, it needs to allocate an IPv6 ULA for that node, and it
> needs to store it, such that whenever the same IDevID does the GET, it gets
> the same answer.  It's uncomfortable having to change database state on a
> GET, but at least the result is cachable!
>
> In the ACME integrations, we haven't said how the RA will decide what
> dNSName
> SAN will be returned, but the same property will apply.  The RA needs to
> collect a CSR that it can pass along up ACME, and for which is can do
> dns-01
> challenges.
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] comments on: draft-ietf-acme-integrations-03.txt

[Deb Cooley]

I've just picked the parts that I want to respond to, hopefully this isn't
confusing:

snip...

Section 3, 4 and 5 call flow:  both cases show the ACME CA returning a PEM,
while the EST RA returns a PKCS#7 to the device.  Is this intentional?  Are
you expecting the EST Server to convert the certificate from PEM to PKCS 7,
and is the PKCS7 a .p7b or .p7c.  [note:  these are trivial conversions,
but they are also very confusing to most people]

[ofriel] That’s a fair point. We could reference
https://datatracker.ietf.org/doc/html/rfc8555#section-7.4.2 and state that
EST server may request ACME certs using "application/pkcs7-mime" and that
would avoid a transcoding operation when the EST downloads the cert from
ACME.

snip..

Deb:  you can't just use PEM everywhere?RFC8555 pretty much says that
PEM is the default anyway?


snip...

Again architecture:  If the EST Server sits in front of a large
organization, then domain validation is more interesting, and the Get
/csrattrs may or may not be able to recommend a SAN, right?  I can see that
policy oids could be provided, if that is a thing in these systems.  [we
use policy oids in US DOD, but that is possibly uncommon elsewhere.]

[ofriel] That is also a fair point, for complex deployments its not clear
what policy the EST server may want to apply before assigning a SAN. The
text in section 3 currently states:

“EST servers could use this mechanism to tell the client  what fields to
include in the CSR Subject and Subject Alternative  Name fields”

We could beef up that statement and explicitly state that the policy by
which the EST determines the SAN to specify is explicitly out of scope. And
also note that policy OIDs could be provided.

snip.

Deb:  don't go too crazy here.  You are pretty soft on the language 'could
use' isn't exactly requiring it, but merely allowing it.


Deb Cooley, NSA




On Tue, Jun 8, 2021 at 12:06 PM Owen Friel (ofriel) 
wrote:

> Yes Deb, it did get lost in the shuffle.
>
>
>
> See inline.
>
>
>
>
>
> *From:* Acme  *On Behalf Of *Deb Cooley
> *Sent:* 19 March 2021 18:46
> *To:* acme@ietf.org
> *Cc:* Cooley, Dorothy E 
> *Subject:* [Acme] comments on: draft-ietf-acme-integrations-03.txt
>
>
>
> I thought this draft was pretty easy to follow, and I just have a few
> minor comments.  Note:  I am probably reviewing this from the point of view
> of an integrator (maybe?) definitely not as a device developer, and not as
> a CA developer.
>
> Section 1, sentence after bullets and Section 4, paragraph 1:  Section 1
> used “enrolment” while Section 4 used “enrollment”.  Pick one.  Use it
> everywhere.
>
> [ofriel] Sure, will fixup.
>
> Section 3, 4 and 5 call flow:  both cases show the ACME CA returning a
> PEM, while the EST RA returns a PKCS#7 to the device.  Is this
> intentional?  Are you expecting the EST Server to convert the certificate
> from PEM to PKCS 7, and is the PKCS7 a .p7b or .p7c.  [note:  these are
> trivial conversions, but they are also very confusing to most people]
>
> [ofriel] That’s a fair point. We could reference
> https://datatracker.ietf.org/doc/html/rfc8555#section-7.4.2 and state
> that EST server may request ACME certs using "application/pkcs7-mime" and
> that would avoid a transcoding operation when the EST downloads the cert
> from ACME.
>
> From an architecture point of view, do you expect the EST Server to be run
> by the requesting organization?  Or by the CA owner – or is this not even
> possible?  [from a ‘domain control’ point of view]
>
> [ofriel] We think this should be run by the organization that owns the
> domain, and then the EST RA can request certs from the ACME CA which could
> be run by a different org.
>
> Again architecture:  If the EST Server sits in front of a large
> organization, then domain validation is more interesting, and the Get
> /csrattrs may or may not be able to recommend a SAN, right?  I can see that
> policy oids could be provided, if that is a thing in these systems.  [we
> use policy oids in US DOD, but that is possibly uncommon elsewhere.]
>
> [ofriel] That is also a fair point, for complex deployments its not clear
> what policy the EST server may want to apply before assigning a SAN. The
> text in section 3 currently states:
>
> “EST servers could use this mechanism to tell the client  what fields to
> include in the CSR Subject and Subject Alternative  Name fields”
>
> We could beef up that statement and explicitly state that the policy by
> which the EST determines the SAN to specify is explicitly out of scope. And
> also note that policy OIDs could be provided.
>
>
>
> Section 8.1, para 3:  What does ‘The cache should be keyed by the complete
> contents of the CSR’ mean?  The word ‘ke

Re: [Acme] comments on: draft-ietf-acme-integrations-03.txt

[Deb Cooley]

Did anyone see this?  Or did it get lost in the shuffle?

Deb Cooley

On Fri, Mar 19, 2021 at 6:46 AM Deb Cooley  wrote:

> I thought this draft was pretty easy to follow, and I just have a few
> minor comments.  Note:  I am probably reviewing this from the point of
> view of an integrator (maybe?) definitely not as a device developer, and
> not as a CA developer.
>
> Section 1, sentence after bullets and Section 4, paragraph 1:  Section 1
> used “enrolment” while Section 4 used “enrollment”.  Pick one.  Use it
> everywhere.
>
> Section 3, 4 and 5 call flow:  both cases show the ACME CA returning a
> PEM, while the EST RA returns a PKCS#7 to the device.  Is this
> intentional?  Are you expecting the EST Server to convert the certificate
> from PEM to PKCS 7, and is the PKCS7 a .p7b or .p7c.  [note:  these are
> trivial conversions, but they are also very confusing to most people]
>
> From an architecture point of view, do you expect the EST Server to be run
> by the requesting organization?  Or by the CA owner – or is this not even
> possible?  [from a ‘domain control’ point of view]
>
> Again architecture:  If the EST Server sits in front of a large
> organization, then domain validation is more interesting, and the Get
> /csrattrs may or may not be able to recommend a SAN, right?  I can see
> that policy oids could be provided, if that is a thing in these systems.  [we
> use policy oids in US DOD, but that is possibly uncommon elsewhere.]
>
> Section 8.1, para 3:  What does ‘The cache should be keyed by the
> complete contents of the CSR’ mean?  The word ‘keyed’, I think, is the
> problem.  Maybe ‘indexed’?  Unless the cache is encrypted?
>
>
> Deb Cooley, NSA
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme