Merge pull request #127 from anima-wg/low-hanging-adfruit

Low hanging adfruit

Author: mcr

draft-ietf-anima-rfc8366bis.md

@@ -3,7 +3,7 @@ docname: draft-ietf-anima-rfc8366bis-latest
 stand_alone: true
 ipr: trust200902
 cat: std
-updates: 8366, 8995
+updates: 8995
 obsoletes: 8366
 consensus: 'yes'
 pi:
@@ -83,7 +83,7 @@ normative:
     seriesinfo:
       ITU-T Recommendation X.690,: ISO/IEC 8825-1
   ZERO-TOUCH: RFC8572
-  BRSKI: RFC8995
+  RFC8995:
   PRM: I-D.ietf-anima-brski-prm
   CLOUD: I-D.ietf-anima-brski-cloud
   IDEVID:
@@ -146,8 +146,8 @@ The Voucher Artifact is normally generated by
 the Pledge's manufacturer (i.e., the Manufacturer Authorized Signing
 Authority (MASA)).
 
-This document updates RFC8366: it includes a number of desired extensions into the YANG module.
-The Voucher Request YANG module defined in RFC8995 is also updated and now included in this document, as well as other YANG extensions needed for variants of BRSKI/RFC8995.
+This document obsoletes RFC8366: it includes a number of desired extensions into the YANG module.
+The Voucher Request YANG module defined in RFC8995 is also updated and now included in this document, as well as other YANG extensions needed for variants of RFC8995.
 
 --- middle
 
@@ -177,8 +177,8 @@ The collection of all these actors is collectively known as the Domain.
 A Voucher may be useful in several contexts, but the driving motivation herein is to support secure Onboarding mechanisms.
 This is accomplished by assigning an Owner to the Pledge, enabling it to authenticate the network that it is connected to.
 
-{{RFC8366}} originally defined the Voucher as the only Voucher Artifact, leaving the Voucher Request that is used in BRSKI to be defined in {{BRSKI}}.
-This document includes both Voucher and Voucher Request, and therefore updates {{BRSKI}}.
+{{RFC8366}} originally defined the Voucher as the only Voucher Artifact, leaving the Voucher Request that is used in BRSKI to be defined in {{RFC8995}}.
+This document includes both Voucher and Voucher Request obsoleting {{RFC8366}}, and updating {{RFC8995}}.
 
 YANG is not easily extended except by updating the YANG module definition.
 Since {{RFC8366}} was written, the common pattern is to publish YANG modules as two documents: one with only the YANG module, and the other one with usage, motivation and further explanation.
@@ -194,7 +194,7 @@ indicated lifetime.
 In order to support long lifetimes, this document recommends using short lifetimes with programmatic renewal, see {{renewal-over-revocation}}.
 
 Some Onboarding protocols using the Voucher Artifact defined in
-this document include: {{ZERO-TOUCH}}, {{SECUREJOIN}}, {{BRSKI}} and {{cBRSKI}}.
+this document include: {{ZERO-TOUCH}}, {{SECUREJOIN}}, {{RFC8995}} and {{cBRSKI}}.
 
 # Terminology
 
@@ -211,8 +211,9 @@ Attribute:
 
 Bootstrapping:
 : The process where a Pledge obtains cryptographic key material to identify
-   and trust future interactions within a specific Domain network. Based on imprinted
-   key material provided during the manufacturing process (see: Imprint).
+   and trust future interactions within a specific Domain network.
+   Bootstrapping is based on imprinted key material provided during the
+   manufacturing process (see: Imprint).
    This term was used in {{RFC8366}}, but has been supplanted by the term Onboarding.
 
 Domain:
@@ -412,23 +413,23 @@ This document obsoletes {{RFC8366}}.
 
 ## Attempts and motivation to extend RFC8366 {#extendfail}
 
-{{RFC8366}} was published in 2018 during the development of {{BRSKI}},
+{{RFC8366}} was published in 2018 during the development of {{RFC8995}},
 {{ZERO-TOUCH}} and other work-in-progress efforts.
 Since then the industry has matured significantly, and the in-the-field activity which this document supports has become known as _Onboarding_ rather than _Bootstrapping_.
 
-The focus of {{BRSKI}} was Onboarding of ISP and Enterprise owned wired routing and switching equipment, with IoT devices being a less important aspect.
+The focus of {{RFC8995}} was Onboarding of ISP and Enterprise owned wired routing and switching equipment, with IoT devices being a less important aspect.
 {{ZERO-TOUCH}} has focused upon Onboarding of CPE equipment like cable modems and other larger IoT devices, again with smaller IoT devices being of lesser importance.
 
-Since {{BRSKI}} was published there is now a mature effort to do application-level Onboarding of constrained IoT devices defined by the Thread Group and the Fairhair Alliance (now OCF) {{fairhair}}.
-The {{cBRSKI}} document has defined a version of {{BRSKI}} that is usable over constrained IEEE 802.15.4 6LoWPAN networks using CoAP and DTLS, while {{?I-D.ietf-lake-authz}} provides for using CoAP and EDHOC on even more constrained devices with very constrained networks.
+Since {{RFC8995}} was published there is now a mature effort to do application-level Onboarding of constrained IoT devices defined by the Thread Group and the Fairhair Alliance (now OCF) {{fairhair}}.
+The {{cBRSKI}} document has defined a version of {{RFC8995}} that is usable over constrained IEEE 802.15.4 6LoWPAN networks using CoAP and DTLS, while {{?I-D.ietf-lake-authz}} provides for using CoAP and EDHOC on even more constrained devices with very constrained networks.
 
 {{PRM}} has created a new methodology for Onboarding that does not depend upon a synchronous connection between the Pledge and the Registrar.
 This mechanism uses a mobile Registrar agent that works to collect and transfer signed artifacts via physical travel from one network to another.
 
 Both {{cBRSKI}} and {{PRM}} require extensions to the Voucher Request and the resulting Voucher. The new Attributes are required to carry the additional data and describe the extended semantics.
 In addition {{cBRSKI}} uses the serialization mechanism described in {{RFC9254}} to produce significantly more compact artifacts.
 
-When the process to define {{cBRSKI}} and {{PRM}} was started, there was a belief that the appropriate process was to use the {{RFC7950}} _augment_ mechanism to further extend both the Voucher Request {{BRSKI}} and Voucher {{RFC8366}} artifacts.
+When the process to define {{cBRSKI}} and {{PRM}} was started, there was a belief that the appropriate process was to use the {{RFC7950}} _augment_ mechanism to further extend both the Voucher Request {{RFC8995}} and Voucher {{RFC8366}} artifacts.
 However, {{PRM}} needs to extend an enumerated type with additional values and _augment_ can not do this, so that was initially the impetus for this document.
 
 An attempt was then made to determine what would happen if one wanted to have a constrained version of the {{PRM}} Voucher Artifact.
@@ -440,12 +441,12 @@ After significant discussion the decision was made to simply roll all of the nee
 
 # Updates to RFC8995
 
-This document represents a merge of YANG definitions of the Voucher from {{RFC8366}}, the Voucher Request from {{BRSKI}}, and extensions to each of these from {{cBRSKI}}, {{CLOUD}} and {{PRM}}.
+This document represents a merge of YANG definitions of the Voucher from {{RFC8366}}, the Voucher Request from {{RFC8995}}, and extensions to each of these from {{cBRSKI}}, {{CLOUD}} and {{PRM}}.
 The difficulty with this approach is that the semantics of the definitions needed for the other documents are not included in this document, but rather in the respective other documents.
 
 ## Updates to the use of `idevid-issuer` {#updates-idevid-issuer}
 
-The `voucher-request` module definition that was in {{BRSKI}} Sections 3.2 (tree diagram) and 3.4 (YANG module) is now included in this document.
+The `voucher-request` module definition that was in {{RFC8995}} Sections 3.2 (tree diagram) and 3.4 (YANG module) is now included in this document.
 There is a change to it: the '`idevid-issuer`' Attribute MUST be included in a Registrar Voucher Request (RVR).
 Like the '`serial-number`' value in the RVR, the '`idevid-issuer`' value in the RVR is to be taken from the Pledge's (IDevID) client certificate.
 In some variations of BRSKI, such as {{PRM}}, there is no direct TLS connection between Pledge and Registrar.  Therefore the Pledge's IDevID certificate cannot be extracted from the TLS connection, so those variations define a different channel binding process and may deviate from the above requirement.
@@ -460,11 +461,11 @@ A Registrar MUST apply the following rules for the value of the '`idevid-issuer`
 
 ## Clarifications on the use of `idevid-issuer`
 
-{{RFC8366}} and {{BRSKI}} define the '`idevid-issuer`' attribute for the '`voucher`' and '`voucher-request`' modules (respectively), but they summarily explain when to use it, and why it is used.
+{{RFC8366}} and {{RFC8995}} define the '`idevid-issuer`' attribute for the '`voucher`' and '`voucher-request`' modules (respectively), but they summarily explain when to use it, and why it is used.
 
 The '`idevid-issuer`' Attribute is provided so that the serial number to which the issued Voucher pertains can be relative to the entity that issued the Pledge's IDevID.
 In most cases there is a one to one relationship between the trust anchor that signs Vouchers (and is trusted by the Pledge), and the Certification Authority that signs the IDevID.
-In that case, the '`serial-number`' in the Voucher Data must refer to the same device as the serial number that is in the IDevID certificate (in the '`serialNumber`' element of type '`X520SerialNumber`' per {{Section 2.3.1 of BRSKI}}).
+In that case, the '`serial-number`' in the Voucher Data must refer to the same device as the serial number that is in the IDevID certificate (in the '`serialNumber`' element of type '`X520SerialNumber`' per {{Section 2.3.1 of RFC8995}}).
 
 However, there are situations where the one to one relationship may be broken.
 This occurs whenever a manufacturer has a common MASA, but different products (on different assembly lines) are produced with identical serial numbers.
@@ -490,7 +491,7 @@ If this rule does not apply, the MASA SHOULD NOT include the '`idevid-issuer`' A
 
 ## Clarifications on the format of `idevid-issuer` {#idevid-issuer-format}
 
-{{RFC8366}} and {{BRSKI}} were not fully clear on the required binary format of the '`idevid-issuer`' Attribute.
+{{RFC8366}} and {{RFC8995}} were not fully clear on the required binary format of the '`idevid-issuer`' Attribute.
 This gave rise to incompatible implementations.
 
 This section clarifies the format of the '`idevid-issuer`' Attribute, which contains the full Authority Key Identifier from an IDevID certificate.
@@ -502,7 +503,7 @@ However, because of the above requirement to include the full '`extnValue`' OCTE
 
 ## Errata closed
 
-This above updates to {{BRSKI}} addresses errata {{eid7263}}.
+The above updates to {{RFC8995}} addresses errata {{eid7263}}.
 
 # Signature mechanisms
 
@@ -543,7 +544,7 @@ In the Voucher Request, the signer is the Pledge (in the PVR), or the Registrar
 Note that Section 5.1 of {{RFC5652}} includes a
 discussion about how to validate a CMS object, which is really a
 PKCS7 object (cmsVersion=1).  Intermediate systems (such as the
-Bootstrapping Remote Secure Key Infrastructures {{BRSKI}} Registrar)
+Bootstrapping Remote Secure Key Infrastructures {{RFC8995}} Registrar)
 that might need to evaluate the Voucher in flight MUST be prepared for
 such an older format.
 No signaling of the format version is necessary, as the manufacturer knows the capabilities
@@ -789,13 +790,13 @@ Note that {{RFC9254}} does not strictly require use of SIDs: instead of a SID va
 be used. But this would significantly increase the size of the Voucher Data.
 
 Instead, a manufacturer MAY use the '`manufacturer-private`' Attribute to put any content they wish.
-In CBOR serialization, if a plain CBOR map would be used, it would be subject to delta encoding: so use of this Attribute requires that the contents are bstr-encoded {{CBOR}} {{RFC8949, Section 3.1}} (Major type 2).
+In CBOR serialization, if a plain CBOR map would be used, it would be subject to delta encoding: so use of this Attribute requires that the contents are bstr-encoded (Major type 2).
 In JSON serialization, delta encoding does not get in the way, and the manufacturer MAY use any encoding that is convenient for them, but base64URL encoding {{?RFC4648, Section 5}} is RECOMMENDED.
 
 
 # Voucher Request Artifact {#voucher-request}
 
-{{BRSKI, Section 3}} defined a "voucher-request" Artifact as an augmented Artifact from the "voucher" Artifact originally defined in {{RFC8366}}.
+{{RFC8995, Section 3}} defined a "voucher-request" Artifact as an augmented Artifact from the "voucher" Artifact originally defined in {{RFC8366}}.
 That definition has been moved to this document, and translated from the "yang-data" extension {{RFC8040}} to the "sx:structure" extension {{RFC8791}}.
 
 ## Tree Diagram {#voucher-request-tree-diagram}
@@ -959,7 +960,8 @@ of {{RFC5652}}), though details for how to do this are outside
 the scope of this document.
 
 The use of YANG to define data structures, via the "sx:structure"
-extension {{RFC8791}}, is relatively new and distinct from the traditional use of
+extension {{RFC8791}}, is relatively new and distinct from the conventional
+use of
 YANG to define an API accessed by network management protocols such as
 NETCONF {{RFC6241}} and RESTCONF {{RFC8040}}. For this reason, this
 security considerations section does not follow the template described
@@ -972,7 +974,7 @@ by Section 3.7 of {{YANG-GUIDE}}.
 
 This document updates two URIs in the "IETF XML Registry" {{RFC3688}}.
 
-IANA has registered the following based on {{RFC8366}} and {{BRSKI}} respectively:
+IANA has registered the following based on {{RFC8366}} and {{RFC8995}} respectively:
 
 > {:compact}
 >    URI:
@@ -1019,7 +1021,7 @@ IANA has registered the following based on {{RFC8366}}:
 This reference should be updated to point to this document and the "File" entry should be updated to point to the
 new module revision in {{voucher-yang-module}}.
 
-IANA has registered the following based on {{BRSKI}}:
+IANA has registered the following based on {{RFC8995}}:
 
 > {:compact}
 >   name:
@@ -1177,6 +1179,11 @@ and also the following YANG module:
 * URI for the ".sid" file: a pointer to the file defined in {{voucher-request-sid-allocations}}
 * Number of SIDs: 24
 
+# YANG references
+
+RFC-editor, please remove.
+This section just lists references present in YANG modules which otherwise do not get included in the references, like {{!RFC7250}}.
+
 --- back
 
 # Examples
@@ -1308,3 +1315,5 @@ by last name):
 {{{Thomas Werner}}}.
 
 {{{Max Pritikin}}} and {{{Kent Watsen}}} were instrumental in creating the original {{RFC8366}}.
+
+

ietf-voucher-request.yang

@@ -7,6 +7,7 @@ module ietf-voucher-request {
 
   import ietf-yang-structure-ext {
     prefix sx;
+    reference "RFC 8791: YANG Data Structure Extensions";
   }
 
   import ietf-voucher {
@@ -31,8 +32,6 @@ module ietf-voucher-request {
                <mailto:kent+ietf@watsen.net>
      Author:   Michael Richardson
                <mailto:mcr+ietf@sandelman.ca>
-     Author:   Max Pritikin
-               <mailto:pritikin@cisco.com>
      Author:   Toerless Eckert
                <mailto:tte@cs.fau.de>
      Author:   Qiufang Ma
@@ -47,7 +46,7 @@ module ietf-voucher-request {
     during a voucher request procedure and subsequent
     Voucher creation.
 
-    Copyright (c) 2023 IETF Trust and the persons identified as
+    Copyright (c) 2023-2026 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.
 
     Redistribution and use in source and binary forms, with or
@@ -85,11 +84,11 @@ module ietf-voucher-request {
        (BRSKI)";
   }
 
-  grouping voucher-request-grouping {
+  grouping voucher-request {
     description
       "Grouping to allow reuse/extensions in future work.";
 
-    uses vch:voucher-artifact-grouping {
+    uses vch:voucher-artifact {
       refine "last-renewal-date" {
         description "A last-renewal-date field
                      is not valid in a voucher request, and
@@ -144,7 +143,7 @@ module ietf-voucher-request {
        "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.X690.1994].
+        in [ITU.X690.2015].
 
         The first certificate in the Registrar TLS server
         certificate_list sequence  (the end-entity TLS
@@ -259,7 +258,7 @@ module ietf-voucher-request {
 
   // Top-level statement: called "voucher" to match RFC8995
   sx:structure voucher {
-    uses voucher-request-grouping;
+    uses voucher-request;
   }
 
 }

ietf-voucher.yang

@@ -5,16 +5,17 @@ module ietf-voucher {
 
   import ietf-yang-types {
     prefix yang;
-    reference "RFC 6991: Common YANG Data Types";
+    reference "RFC 9911: Common YANG Data Types";
   }
 
   import ietf-inet-types {
     prefix ietf;
-    reference "RFC 6991: Common YANG Data Types";
+    reference "RFC 9911: Common YANG Data Types";
   }
 
   import ietf-yang-structure-ext {
     prefix sx;
+    reference "RFC 8791: YANG Data Structure Extensions";
   }
 
   organization
@@ -26,8 +27,6 @@ module ietf-voucher {
               <mailto:kent+ietf@watsen.net>
     Author:   Michael Richardson
               <mailto:mcr+ietf@sandelman.ca>
-    Author:   Max Pritikin
-              <mailto:pritikin@cisco.com>
     Author:   Toerless Eckert
               <mailto:tte@cs.fau.de>
     Author:   Qiufang Ma
@@ -42,7 +41,7 @@ module ietf-voucher {
      pledge may establish a secure connection to the owner's
      network infrastructure.
 
-     Copyright (c) 2023 IETF Trust and the persons identified as
+     Copyright (c) 2023-2026 IETF Trust and the persons identified as
      authors of the code.  All rights reserved.
 
      Redistribution and use in source and binary forms, with or
@@ -79,7 +78,7 @@ module ietf-voucher {
       "RFC 8366: Voucher Profile for Bootstrapping Protocols";
   }
 
-  grouping voucher-artifact-grouping {
+  grouping voucher-artifact {
     description
       "Grouping to allow reuse/extensions in future work.";
 
@@ -176,7 +175,7 @@ module ietf-voucher {
            certificate.  In the voucher, it is optional
            as some manufacturers know that all serial-numbers
            are unique within the scope of a MASA.
-        In the voucher request, whether it is mandatory or optional depends 
+        In the voucher request, whether it is mandatory or optional depends
         upon the which protocol is used, such as RFC8995 and variations.
            When processing a voucher, a pledge MUST ensure that its
            IDevID Authority Key Identifier matches this value.  If no
@@ -194,7 +193,7 @@ module ietf-voucher {
           description
            "An X.509 v3 certificate structure, as specified by
             RFC 5280, using Distinguished Encoding Rules (DER)
-            encoding, as defined in ITU-T X.690.
+            encoding, as defined in [ITU-T.X690.2015].
 
             This certificate is used by a pledge to trust a Public Key
             Infrastructure in order to verify a domain certificate
@@ -221,12 +220,7 @@ module ietf-voucher {
              the voucher. The pinned-domain-pubk
              is the Raw Public Key of the registrar.
              This field is encoded as a Subject Public Key Info block
-             as specified in RFC7250, in 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.";
+             as specified in RFC7250, in section 3.";
         }
 
         leaf pinned-domain-pubk-sha256 {
@@ -331,7 +325,7 @@ module ietf-voucher {
 
   // Top-level statement
   sx:structure voucher {
-    uses voucher-artifact-grouping;
+    uses voucher-artifact;
   }
 
 }