Re: [yang-doctors] [Anima] Yangdoctors early review of draft-ietf-anima-brski-async-enroll-03

[Reshad Rahman <[e-mail]>]

 Hi Steffen,

    On Wednesday, August 18, 2021, 04:44:01 AM EDT, Fries, Steffen <[e-mail]> wrote:  
 
 Hi Reshad,

Thank you for the review. I will address the points in the next update of the draft. 
I took over the proposed changes you made and will provide the tree diagram and the enhancement to the security considerations as suggested. In the ANIMA design team we will discuss the recommendations for RFC 8366bis 
I have some remarks to the other comments:

> See below for the modified YANG module which
> is valid, please check whether it is correct. Changes consist of removing extra ";
> in author list, adding a revision date and replacing augment "voucher-request"
> by augment voucher. 
I'm not sure about the last statement, as we would like to enhance the existing voucher-request definition from RFC 8995 in BRSKI-AE. Does this comment means we cannot augment the voucher-request as it already augments the voucher and therefore have to use the voucher  and only describe the leafs added?
<RR> The document currently has the following       uses ivr:voucher-request-grouping {
         augment "voucher-request" {
There is no node "voucher-request" in voucher-request-grouping in RFC8995 (unless I missed it). So I assumed it's the "voucher" node which is intended to be augmented. Disclaimer: I don't fully understand the intent here.
If it is the voucher-request-artifact  from RFC8995 which is to be augmented, I believe that can't be done because yang-data doesn't allow for augments.     // Top-level statement
     rc:yang-data voucher-request-artifact {
       uses voucher-request-grouping;
     }
> Other comments:
> - rc:yang-data (RFC8040) is used. While this seems to be fine, if the voucher-
> request-async-artifact template needs to be extended in the future, my
> understanding is that it is not possible with yang-data. However, you could use
> "structure" and (eventually) "augment-structure" from RFC8791 for this. 
We will discuss this point. Currently there is no explicit need for enhancements.
<RR> My understanding is that people are being encouraged to use "structure" instead of "yang-data", but I'll fer this to the AD (Rob).
>- Prefix
> "ivr" is used for ietf-voucher-request although RFC8995 has "vcr". While this is
> valid, I am curious why. 
Changed to match the definition in RFC 8995. Also changed for the "uses" statement in the grouping.
<RR> Ack.
Regards,Reshad.
Best regards
Steffen



- Please take a look at
> Error during processing.
> ker.ietf.org%2Fdoc%2Fhtml%2Frfc8407%23appendix-
> B&amp;data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=oyAUYIKQZSQxxURiRc
> j0RTlM6kiupsa6PqRs0hb86jg%3D&amp;reserved=0 for a module remplate.
> e.g. data definition statements usualy go after grouping definitions.
> 
> Valid YANG module:
> 
>    module ietf-async-voucher-request {
>      yang-version 1.1;
> 
>      namespace
>        "urn:ietf:params:xml:ns:yang:ietf-async-voucher-request";
>      prefix "constrained";
> 
>      import ietf-restconf {
>        prefix rc;
>        description
>          "This import statement is only present to access
>          the yang-data extension defined in RFC 8040.";
>        reference "RFC 8040: RESTCONF Protocol";
>      }
> 
>      import ietf-voucher-request {
>        prefix ivr;
>        description
>          "This module defines the format for a voucher request,
>              which is produced by a pledge as part of the RFC8995
>              onboarding process.";
>        reference
>          "RFC 8995: Bootstrapping Remote Secure Key Infrastructure";
>      }
> 
>      organization
>      "IETF ANIMA Working Group";
> 
>      contact
>      "WG Web:
> <Error during processing.
> .org%2Fwg%2Fanima%2F&amp;data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=7BDzJ4MjL%2BaCAAh
> v4A2PZLl2pB0b7WoNM19qAEGVICU%3D&amp;reserved=0>
>        WG List:  <mailto:[e-mail]>
>        Author:  Steffen Fries
>                  <mailto:[e-mail]>
>        Author:  Hendrik Brockhaus
>                  <mailto: [e-mail]>
>        Author:  Eliot Lear
>                  <mailto: [e-mail]>
>        Author:  Thomas Werner
>                  <mailto: [e-mail]>"t;";
>      description
>      "This module defines an extension of the RFC8995 voucher
>        request to permit a registrar-agent to convey the adjacency
>        relationship from the registrar-agent to the registrar.
> 
>        The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
>        'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
>        and 'OPTIONAL' in the module text are to be interpreted as
>        described in RFC 2119.";
>      revision 2021-08-13 {
>        description
>        "Initial version";
>        reference
>        "RFC XXXX: Voucher Request for Asynchronous Enrollment";
>      }
>      rc:yang-data voucher-request-async-artifact {
>        // YANG data template for a voucher.
>        uses voucher-request-async-grouping;
>      }
>      // Grouping defined for future usage
>      grouping voucher-request-async-grouping {
>        description
>          "Grouping to allow reuse/extensions in future work.";
>        uses ivr:voucher-request-grouping {
> 
>          augment voucher {
>            description "Base the constrained voucher-request upon the
>              regular one";
>            leaf agent-signed-data {
>              type binary;
>              description
>                "The agent-signed-data field contains a JOSE [RFC7515]
>                object provided by the Registrar-Agent to the Pledge.
> 
>                This artifact is signed by the Registrar-Agent
>                and contains a copy of the pledge's serial-number.";
>            }
> 
>            leaf agent-provided-proximity-registrar-cert {
>              type binary;
>              description
>                "An X.509 v3 certificate structure, as specified by
>                RFC 5280, Section 4, encoded using the ASN.1
>                distinguished encoding rules (DER), as specified
>                in ITU X.690.
>                The first certificate in the registrar TLS server
>                certificate_list sequence (the end-entity TLS
>                certificate; see RFC 8446) presented by the
>                registrar to the registrar-agent and provided to
>                the pledge.
>                This MUST be populated in a pledge's voucher-request
>                when an agent-proximity assertion is requested.";
>              reference
>                "ITU X.690: Information Technology - ASN.1 encoding
>                rules: Specification of Basic Encoding Rules (BER),
>                Canonical Encoding Rules (CER) and Distinguished
>                Encoding Rules (DER)
>                RFC 5280: Internet X.509 Public Key Infrastructure
>                Certificate and Certificate Revocation List (CRL)
>                Profile
>                RFC 8446: The Transport Layer Security (TLS)
>                Protocol Version 1.3";
>            }
> 
>            leaf agent-sign-cert {
>              type binary;
>              description
>                "An X.509 v3 certificate structure, as specified by
>                RFC 5280, Section 4, encoded using the ASN.1
>                distinguished encoding rules (DER), as specified
>                in ITU X.690.
>                This certificate can be used by the pledge,
>                the registrar, and the MASA to verify the signature
>                of agent-signed-data. It is an optional component
>                for the pledge-voucher request.
>                This MUST be populated in a registrar's
>                voucher-request when an agent-proximity assertion
>                is requested.";
>              reference
>                "ITU X.690: Information Technology - ASN.1 encoding
>                rules: Specification of Basic Encoding Rules (BER),
>                Canonical Encoding Rules (CER) and Distinguished
>                Encoding Rules (DER)
>                RFC 5280: Internet X.509 Public Key Infrastructure
>                Certificate and Certificate Revocation List (CRL)
>                Profile";
>            }
>          }
>        }
>      }
>    }
> 
> 
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> Error during processing.
> .org%2Fmailman%2Flistinfo%2Fanima&amp;data=04%7C01%7Ccef9763c-149c-
> 4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C7e6d34307a3642d99cd208d9600095
> 14%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637646377883265
> 554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=BBO%2FhGYnqAUtGF
> 3Jc5KBxe53v3jF%2BpyWdukQSAmp9x8%3D&amp;reserved=0


| 
| 
| 
|  |  |

 |

 |
| 
|  | 
Error during processing.


 |

 |

 |

       uses ivr:voucher-request-grouping {

Fries, et al.           Expires December 26, 2021              [Page 49]
Internet-Draft                  BRSKI-AE                       June 2021

         augment "voucher-request" {



| 
| 
| 
|  |  |

 |

 |
| 
|  | 
Error during processing.


 |

 |

 |





| 
| 
| 
|  |  |

 |

 |
| 
|  | 
Error during processing.


 |

 |

 |