Re: [Anima] New Version Notification for draft-ietf-anima-brski-prm-09.txt

["Fries, Steffen" <[e-mail]>]

Hello,

We just submitted an update of BRSKI-PRM (now version 09)
Since the last IETF meeting we mainly addressed the comments from the WGLC and the chair review, as there are:

   *  issue #80, enhanced Section 5.3.2 with clarification on the serial number and the inclusion of GRASP
   *  issue #81, enhanced introduction with motivation for agent_signed_data
   *  issue #82, included optional TLS protection of the communication link between registrar-agent and pledge in the introduction, Section 4, and Section 6.1
   *  issue #83, enhanced Section 6.1.4 and Section 6.2.6 with note to re-enrollment
   *  issue #87, clarified available information at the registrar-agent in Section 6.1
   *  issue #88, clarified, that the PVR in Section 6.1.2 and PER in Section 6.1.4 may contain the certificate chain.  If not contained it MUST be available at the registrar.
   *  issue #91, clarified that a separate HTTP connection may also be used to provide the PER in Section 6.2.6
   *  resolved remaining editorial issues discovered after WGLC (responded to on the mailing list in Reply 1 and Reply 2) resulting in more consistent descriptions
   *  issue #92: kept separate endpoint for wrapped CSR on registrar Section 6.2.7
   *  issue #94: clarified terminology (possess vs. obtained)
   *  issue #95: clarified optional IDevID CA certificates on registrar- agent Section 6.3
   *  issue #96: updated Figure 14 to correct to just one CA certificate provisioning
   *  issue #97: deleted format explanation in Section 6.3 as it may be misleading
   *  issue #99: motivated verification of second signature on voucher in Section 6.3
   *  issue #100: included negative example in Figure 15
   *  issue #101: included handling if Section 6.3.2 voucher telemetry information has not been received by the registrar-agent
   *  issue #102: relaxed requirements for CA certs provisioning in Section 6.3.3
   *  issue #105: included negative example in Figure 16
   *  issue #107: included example for certificate revocation in Section 6.3.6
   *  issue #108: renamed heading to Pledge-Status Request of Section 6.4.1
   *  issue #111: included pledge-status response processing for authenticated requests in Section 6.4.2
   *  issue #112: added "Example key word in pledge-status response in Figure 22
   *  issue #113: enhanced description of status reply for "factory-default" in Section 6.4.2
   *  issue #114: Consideration of optional TLS usage in Privacy Considerations
   *  issue #115: Consideration of optional TLS usage in Privacy Considerations to protect potentially privacy related information in the bootstrapping like status information, etc.
   *  issue #116: Enhanced DoS description and mitigation options in security consideration section

Most changes resulted in clarifications of terminology and approaches and additional error handling.
There are some open issues in the ANIMA git, which are discussed during the design team meetings. The solution of these issues is expected straight forward. There is one issue to be discussed for the BRSKI enhancements in general, which relates to the discovery of registrars with additional features. The intention is to come up for a solution, which is applicable to BRSKI-AE, BRSKI-PRM, constraint BRSKI.

Best regards
Steffen


> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Monday, July 10, 2023 9:34 PM
> To: Michael C. Richardson <[e-mail]>; Eliot Lear
> <[e-mail]>; Michael Richardson <[e-mail]>; Fries,
> Steffen (T CST) <[e-mail]>; Werner, Thomas (T CST SEA-DE)
> <[e-mail]>
> Subject: New Version Notification for draft-ietf-anima-brski-prm-09.txt
> 
> 
> A new version of I-D, draft-ietf-anima-brski-prm-09.txt has been successfully
> submitted by Steffen Fries and posted to the IETF repository.
> 
> Name:		draft-ietf-anima-brski-prm
> Revision:	09
> Title:		BRSKI with Pledge in Responder Mode (BRSKI-PRM)
> Document date:	2023-07-10
> Group:		anima
> Pages:		91
> URL:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Farchive%2Fid%2Fdraft-ietf-anima-brski-prm-
> 09.txt&data=05%7C01%7Csteffen.fries%40siemens.com%7Cdf72d4003fab4
> 2993ac008db817c8e09%7C38ae3bcd95794fd4addab42e1495d55a%7C1%
> 7C0%7C638246144182588719%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> 0%7C%7C%7C&sdata=KnV6w2R9H22iRcIL53A822%2FowLa12mlNsbREGgv
> MyeU%3D&reserved=0
> Status:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat
> racker.ietf.org%2Fdoc%2Fdraft-ietf-anima-brski-
> prm%2F&data=05%7C01%7Csteffen.fries%40siemens.com%7Cdf72d4003fa
> b42993ac008db817c8e09%7C38ae3bcd95794fd4addab42e1495d55a%7C1
> %7C0%7C638246144182588719%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> 000%7C%7C%7C&sdata=2GdedDwvgEVmhwY994avpYCKI3sCz1YqR5X3PwN
> TSLo%3D&reserved=0
> Htmlized:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat
> racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-anima-brski-
> prm&data=05%7C01%7Csteffen.fries%40siemens.com%7Cdf72d4003fab429
> 93ac008db817c8e09%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C
> 0%7C638246144182588719%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> 7C%7C%7C&sdata=8ZFSU%2FGnubEe5W7FRwhHJKrDqvthZ8vFtwTKMF25PT
> E%3D&reserved=0
> Diff:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fautho
> r-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-anima-brski-prm-
> 09&data=05%7C01%7Csteffen.fries%40siemens.com%7Cdf72d4003fab4299
> 3ac008db817c8e09%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0
> %7C638246144182588719%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> 7C%7C%7C&sdata=MOapl34wQtbcDeb9bcZEWK0y4Rp%2BIpHmlBvX8Xy4i%
> 2Bk%3D&reserved=0
> 
> Abstract:
>    This document defines enhancements to Bootstrapping a Remote Secure
>    Key Infrastructure (BRSKI, RFC8995) to enable bootstrapping in
>    domains featuring no or only limited connectivity between a pledge
>    and the domain registrar.  It specifically changes the interaction
>    model from a pledge-initiated mode, as used in BRSKI, to a pledge-
>    responding mode, where the pledge is in server role.  For this, BRSKI
>    with Pledge in Responder Mode (BRSKI-PRM) introduces a new component,
>    the registrar-agent, which facilitates the communication between
>    pledge and registrar during the bootstrapping phase.  To establish
>    the trust relation between pledge and registrar, BRSKI-PRM relies on
>    object security rather than transport security.  The approach defined
>    here is agnostic to the enrollment protocol that connects the domain
>    registrar to the domain CA.
> 
> 
> 
> 
> The IETF Secretariat
>