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

[Robert Lee <[e-mail]>]

Hi all,

 

So, I’ve read the draft a couple of times recently and am happy to review.  Generally I think the technical content is sound and effectively does what it says it’s trying to do.  I also think it’s clearly explained and easy to follow.

 

I do have two comments that I’d like to make (apologies if I’m a little late to the party on some of this).

 

Firstly, I’m not sure I buy the argument in the intro about changing certificate lifetimes and renewing at issuedcert.not_after – x.  From my experience the most recent couple of changes to certificate lifetimes made via root store policy changes have only affected certs issued after a date in the future and not certs that have already been issued.  If a subscriber gets a new cert a week before their current one expires then that approach would continue to work even if the lifetime of new certs was changed.  I’ll admit though that it’s less resistant to changes of certificate lifetimes than renewing x% through the lifetime of the current cert.

 

That being said, I wonder if a second justification for ARI might be scheduled revocation (which is a change of the certificate lifetime but would cause problems for all three of the use cases in the intro so I assume it was validity periods mentioned there).  The new Mozilla Root Store Policy changes included a requirement for cascading revocation (even between subscribers) in one of the keyCompromise use cases.  I wonder if ARI might be useful in the situation where customer a has revoked for keyCompromise with proof-of-possession and then customer b using the same key can be notified that they need a new certificate within the next 24 hours.  Happy to try and write something if it would help.

 

Secondly, I think the key words around client action and the suggested renewal window are a bit inconsistent.  If the renewal window is in the future then one MUST uniformly pick a random time in the window to renew but if you’ve already missed it then the guidance is you SHOULD attempt to renew immediately.  Then if the window is before you’d poll ARI again then you MAY attempt to renew immediately.

 

I don’t mind the latter two as much but I wonder if the “MUST” is a little strong and if it would be better to downgrade it to a “SHOULD” or to “It is RECOMMENDED that conforming clients select a uniform random…”.  In this I’m mainly considering the case where checking ARI is integrated into a notification system that tells a person to renew the cert using their ACME client rather than when the entire thing is automated.  Again, can open a PR for this if there is agreement.

 

Best Regards,

Rob

 

Dr. Robert Lee MEng PhD

Senior Software Engineer

http://www.globalsign.co.uk/" rel="nofollow">www.globalsign.co.uk|http://www.globalsign.eu/" rel="nofollow">www.globalsign.eu

 

 

From: Acme <[e-mail]> on behalf of Sipos, Brian J. <[e-mail]>
Date: Tuesday, 24 May 2022 at 22:29
To: Deb Cooley <[e-mail]>, IETF ACME <[e-mail]>, Brian Sipos <[e-mail]>
Cc: Roman Danyliw <[e-mail]>, Dorothy E Cooley <[e-mail]>
Subject: Re: [Acme] [EXT] Re: I-D Action: draft-ietf-acme-dtnnodeid-09.txt

You don't often get email from [e-mail]. https://aka.ms/LearnAboutSenderIdentification" rel="nofollow">Learn why this is important

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 <[e-mail]> On Behalf Of Deb Cooley
Sent: Tuesday, May 24, 2022 7:39 AM
To: IETF ACME <[e-mail]>; Brian Sipos <[e-mail]>
Cc: Roman Danyliw <[e-mail]>; Dorothy E Cooley <[e-mail]>
Subject: [EXT] Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-09.txt

 

APL external email warning: Verify sender [e-mail] 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 <[e-mail]> 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 <[e-mail]> 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" rel="nofollow">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 <[e-mail]> On Behalf Of Brian Sipos
Sent: Wednesday, March 2, 2022 11:27 PM
To: IETF ACME <[e-mail]>
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 <[e-mail]> 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/" rel="nofollow">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" rel="nofollow">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" rel="nofollow">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
[e-mail]
https://www.ietf.org/mailman/listinfo/acme" rel="nofollow">https://www.ietf.org/mailman/listinfo/acme

_______________________________________________
Acme mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/acme" rel="nofollow">https://www.ietf.org/mailman/listinfo/acme