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: [email protected] <[email protected]>
> Sent: Monday, July 10, 2023 9:34 PM
> To: Michael C. Richardson <[email protected]>; Eliot Lear
> <[email protected]>; Michael Richardson <[email protected]>; Fries,
> Steffen (T CST) <[email protected]>; Werner, Thomas (T CST SEA-DE)
> <[email protected]>
> 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
> 

_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to