Ok. Thanks. I have sent the document for Expert Review. Cheers. > On Apr 7, 2026, at 2:05 PM, Esko Dijk <[email protected]> wrote: > > Hi Mahesh, Michael, > > My original comments were both addressed; first was removal of the 4492bis > reference. > > The second was removal of mandatory or recommended (normative) crypto > details/algorithms in this item. The latest text doesn't have such > requirements. It only mentions some details to motivate some size-related > considerations for RSA and ECDSA - which is ok since it doesn't require any > of these to be used. It leaves it up to the protocol using 'voucher' to > select the crypto algorithms; and whether to use pinned pubk, pubk-sha256, or > pinned-domain-cert, or something entirely new using the extensions. > > Esko > > > > On 4/7/26 22:02, Mahesh Jethanandani wrote: >> Hi Michael, >> >> In reviewing the changes made in -29, I believe you have addressed the first >> comment from Esko, but I do not see a resolution for his second comment. >> >> Thanks. >> >>> On Mar 16, 2026, at 1:19 AM, Esko Dijk <[email protected]> >>> <mailto:[email protected]> wrote: >>> >>> Hi Michael, >>> >>> Thanks for the updates. It looks like one instance of the reference to >>> 'draft-ietf-tls-rfc4492bis-17' as shown in the text below still is present >>> in the rev -28, where the related text should be removed also. >>> >>> I also think the voucher request format is generic and could store any >>> public key type! It's up to the specific protocol like BRSKI, cBRSKI or >>> others, or profiles of these protocols, to define what ciphersuites are to >>> be supported in the (D)TLS connections. So the crypto details should be >>> removed also here and left to the specific protocol using vouchers/VRs. >>> >>> >>> >>> leaf proximity-registrar-pubk { >>> type binary; >>> description >>> "The proximity-registrar-pubk replaces >>> the proximity-registrar-cert in constrained uses of >>> the voucher-request. >>> The proximity-registrar-pubk is the >>> Raw Public Key of the Registrar. This field is encoded >>> as specified in RFC7250, section 3. >>> The ECDSA algorithm MUST be supported. >>> The EdDSA algorithm as specified in >>> draft-ietf-tls-rfc4492bis-17 SHOULD be supported. >>> Support for the DSA algorithm is not recommended. >>> Support for the RSA algorithm is a MAY, but due to >>> size is discouraged."; >>> regards >>> >>> Esko >>> >>> >>> >>> On 3/16/26 01:11, Michael Richardson wrote: >>>> [email protected] <mailto:[email protected]> wrote: >>>> > Internet-Draft draft-ietf-anima-rfc8366bis-28.txt is now available. >>>> It is a >>>> > work item of the Autonomic Networking Integrated Model and Approach >>>> (ANIMA) WG >>>> > of the IETF. >>>> >>>> > Title: A Voucher Artifact for Bootstrapping Protocols >>>> > Name: draft-ietf-anima-rfc8366bis-28.txt >>>> >>>> > A diff from the previous version is available at: >>>> > >>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-rfc8366bis-28 >>>> >>>> This version deals with the AD review comments from Mahesh. >>>> They are all complete, and I don't think there was anything particularly >>>> controversial that the WG needed to be consulted on. Of course, read the >>>> diff and disagree. (Or send text) >>>> >>>> If you want to see how I dealt with each comment, then one could start at: >>>> https://github.com/anima-wg/voucher/issues/116 >>>> >>>> Each sub-issue deals with a type of comment, such as: >>>> >>>> https://github.com/anima-wg/voucher/issues/116?issue=anima-wg%7Cvoucher%7C119 >>>> >>>> Where you can see a comment like: >>>> mcr added a commit that references this issue 3 days ago >>>> remove redundant word -grouping from names of groupings. close #119 >>>> >>>> with a link to, e.g., >>>> https://github.com/anima-wg/voucher/commit/ac84b245a12107a7271a984926075e3100444ac6 >>>> >>>> In the process of dealing with references from the YANG modules that did >>>> not >>>> lead anywhere, I wound up removing some BCP14 language about supported >>>> algorithms. See https://github.com/anima-wg/voucher/issues/125 >>>> and also https://github.com/anima-wg/constrained-voucher/issues/346 >>>> >>>> This is not just about for (D)TLS itself, but in effect also supported >>>> algorithms for the IDevID and registrar server certificate. >>>> >>>> -- >>>> Michael Richardson <[email protected]> <mailto:[email protected]> >>>> . o O ( IPv6 IøT consulting ) >>>> Sandelman Software Works Inc, Ottawa and Worldwide >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Anima mailing list -- [email protected] <mailto:[email protected]> >>>> To unsubscribe send an email to [email protected] >>>> <mailto:[email protected]> >> >> >> Mahesh Jethanandani >> [email protected] <mailto:[email protected]> >> >> >> >> >> >>
Mahesh Jethanandani [email protected]
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
