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

[Sean Turner <[e-mail]>]

Brian - that’s totally fine by me.

spt

> On Sep 7, 2022, at 19:43, Brian Sipos <[e-mail]> wrote:
> 
> Sean,
> Thank you for this review!
> I'm preparing changes based on this feedback. For your #2 and #4 my preference is to cite the IANA registry as the authority with RFC 9174 as the secondary only because I want to treat RFC 9174 as an informative reference. It certainly informs the use case of this validation method but they shouldn't be seen as directly coupled; only through the PKIX OIDs on which they both depend.
> 
> On Wed, Sep 7, 2022 at 1:43 PM Sean Turner <[e-mail]> wrote:
> Hi! Some comments:
> 
> tl;dr: Let the experiment begin!
> 
> # General
> 
> I thought this document is well written and easy to follow. 
> 
> # Nits
> 
> 1) s1: s/certificate authorities/Certification Authorities (CAs)
> 
> 2) s2: I think maybe you can drop the IANA-SMI reference here:
> 
> … identified by id-on-bundleEID of [IANA-SMI], consistent
>    with the requirements of Section 4.4.2.1 of [RFC9174].
> 
> RFC 9174 includes the OID and the semantics so unless you’re changing that I think this text could be:
> 
> … identified by id-on-bundleEID, consistent
>    with the requirements of Section 4.4.2.1 of [RFC9174].
> 
> 3) s3.3: r/[draft-ietf-cose-hash-algs]/[RFC9054]
> 
> 4) s5: A better reference for id-kp-bundleSecurity would be [RFC9174], at least I think it is because that’s where id-kp-bundleSecurity is defined.
> 
> 5) s5.2: I think the last para needs a little tweaking. Just because a client asks for signature only certificate for a DH key shouldn’t mean they get it ;) Maybe something like, “Obviously, the request for signature-only and encryption-only certificates is algorithm dependent” or something like that.
> 
> 6) Appendix A: I think you need to include text that states this Appendix is a normative part of the specification. Often Appendices are considered informative, but this one includes the definition of the CDDL.
> 
> Cheers,
> spt
> 
> > On Aug 18, 2022, at 06:13, Deb Cooley <[e-mail]> wrote:
> > 
> > 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 <[e-mail]> 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. <[e-mail]> 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 <[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).  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/
> > 
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/acme
> > 
> > _______________________________________________
> > Acme mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/acme
> > 
> > _______________________________________________
> > Acme mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/acme
> 
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme