diff options
Diffstat (limited to 'doc/rfc/rfc8995.txt')
| -rw-r--r-- | doc/rfc/rfc8995.txt | 5730 |
1 files changed, 5730 insertions, 0 deletions
diff --git a/doc/rfc/rfc8995.txt b/doc/rfc/rfc8995.txt new file mode 100644 index 0000000..24ac99a --- /dev/null +++ b/doc/rfc/rfc8995.txt @@ -0,0 +1,5730 @@ + + + + +Internet Engineering Task Force (IETF) M. Pritikin +Request for Comments: 8995 Cisco +Category: Standards Track M. Richardson +ISSN: 2070-1721 Sandelman Software Works + T. Eckert + Futurewei USA + M. Behringer + + K. Watsen + Watsen Networks + May 2021 + + + Bootstrapping Remote Secure Key Infrastructure (BRSKI) + +Abstract + + This document specifies automated bootstrapping of an Autonomic + Control Plane. To do this, a Secure Key Infrastructure is + bootstrapped. This is done using manufacturer-installed X.509 + certificates, in combination with a manufacturer's authorizing + service, both online and offline. We call this process the + Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. + Bootstrapping a new device can occur when using a routable address + and a cloud service, only link-local connectivity, or limited/ + disconnected networks. Support for deployment models with less + stringent security requirements is included. Bootstrapping is + complete when the cryptographic identity of the new key + infrastructure is successfully deployed to the device. The + established secure connection can be used to deploy a locally issued + certificate to the device as well. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8995. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 1.1. Prior Bootstrapping Approaches + 1.2. Terminology + 1.3. Scope of Solution + 1.3.1. Support Environment + 1.3.2. Constrained Environments + 1.3.3. Network Access Controls + 1.3.4. Bootstrapping is Not Booting + 1.4. Leveraging the New Key Infrastructure / Next Steps + 1.5. Requirements for Autonomic Networking Infrastructure (ANI) + Devices + 2. Architectural Overview + 2.1. Behavior of a Pledge + 2.2. Secure Imprinting Using Vouchers + 2.3. Initial Device Identifier + 2.3.1. Identification of the Pledge + 2.3.2. MASA URI Extension + 2.4. Protocol Flow + 2.5. Architectural Components + 2.5.1. Pledge + 2.5.2. Join Proxy + 2.5.3. Domain Registrar + 2.5.4. Manufacturer Service + 2.5.5. Public Key Infrastructure (PKI) + 2.6. Certificate Time Validation + 2.6.1. Lack of Real-Time Clock + 2.6.2. Infinite Lifetime of IDevID + 2.7. Cloud Registrar + 2.8. Determining the MASA to Contact + 3. Voucher-Request Artifact + 3.1. Nonceless Voucher-Requests + 3.2. Tree Diagram + 3.3. Examples + 3.4. YANG Module + 4. Proxying Details (Pledge -- Proxy -- Registrar) + 4.1. Pledge Discovery of Proxy + 4.1.1. Proxy GRASP Announcements + 4.2. CoAP Connection to Registrar + 4.3. Proxy Discovery and Communication of Registrar + 5. Protocol Details (Pledge -- Registrar -- MASA) + 5.1. BRSKI-EST TLS Establishment Details + 5.2. Pledge Requests Voucher from the Registrar + 5.3. Registrar Authorization of Pledge + 5.4. BRSKI-MASA TLS Establishment Details + 5.4.1. MASA Authentication of Customer Registrar + 5.5. Registrar Requests Voucher from MASA + 5.5.1. MASA Renewal of Expired Vouchers + 5.5.2. MASA Pinning of Registrar + 5.5.3. MASA Check of the Voucher-Request Signature + 5.5.4. MASA Verification of the Domain Registrar + 5.5.5. MASA Verification of the Pledge + 'prior-signed-voucher-request' + 5.5.6. MASA Nonce Handling + 5.6. MASA and Registrar Voucher Response + 5.6.1. Pledge Voucher Verification + 5.6.2. Pledge Authentication of Provisional TLS Connection + 5.7. Pledge BRSKI Status Telemetry + 5.8. Registrar Audit-Log Request + 5.8.1. MASA Audit-Log Response + 5.8.2. Calculation of domainID + 5.8.3. Registrar Audit-Log Verification + 5.9. EST Integration for PKI Bootstrapping + 5.9.1. EST Distribution of CA Certificates + 5.9.2. EST CSR Attributes + 5.9.3. EST Client Certificate Request + 5.9.4. Enrollment Status Telemetry + 5.9.5. Multiple Certificates + 5.9.6. EST over CoAP + 6. Clarification of Transfer-Encoding + 7. Reduced Security Operational Modes + 7.1. Trust Model + 7.2. Pledge Security Reductions + 7.3. Registrar Security Reductions + 7.4. MASA Security Reductions + 7.4.1. Issuing Nonceless Vouchers + 7.4.2. Trusting Owners on First Use + 7.4.3. Updating or Extending Voucher Trust Anchors + 8. IANA Considerations + 8.1. The IETF XML Registry + 8.2. YANG Module Names Registry + 8.3. BRSKI Well-Known Considerations + 8.3.1. BRSKI .well-known Registration + 8.3.2. BRSKI .well-known Registry + 8.4. PKIX Registry + 8.5. Pledge BRSKI Status Telemetry + 8.6. DNS Service Names + 8.7. GRASP Objective Names + 9. Applicability to the Autonomic Control Plane (ACP) + 9.1. Operational Requirements + 9.1.1. MASA Operational Requirements + 9.1.2. Domain Owner Operational Requirements + 9.1.3. Device Operational Requirements + 10. Privacy Considerations + 10.1. MASA Audit-Log + 10.2. What BRSKI-EST Reveals + 10.3. What BRSKI-MASA Reveals to the Manufacturer + 10.4. Manufacturers and Used or Stolen Equipment + 10.5. Manufacturers and Grey Market Equipment + 10.6. Some Mitigations for Meddling by Manufacturers + 10.7. Death of a Manufacturer + 11. Security Considerations + 11.1. Denial of Service (DoS) against MASA + 11.2. DomainID Must Be Resistant to Second-Preimage Attacks + 11.3. Availability of Good Random Numbers + 11.4. Freshness in Voucher-Requests + 11.5. Trusting Manufacturers + 11.6. Manufacturer Maintenance of Trust Anchors + 11.6.1. Compromise of Manufacturer IDevID Signing Keys + 11.6.2. Compromise of MASA Signing Keys + 11.6.3. Compromise of MASA Web Service + 11.7. YANG Module Security Considerations + 12. References + 12.1. Normative References + 12.2. Informative References + Appendix A. IPv4 and Non-ANI Operations + A.1. IPv4 Link-Local Addresses + A.2. Use of DHCPv4 + Appendix B. mDNS / DNS-SD Proxy Discovery Options + Appendix C. Example Vouchers + C.1. Keys Involved + C.1.1. Manufacturer Certification Authority for IDevID + Signatures + C.1.2. MASA Key Pair for Voucher Signatures + C.1.3. Registrar Certification Authority + C.1.4. Registrar Key Pair + C.1.5. Pledge Key Pair + C.2. Example Process + C.2.1. Pledge to Registrar + C.2.2. Registrar to MASA + C.2.3. MASA to Registrar + Acknowledgements + Authors' Addresses + +1. Introduction + + The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol + provides a solution for secure zero-touch (automated) bootstrap of + new (unconfigured) devices that are called "pledges" in this + document. Pledges have an Initial Device Identifier (IDevID) + installed in them at the factory. + + "BRSKI", pronounced like "brewski", is a colloquial term for beer in + Canada and parts of the Midwestern United States [brewski]. + + This document primarily provides for the needs of the ISP and + enterprise-focused Autonomic Networking Integrated Model and Approach + (ANIMA) Autonomic Control Plane (ACP) [RFC8994]. This bootstrap + process satisfies the requirement of making all operations secure by + default per Section 3.3 of [RFC7575]. Other users of the BRSKI + protocol will need to provide separate applicability statements that + include privacy and security considerations appropriate to that + deployment. Section 9 explains the detailed applicability for this + ACP usage. + + The BRSKI protocol requires a significant amount of communication + between manufacturer and owner: in its default modes, it provides a + cryptographic transfer of control to the initial owner. In its + strongest modes, it leverages sales channel information to identify + the owner in advance. Resale of devices is possible, provided that + the manufacturer is willing to authorize the transfer. Mechanisms to + enable transfers of ownership without manufacturer authorization are + not included in this version of the protocol, but it could be + designed into future versions. + + This document describes how a pledge discovers (or are discovered by) + an element of the network domain that it will belong to and that will + perform its bootstrap. This element (device) is called the + "registrar". Before any other operation, the pledge and registrar + need to establish mutual trust: + + 1. Registrar authenticating the pledge: "Who is this device? What + is its identity?" + + 2. Registrar authorizing the pledge: "Is it mine? Do I want it? + What are the chances it has been compromised?" + + 3. Pledge authenticating the registrar: "What is this registrar's + identity?" + + 4. Pledge authorizing the registrar: "Should I join this network?" + + This document details protocols and messages to answer the above + questions. It uses a TLS connection and a PKIX-shaped (X.509v3) + certificate (an IEEE 802.1AR IDevID [IDevID]) of the pledge to answer + points 1 and 2. It uses a new artifact called a "voucher" that the + registrar receives from a Manufacturer Authorized Signing Authority + (MASA) and passes it to the pledge to answer points 3 and 4. + + A proxy provides very limited connectivity between the pledge and the + registrar. + + The syntactic details of vouchers are described in detail in + [RFC8366]. This document details automated protocol mechanisms to + obtain vouchers, including the definition of a "voucher-request" + message that is a minor extension to the voucher format (see + Section 3) as defined by [RFC8366]. + + BRSKI results in the pledge storing an X.509 root certificate + sufficient for verifying the registrar identity. In the process, a + TLS connection is established that can be directly used for + Enrollment over Secure Transport (EST). In effect, BRSKI provides an + automated mechanism for "Bootstrap Distribution of CA Certificates" + described in [RFC7030], Section 4.1.1, wherein the pledge "MUST [...] + engage a human user to authorize the CA certificate using out-of-band + data". With BRSKI, the pledge now can automate this process using + the voucher. Integration with a complete EST enrollment is optional + but trivial. + + BRSKI is agile enough to support bootstrapping alternative key + infrastructures, such as a symmetric key solution, but no such system + is described in this document. + +1.1. Prior Bootstrapping Approaches + + To literally "pull yourself up by the bootstraps" is an impossible + action. Similarly, the secure establishment of a key infrastructure + without external help is also an impossibility. Today, it is + commonly accepted that the initial connections between nodes are + insecure, until key distribution is complete, or that domain-specific + keying material (often pre-shared keys, including mechanisms like + Subscriber Identification Module (SIM) cards) is pre-provisioned on + each new device in a costly and non-scalable manner. Existing + automated mechanisms are known as non-secured "Trust on First Use + (TOFU)" [RFC7435], "resurrecting duckling" + [Stajano99theresurrecting], or "pre-staging". + + Another prior approach has been to try and minimize user actions + during bootstrapping, but not eliminate all user actions. The + original EST protocol [RFC7030] does reduce user actions during + bootstrapping but does not provide solutions for how the following + protocol steps can be made autonomic (not involving user actions): + + * using the Implicit Trust Anchor (TA) [RFC7030] database to + authenticate an owner-specific service (not an autonomic solution + because the URL must be securely distributed), + + * engaging a human user to authorize the CA certificate using out- + of-band data (not an autonomic solution because the human user is + involved), + + * using a configured Explicit TA database (not an autonomic solution + because the distribution of an explicit TA database is not + autonomic), and + + * using a certificate-less TLS mutual authentication method (not an + autonomic solution because the distribution of symmetric key + material is not autonomic). + + These "touch" methods do not meet the requirements for zero-touch. + + There are "call home" technologies where the pledge first establishes + a connection to a well-known manufacturer service using a common + client-server authentication model. After mutual authentication, + appropriate credentials to authenticate the target domain are + transferred to the pledge. This creates several problems and + limitations: + + * the pledge requires real-time connectivity to the manufacturer + service, + + * the domain identity is exposed to the manufacturer service (this + is a privacy concern), and + + * the manufacturer is responsible for making the authorization + decisions (this is a liability concern). + + BRSKI addresses these issues by defining extensions to the EST + protocol for the automated distribution of vouchers. + +1.2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + The following terms are defined for clarity: + + ANI: The Autonomic Networking Infrastructure as defined by + [RFC8993]. Section 9 details specific requirements for pledges, + proxies, and registrars when they are part of an ANI. + + Circuit Proxy: A stateful implementation of the Join Proxy. This is + the assumed type of proxy. + + drop-ship: The physical distribution of equipment containing the + "factory default" configuration to a final destination. In zero- + touch scenarios, there is no staging or preconfiguration during + drop-ship. + + Domain: The set of entities that share a common local trust anchor. + This includes the proxy, registrar, domain CA, management + components, and any existing entity that is already a member of + the domain. + + Domain CA: The domain Certification Authority (CA) provides + certification functionalities to the domain. At a minimum, it + provides certification functionalities to a registrar and manages + the private key that defines the domain. Optionally, it certifies + all elements. + + domainID: The domain IDentity is a unique value based upon the + registrar's CA certificate. Section 5.8.2 specifies how it is + calculated. + + enrollment: The process where a device presents key material to a + network and acquires a network-specific identity. For example, + when a certificate signing request is presented to a CA, and a + certificate is obtained in response. + + IDevID: An Initial Device Identifier X.509 certificate installed by + the vendor on new equipment. This is a term from 802.1AR + [IDevID]. + + imprint: The process where a device obtains the cryptographic key + material to identify and trust future interactions with a network. + This term is taken from Konrad Lorenz's work in biology with new + ducklings: during a critical period, the duckling would assume + that anything that looks like a mother duck is in fact their + mother. An equivalent for a device is to obtain the fingerprint + of the network's root CA certificate. A device that imprints on + an attacker suffers a similar fate to a duckling that imprints on + a hungry wolf. Securely imprinting is a primary focus of this + document [imprinting]. The analogy to Lorenz's work was first + noted in [Stajano99theresurrecting]. + + IPIP Proxy: A stateless proxy alternative. + + Join Proxy: A domain entity that helps the pledge join the domain. + A Join Proxy facilitates communication for devices that find + themselves in an environment where they are not provided + connectivity until after they are validated as members of the + domain. For simplicity, this document sometimes uses the term of + "proxy" to indicate the Join Proxy. The pledge is unaware that + they are communicating with a proxy rather than directly with a + registrar. + + Join Registrar (and Coordinator): A representative of the domain + that is configured, perhaps autonomically, to decide whether a new + device is allowed to join the domain. The administrator of the + domain interfaces with a "Join Registrar (and Coordinator)" to + control this process. Typically, a Join Registrar is "inside" its + domain. For simplicity, this document often refers to this as + just "registrar". Within [RFC8993], it is referred to as the + "Join Registrar Autonomic Service Agent (ASA)". Other communities + use the abbreviation "JRC". + + LDevID: A Local Device Identifier X.509 certificate installed by the + owner of the equipment. This is a term from 802.1AR [IDevID]. + + manufacturer: The term manufacturer is used throughout this document + as the entity that created the device. This is typically the + original equipment manufacturer (OEM), but in more complex + situations, it could be a value added retailer (VAR), or possibly + even a systems integrator. In general, a goal of BRSKI is to + eliminate small distinctions between different sales channels. + The reason for this is that it permits a single device, with a + uniform firmware load, to be shipped directly to all customers. + This eliminates costs for the manufacturer. This also reduces the + number of products supported in the field, increasing the chance + that firmware will be more up to date. + + MASA Audit-Log: An anonymized list of previous owners maintained by + the MASA on a per-device (per-pledge) basis, as described in + Section 5.8.1. + + MASA Service: A third-party MASA service on the global Internet. + The MASA signs vouchers. It also provides a repository for audit- + log information of privacy-protected bootstrapping events. It + does not track ownership. + + nonced: A voucher (or request) that contains a nonce (the normal + case). + + nonceless: A voucher (or request) that does not contain a nonce and + either relies upon accurate clocks for expiration or does not + expire. + + offline: When an architectural component cannot perform real-time + communications with a peer, due to either network connectivity or + the peer being turned off, the operation is said to be occurring + offline. + + Ownership Tracker: An Ownership Tracker service on the global + Internet. The Ownership Tracker uses business processes to + accurately track ownership of all devices shipped against domains + that have purchased them. Although optional, this component + allows vendors to provide additional value in cases where their + sales and distribution channels allow for accurate tracking of + such ownership. Tracking information about ownership is indicated + in vouchers, as described in [RFC8366]. + + Pledge: The prospective (unconfigured) device, which has an identity + installed at the factory. + + (Public) Key Infrastructure: The collection of systems and processes + that sustains the activities of a public key system. The + registrar acts as a "Registration Authority"; see [RFC5280] and + Section 7 of [RFC5272]. + + TOFU: Trust on First Use. Used similarly to how it is described in + [RFC7435]. This is where a pledge device makes no security + decisions but rather simply trusts the first registrar it is + contacted by. This is also known as the "resurrecting duckling" + model. + + Voucher: A signed artifact from the MASA that indicates the + cryptographic identity of the registrar it should trust to a + pledge. There are different types of vouchers depending on how + that trust is asserted. Multiple voucher types are defined in + [RFC8366]. + +1.3. Scope of Solution + +1.3.1. Support Environment + + This solution (BRSKI) can support large router platforms with multi- + gigabit inter-connections, mounted in controlled access data centers. + But this solution is not exclusive to large equipment: it is intended + to scale to thousands of devices located in hostile environments, + such as ISP-provided Customer Premises Equipment (CPE) devices that + are drop-shipped to the end user. The situation where an order is + fulfilled from a distributed warehouse from a common stock and + shipped directly to the target location at the request of a domain + owner is explicitly supported. That stock ("SKU") could be provided + to a number of potential domain owners, and the eventual domain owner + will not know a priori which device will go to which location. + + The bootstrapping process can take minutes to complete depending on + the network infrastructure and device processing speed. The network + communication itself is not optimized for speed; for privacy reasons, + the discovery process allows for the pledge to avoid announcing its + presence through broadcasting. + + Nomadic or mobile devices often need to acquire credentials to access + the network at the new location. An example of this is mobile phone + roaming among network operators, or even between cell towers. This + is usually called "handoff". BRSKI does not provide a low-latency + handoff, which is usually a requirement in such situations. For + these solutions, BRSKI can be used to create a relationship (an + LDevID) with the "home" domain owner. The resulting credentials are + then used to provide credentials more appropriate for a low-latency + handoff. + +1.3.2. Constrained Environments + + Questions have been posed as to whether this solution is suitable in + general for Internet of Things (IoT) networks. This depends on the + capabilities of the devices in question. The terminology of + [RFC7228] is best used to describe the boundaries. + + The solution described in this document is aimed in general at non- + constrained (i.e., Class 2+ [RFC7228]) devices operating on a non- + challenged network. The entire solution as described here is not + intended to be usable as is by constrained devices operating on + challenged networks (such as 802.15.4 Low-Power and Lossy Networks + (LLNs)). + + Specifically, there are protocol aspects described here that might + result in congestion collapse or energy exhaustion of intermediate + battery-powered routers in an LLN. Those types of networks should + not use this solution. These limitations are predominately related + to the large credential and key sizes required for device + authentication. Defining symmetric key techniques that meet the + operational requirements is out of scope, but the underlying protocol + operations (TLS handshake and signing structures) have sufficient + algorithm agility to support such techniques when defined. + + The imprint protocol described here could, however, be used by non- + energy constrained devices joining a non-constrained network (for + instance, smart light bulbs are usually mains powered and use 802.11 + wireless technology). It could also be used by non-constrained + devices across a non-energy constrained, but challenged, network + (such as 802.15.4). The certificate contents, and the process by + which the four questions above are resolved, do apply to constrained + devices. It is simply the actual on-the-wire imprint protocol that + could be inappropriate. + +1.3.3. Network Access Controls + + This document presumes that network access control has already + occurred, is not required, or is integrated by the proxy and + registrar in such a way that the device itself does not need to be + aware of the details. Although the use of an X.509 IDevID is + consistent with IEEE 802.1AR [IDevID], and allows for alignment with + 802.1X network access control methods, its use here is for pledge + authentication rather than network access control. Integrating this + protocol with network access control, perhaps as an Extensible + Authentication Protocol (EAP) method (see [RFC3748]), is out of scope + for this document. + +1.3.4. Bootstrapping is Not Booting + + This document describes "bootstrapping" as the protocol used to + obtain a local trust anchor. It is expected that this trust anchor, + along with any additional configuration information subsequently + installed, is persisted on the device across system restarts + ("booting"). Bootstrapping occurs only infrequently such as when a + device is transferred to a new owner or has been reset to factory + default settings. + +1.4. Leveraging the New Key Infrastructure / Next Steps + + As a result of the protocol described herein, bootstrapped devices + have the domain CA trust anchor in common. An end-entity (EE) + certificate has optionally been issued from the domain CA. This + makes it possible to securely deploy functionalities across the + domain; for example: + + * Device management + + * Routing authentication + + * Service discovery + + The major intended benefit is the ability to use the credentials + deployed by this protocol to secure the Autonomic Control Plane (ACP) + [RFC8994]. + +1.5. Requirements for Autonomic Networking Infrastructure (ANI) Devices + + The BRSKI protocol can be used in a number of environments. Some of + the options in this document are the result of requirements that are + out of the ANI scope. This section defines the base requirements for + ANI devices. + + For devices that intend to become part of an ANI [RFC8993] that + includes an Autonomic Control Plane [RFC8994], the BRSKI protocol + MUST be implemented. + + The pledge must perform discovery of the proxy as described in + Section 4.1 using the Discovery Unsolicited Link-Local (DULL) + [RFC8990] M_FLOOD announcements of the GeneRic Autonomic Signaling + Protocol (GRASP). + + Upon successfully validating a voucher artifact, a status telemetry + MUST be returned; see Section 5.7. + + An ANIMA ANI pledge MUST implement the EST automation extensions + described in Section 5.9. They supplement the EST [RFC7030] to + better support automated devices that do not have an end user. + + The ANI Join Registrar ASA MUST support all the BRSKI and above- + listed EST operations. + + All ANI devices SHOULD support the BRSKI proxy function, using + Circuit Proxies over the Autonomic Control Plane (ACP) (see + Section 4.3). + +2. Architectural Overview + + The logical elements of the bootstrapping framework are described in + this section. Figure 1 provides a simplified overview of the + components. + + +------------------------+ + +--------------Drop-Ship----------------| Vendor Service | + | +------------------------+ + | | M anufacturer| | + | | A uthorized |Ownership| + | | S igning |Tracker | + | | A uthority | | + | +--------------+---------+ + | ^ + | | BRSKI- + V | MASA + +-------+ ............................................|... + | | . | . + | | . +------------+ +-----------+ | . + | | . | | | | | . + |Pledge | . | Join | | Domain <-------+ . + | | . | Proxy | | Registrar | . + | <-------->............<-------> (PKI RA) | . + | | | BRSKI-EST | | . + | | . | | +-----+-----+ . + |IDevID | . +------------+ | e.g., RFC 7030 . + | | . +-----------------+----------+ . + | | . | Key Infrastructure | . + | | . | (e.g., PKI CA) | . + +-------+ . | | . + . +----------------------------+ . + . . + ................................................ + "Domain" Components + + Figure 1: Architecture Overview + + We assume a multivendor network. In such an environment, there could + be a manufacturer service for each manufacturer that supports devices + following this document's specification, or an integrator could + provide a generic service authorized by multiple manufacturers. It + is unlikely that an integrator could provide ownership tracking + services for multiple manufacturers due to the required sales channel + integrations necessary to track ownership. + + The domain is the managed network infrastructure with a key + infrastructure that the pledge is joining. The domain provides + initial device connectivity sufficient for bootstrapping through a + proxy. The domain registrar authenticates the pledge, makes + authorization decisions, and distributes vouchers obtained from the + manufacturer service. Optionally, the registrar also acts as a PKI + CA. + +2.1. Behavior of a Pledge + + The pledge goes through a series of steps, which are outlined here at + a high level. + + ------------ + / Factory \ + \ default / + -----+------ + | + +------v-------+ + | (1) Discover | + +------------> | + | +------+-------+ + | | + | +------v-------+ + | | (2) Identify | + ^------------+ | + | rejected +------+-------+ + | | + | +------v-------+ + | | (3) Request | + | | Join | + | +------+-------+ + | | + | +------v-------+ + | | (4) Imprint | + ^------------+ | + | Bad MASA +------+-------+ + | response | send Voucher Status Telemetry + | +------v-------+ + | | (5) Enroll |<---+ (non-error HTTP codes) + ^------------+ |\___/ (e.g., 202 "Retry-After") + | Enroll +------+-------+ + | failure | + | -----v------ + | / Enrolled \ + ^------------+ | + Factory \------------/ + reset + + Figure 2: Pledge State Diagram + + State descriptions for the pledge are as follows: + + 1. Discover a communication channel to a registrar. + + 2. Identify itself. This is done by presenting an X.509 IDevID + credential to the discovered registrar (via the proxy) in a TLS + handshake. (The registrar credentials are only provisionally + accepted at this time.) + + 3. Request to join the discovered registrar. A unique nonce is + included, ensuring that any responses can be associated with this + particular bootstrapping attempt. + + 4. Imprint on the registrar. This requires verification of the + manufacturer-service-provided voucher. A voucher contains + sufficient information for the pledge to complete authentication + of a registrar. This document details this step in depth. + + 5. Enroll. After imprint, an authenticated TLS (HTTPS) connection + exists between the pledge and registrar. EST [RFC7030] can then + be used to obtain a domain certificate from a registrar. + + The pledge is now a member of, and can be managed by, the domain and + will only repeat the discovery aspects of bootstrapping if it is + returned to factory default settings. + + This specification details integration with EST enrollment so that + pledges can optionally obtain a locally issued certificate, although + any Representational State Transfer (REST) (see [REST]) interface + could be integrated in future work. + +2.2. Secure Imprinting Using Vouchers + + A voucher is a cryptographically protected artifact (using a digital + signature) to the pledge device authorizing a zero-touch imprint on + the registrar domain. + + The format and cryptographic mechanism of vouchers is described in + detail in [RFC8366]. + + Vouchers provide a flexible mechanism to secure imprinting: the + pledge device only imprints when a voucher can be validated. At the + lowest security levels, the MASA can indiscriminately issue vouchers + and log claims of ownership by domains. At the highest security + levels, issuance of vouchers can be integrated with complex sales + channel integrations that are beyond the scope of this document. The + sales channel integration would verify actual (legal) ownership of + the pledge by the domain. This provides the flexibility for a number + of use cases via a single common protocol mechanism on the pledge and + registrar devices that are to be widely deployed in the field. The + MASA services have the flexibility to either leverage the currently + defined claim mechanisms or experiment with higher or lower security + levels. + + Vouchers provide a signed but non-encrypted communication channel + among the pledge, the MASA, and the registrar. The registrar + maintains control over the transport and policy decisions, allowing + the local security policy of the domain network to be enforced. + +2.3. Initial Device Identifier + + Pledge authentication and pledge voucher-request signing is via a + PKIX-shaped certificate installed during the manufacturing process. + This is the 802.1AR IDevID, and it provides a basis for + authenticating the pledge during the protocol exchanges described + here. There is no requirement for a common root PKI hierarchy. Each + device manufacturer can generate its own root certificate. + Specifically, the IDevID enables: + + * Uniquely identifying the pledge by the Distinguished Name (DN) and + subjectAltName (SAN) parameters in the IDevID. The unique + identification of a pledge in the voucher objects are derived from + those parameters as described below. Section 10.3 discusses + privacy implications of the identifier. + + * Providing a cryptographic authentication of the pledge to the + registrar (see Section 5.3). + + * Securing auto-discovery of the pledge's MASA by the registrar (see + Section 2.8). + + * Signing of a voucher-request by the pledge's IDevID (see + Section 3). + + * Providing a cryptographic authentication of the pledge to the MASA + (see Section 5.5.5). + + Sections 7.2.13 (2009 edition) and 8.10.3 (2018 edition) of [IDevID] + discuss keyUsage and extendedKeyUsage extensions in the IDevID + certificate. [IDevID] acknowledges that adding restrictions in the + certificate limits applicability of these long-lived certificates. + This specification emphasizes this point and therefore RECOMMENDS + that no key usage restrictions be included. This is consistent with + [RFC5280], Section 4.2.1.3, which does not require key usage + restrictions for end-entity certificates. + +2.3.1. Identification of the Pledge + + In the context of BRSKI, pledges have a 1:1 relationship with a + "serial-number". This serial-number is used both in the serial- + number field of a voucher or voucher-requests (see Section 3) and in + local policies on the registrar or MASA (see Section 5). + + There is a (certificate) serialNumber field defined in [RFC5280], + Section 4.1.2.2. In ASN.1, this is referred to as the + CertificateSerialNumber. This field is NOT relevant to this + specification. Do not confuse this field with the serial-number + defined by this document, or by [IDevID] and [RFC4519], Section 2.31. + + The device serial number is defined in Appendix A.1 of [RFC5280] as + the X520SerialNumber, with the OID tag id-at-serialNumber. + + The device _serialNumber_ field (X520SerialNumber) is used as follows + by the pledge to build the *serial-number* that is placed in the + voucher-request. In order to build it, the fields need to be + converted into a serial-number of "type string". + + An example of a printable form of the serialNumber field is provided + in [RFC4519], Section 2.31 ("WI-3005"). That section further + provides equality and syntax attributes. + + Due to the reality of existing device identity provisioning + processes, some manufacturers have stored serial-numbers in other + fields. Registrars SHOULD be configurable, on a per-manufacturer + basis, to look for serial-number equivalents in other fields. + + As explained in Section 5.5, the registrar MUST again extract the + serialNumber itself from the pledge's TLS certificate. It can + consult the serial-number in the pledge request if there is any + possible confusion about the source of the serial-number. + +2.3.2. MASA URI Extension + + This document defines a new PKIX non-critical certificate extension + to carry the MASA URI. This extension is intended to be used in the + IDevID certificate. The URI is represented as described in + Section 7.4 of [RFC5280]. + + The URI provides the authority information. The BRSKI "/.well-known" + tree [RFC8615] is described in Section 5. + + A complete URI MAY be in this extension, including the "scheme", + "authority", and "path". The complete URI will typically be used in + diagnostic or experimental situations. Typically (and in + consideration to constrained systems), this SHOULD be reduced to only + the "authority", in which case a scheme of "https://" (see [RFC7230], + Section 2.7.3) and a "path" of "/.well-known/brski" is to be assumed. + + The registrar can assume that only the "authority" is present in the + extension, if there are no slash ("/") characters in the extension. + + Section 7.4 of [RFC5280] calls out various schemes that MUST be + supported, including the Lightweight Directory Access Protocol + (LDAP), HTTP, and FTP. However, the registrar MUST use HTTPS for the + BRSKI-MASA connection. + + The new extension is identified as follows: + + <CODE BEGINS> + MASAURLExtnModule-2016 { iso(1) identified-organization(3) dod(6) + internet(1) security(5) mechanisms(5) pkix(7) + id-mod(0) id-mod-MASAURLExtn2016(96) } + + DEFINITIONS IMPLICIT TAGS ::= BEGIN + + -- EXPORTS ALL -- + + IMPORTS + EXTENSION + FROM PKIX-CommonTypes-2009 + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-pkixCommon-02(57) } + + id-pe FROM PKIX1Explicit-2009 + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-pkix1-explicit-02(51) } ; + + MASACertExtensions EXTENSION ::= { ext-MASAURL, ... } + ext-MASAURL EXTENSION ::= { SYNTAX MASAURLSyntax + IDENTIFIED BY id-pe-masa-url } + + id-pe-masa-url OBJECT IDENTIFIER ::= { id-pe 32 } + + MASAURLSyntax ::= IA5String + + END + <CODE ENDS> + + Figure 3: MASAURL ASN.1 Module + + The choice of id-pe is based on guidance found in Section 4.2.2 of + [RFC5280]: "These extensions may be used to direct applications to + on-line information about the issuer or the subject". The MASA URL + is precisely that: online information about the particular subject. + +2.4. Protocol Flow + + A representative flow is shown in Figure 4. + + +--------+ +---------+ +------------+ +------------+ + | Pledge | | Circuit | | Domain | | Vendor | + | | | Join | | Registrar | | Service | + | | | Proxy | | (JRC) | | (MASA) | + +--------+ +---------+ +------------+ +------------+ + | | | Internet | + [discover] | | | + |<-RFC 4862 IPv6 addr | | | + |<-RFC 3927 IPv4 addr | Appendix A | Legend | + |-++++++++++++++++++->| | C - Circuit | + | optional: mDNS query| Appendix B | Join Proxy | + | RFCs 6763/6762 (+) | | P - Provisional TLS| + |<-++++++++++++++++++-| | Connection | + | GRASP M_FLOOD | | | + | periodic broadcast| | | + [identity] | | | + |<------------------->C<----------------->| | + | TLS via the Join Proxy | | + |<--Registrar TLS server authentication---| | + [PROVISIONAL accept of server cert] | | + P---X.509 client authentication---------->| | + [request join] | | + P---Voucher-Request(w/nonce for voucher)->| | + P /------------------- | | + P | [accept device?] | + P | [contact vendor] | + P | |--Pledge ID-------->| + P | |--Domain ID-------->| + P | |--optional:nonce--->| + P optional: | [extract DomainID] + P can occur in advance | [update audit-log] + P if nonceless | | + P | |<- voucher ---------| + P \------------------- | w/nonce if provided| + P<------voucher---------------------------| | + [imprint] | | + |-------voucher status telemetry--------->| | + | |<-device audit-log--| + | [verify audit-log and voucher] | + |<--------------------------------------->| | + [enroll] | | + | Continue with enrollment using now | | + | bidirectionally authenticated TLS | | + | session per RFC 7030. | | + [enrolled] | | + + Figure 4: Protocol Time Sequence Diagram + + On initial bootstrap, a new device (the pledge) uses a local service + auto-discovery (the GeneRic Autonomic Signaling Protocol (GRASP) or + Multicast DNS (mDNS)) to locate a Join Proxy. The Join Proxy + connects the pledge to a local registrar (the JRC). + + Having found a candidate registrar, the fledgling pledge sends some + information about itself to the registrar, including its serial + number in the form of a voucher-request and its IDevID certificate as + part of the TLS session. + + The registrar can determine whether it expected such a device to + appear and locates a MASA. The location of the MASA is usually found + in an extension in the IDevID. Having determined that the MASA is + suitable, the entire information from the initial voucher-request + (including the device's serial number) is transmitted over the + Internet in a TLS-protected channel to the manufacturer, along with + information about the registrar/owner. + + The manufacturer can then apply policy based on the provided + information, as well as other sources of information (such as sales + records), to decide whether to approve the claim by the registrar to + own the device; if the claim is accepted, a voucher is issued that + directs the device to accept its new owner. + + The voucher is returned to the registrar, but not immediately to the + device -- the registrar has an opportunity to examine the voucher, + the MASA's audit-logs, and other sources of information to determine + whether the device has been tampered with and whether the bootstrap + should be accepted. + + No filtering of information is possible in the signed voucher, so + this is a binary yes-or-no decision. After the registrar has applied + any local policy to the voucher, if it accepts the voucher, then the + voucher is returned to the pledge for imprinting. + + The voucher also includes a trust anchor that the pledge uses to + represent the owner. This is used to successfully bootstrap from an + environment where only the manufacturer has built-in trust by the + device to an environment where the owner now has a PKI footprint on + the device. + + When BRSKI is followed with EST, this single footprint is further + leveraged into the full owner's PKI and an LDevID for the device. + Subsequent reporting steps provide flows of information to indicate + success/failure of the process. + +2.5. Architectural Components + +2.5.1. Pledge + + The pledge is the device that is attempting to join. It is assumed + that the pledge talks to the Join Proxy using link-local network + connectivity. In most cases, the pledge has no other connectivity + until the pledge completes the enrollment process and receives some + kind of network credential. + +2.5.2. Join Proxy + + The Join Proxy provides HTTPS connectivity between the pledge and the + registrar. A Circuit Proxy mechanism is described in Section 4. + Additional mechanisms, including a Constrained Application Protocol + (CoAP) mechanism and a stateless IP in IP (IPIP) mechanism, are the + subject of future work. + +2.5.3. Domain Registrar + + The domain's registrar operates as the BRSKI-MASA client when + requesting vouchers from the MASA (see Section 5.4). The registrar + operates as the BRSKI-EST server when pledges request vouchers (see + Section 5.1). The registrar operates as the BRSKI-EST server + "Registration Authority" if the pledge requests an end-entity + certificate over the BRSKI-EST connection (see Section 5.9). + + The registrar uses an Implicit Trust Anchor database for + authenticating the BRSKI-MASA connection's MASA TLS server + certificate. Configuration or distribution of trust anchors is out + of scope for this specification. + + The registrar uses a different Implicit Trust Anchor database for + authenticating the BRSKI-EST connection's pledge TLS Client + Certificate. Configuration or distribution of the BRSKI-EST client + trust anchors is out of scope of this specification. Note that the + trust anchors in / excluded from the database will affect which + manufacturers' devices are acceptable to the registrar as pledges, + and they can also be used to limit the set of MASAs that are trusted + for enrollment. + +2.5.4. Manufacturer Service + + The manufacturer service provides two logically separate functions: + the MASA as described in Sections 5.5 and 5.6 and an ownership + tracking/auditing function as described in Sections 5.7 and 5.8. + +2.5.5. Public Key Infrastructure (PKI) + + The Public Key Infrastructure (PKI) administers certificates for the + domain of concern, providing the trust anchor(s) for it and allowing + enrollment of pledges with domain certificates. + + The voucher provides a method for the distribution of a single PKI + trust anchor (as the "pinned-domain-cert"). A distribution of the + full set of current trust anchors is possible using the optional EST + integration. + + The domain's registrar acts as a Registration Authority [RFC5272], + requesting certificates for pledges from the PKI. + + The expectations of the PKI are unchanged from EST [RFC7030]. This + document does not place any additional architectural requirements on + the PKI. + +2.6. Certificate Time Validation + +2.6.1. Lack of Real-Time Clock + + When bootstrapping, many devices do not have knowledge of the current + time. Mechanisms such as Network Time Protocols cannot be secured + until bootstrapping is complete. Therefore, bootstrapping is defined + with a framework that does not require knowledge of the current time. + A pledge MAY ignore all time stamps in the voucher and in the + certificate validity periods if it does not know the current time. + + The pledge is exposed to dates in the following five places: + registrar certificate notBefore, registrar certificate notAfter, + voucher created-on, and voucher expires-on. Additionally, + Cryptographic Message Syntax (CMS) signatures contain a signingTime. + + A pledge with a real-time clock in which it has confidence MUST check + the above time fields in all certificates and signatures that it + processes. + + If the voucher contains a nonce, then the pledge MUST confirm the + nonce matches the original pledge voucher-request. This ensures the + voucher is fresh. See Section 5.2. + +2.6.2. Infinite Lifetime of IDevID + + Long-lived pledge certificates "SHOULD be assigned the + GeneralizedTime value of 99991231235959Z" for the notAfter field as + explained in [RFC5280]. + + Some deployed IDevID management systems are not compliant with the + 802.1AR requirement for infinite lifetimes and are put in typical <= + 3 year certificate lifetimes. Registrars SHOULD be configurable on a + per-manufacturer basis to ignore pledge lifetimes when the pledge + does not follow the recommendations in [RFC5280]. + +2.7. Cloud Registrar + + There exist operationally open networks wherein devices gain + unauthenticated access to the Internet at large. In these use cases, + the management domain for the device needs to be discovered within + the larger Internet. The case where a device can boot and get access + to a larger Internet is less likely within the ANIMA ACP scope but + may be more important in the future. In the ANIMA ACP scope, new + devices will be quarantined behind a Join Proxy. + + Additionally, there are some greenfield situations involving an + entirely new installation where a device may have some kind of + management uplink that it can use (such as via a 3G network, for + instance). In such a future situation, the device might use this + management interface to learn that it should configure itself to + become the local registrar. + + In order to support these scenarios, the pledge MAY contact a well- + known URI of a cloud registrar if a local registrar cannot be + discovered or if the pledge's target use cases do not include a local + registrar. + + If the pledge uses a well-known URI for contacting a cloud registrar, + a manufacturer-assigned Implicit Trust Anchor database (see + [RFC7030]) MUST be used to authenticate that service as described in + [RFC6125]. The use of a DNS-ID for validation is appropriate, and it + may include wildcard components on the left-mode side. This is + consistent with the human-user configuration of an EST server URI in + [RFC7030], which also depends on [RFC6125]. + +2.8. Determining the MASA to Contact + + The registrar needs to be able to contact a MASA that is trusted by + the pledge in order to obtain vouchers. + + The device's IDevID will normally contain the MASA URL as detailed in + Section 2.3. This is the RECOMMENDED mechanism. + + In some cases, it can be operationally difficult to ensure the + necessary X.509 extensions are in the pledge's IDevID due to the + difficulty of aligning current pledge manufacturing with software + releases and development; thus, as a final fallback, the registrar + MAY be manually configured or distributed with a MASA URL for each + manufacturer. Note that the registrar can only select the configured + MASA URL based on the trust anchor -- so manufacturers can only + leverage this approach if they ensure a single MASA URL works for all + pledges associated with each trust anchor. + +3. Voucher-Request Artifact + + Voucher-requests are how vouchers are requested. The semantics of + the voucher-request are described below, in the YANG module. + + A pledge forms the "pledge voucher-request", signs it with its + IDevID, and submits it to the registrar. + + In turn, the registrar forms the "registrar voucher-request", signs + it with its registrar key pair, and submits it to the MASA. + + The "proximity-registrar-cert" leaf is used in the pledge voucher- + requests. This provides a method for the pledge to assert the + registrar's proximity. + + This network proximity results from the following properties in the + ACP context: the pledge is connected to the Join Proxy (Section 4) + using a link-local IPv6 connection. While the Join Proxy does not + participate in any meaningful sense in the cryptography of the TLS + connection (such as via a Channel Binding), the registrar can observe + that the connection is via the private ACP (ULA) address of the Join + Proxy, and it cannot come from outside the ACP. The pledge must + therefore be at most one IPv6 link-local hop away from an existing + node on the ACP. + + Other users of BRSKI will need to define other kinds of assertions if + the network proximity described above does not match their needs. + + The "prior-signed-voucher-request" leaf is used in registrar voucher- + requests. If present, it is the signed pledge voucher-request + artifact. This provides a method for the registrar to forward the + pledge's signed request to the MASA. This completes transmission of + the signed proximity-registrar-cert leaf. + + Unless otherwise signaled (outside the voucher-request artifact), the + signing structure is as defined for vouchers; see [RFC8366]. + +3.1. Nonceless Voucher-Requests + + A registrar MAY also retrieve nonceless vouchers by sending nonceless + voucher-requests to the MASA in order to obtain vouchers for use when + the registrar does not have connectivity to the MASA. No prior- + signed-voucher-request leaf would be included. The registrar will + also need to know the serial number of the pledge. This document + does not provide a mechanism for the registrar to learn that in an + automated fashion. Typically, this will be done via the scanning of + a bar code or QR code on packaging, or via some sales channel + integration. + +3.2. Tree Diagram + + The following tree diagram illustrates a high-level view of a + voucher-request document. The voucher-request builds upon the + voucher artifact described in [RFC8366]. The tree diagram is + described in [RFC8340]. Each node in the diagram is fully described + by the YANG module in Section 3.4. Please review the YANG module for + a detailed description of the voucher-request format. + + module: ietf-voucher-request + + grouping voucher-request-grouping + +-- voucher + +-- created-on? yang:date-and-time + +-- expires-on? yang:date-and-time + +-- assertion? enumeration + +-- serial-number string + +-- idevid-issuer? binary + +-- pinned-domain-cert? binary + +-- domain-cert-revocation-checks? boolean + +-- nonce? binary + +-- last-renewal-date? yang:date-and-time + +-- prior-signed-voucher-request? binary + +-- proximity-registrar-cert? binary + + Figure 5: YANG Tree Diagram for a Voucher-Request + +3.3. Examples + + This section provides voucher-request examples for illustration + purposes. These examples show JSON prior to CMS wrapping. JSON + encoding rules specify that any binary content be base64 encoded + ([RFC4648], Section 4). The contents of the (base64) encoded + certificates have been elided to save space. For detailed examples, + see Appendix C.2. These examples conform to the encoding rules + defined in [RFC7951]. + + Example (1): The following example illustrates a pledge voucher- + request. The assertion leaf is indicated as + "proximity", and the registrar's TLS server certificate + is included in the proximity-registrar-cert leaf. See + Section 5.2. + + { + "ietf-voucher-request:voucher": { + "assertion": "proximity", + "nonce": "62a2e7693d82fcda2624de58fb6722e5", + "serial-number" : "JADA123456789", + "created-on": "2017-01-01T00:00:00.000Z", + "proximity-registrar-cert": "base64encodedvalue==" + } + } + + Figure 6: JSON Representation of an Example Voucher-Request + + Example (2): The following example illustrates a registrar voucher- + request. The prior-signed-voucher-request leaf is + populated with the pledge's voucher-request (such as + the prior example). The pledge's voucher-request is a + binary CMS-signed object. In the JSON encoding used + here, it must be base64 encoded. The nonce and + assertion have been carried forward from the pledge + request to the registrar request. The serial-number is + extracted from the pledge's Client Certificate from the + TLS connection. See Section 5.5. + + { + "ietf-voucher-request:voucher": { + "assertion" : "proximity", + "nonce": "62a2e7693d82fcda2624de58fb6722e5", + "created-on": "2017-01-01T00:00:02.000Z", + "idevid-issuer": "base64encodedvalue==", + "serial-number": "JADA123456789", + "prior-signed-voucher-request": "base64encodedvalue==" + } + } + + Figure 7: JSON Representation of an Example Prior-Signed Voucher- + Request + + Example (3): The following example illustrates a registrar voucher- + request. The prior-signed-voucher-request leaf is not + populated with the pledge's voucher-request nor is the + nonce leaf. This form might be used by a registrar + requesting a voucher when the pledge cannot communicate + with the registrar (such as when it is powered down or + still in packaging) and therefore cannot submit a + nonce. This scenario is most useful when the registrar + is aware that it will not be able to reach the MASA + during deployment. See Section 5.5. + + { + "ietf-voucher-request:voucher": { + "created-on": "2017-01-01T00:00:02.000Z", + "idevid-issuer": "base64encodedvalue==", + "serial-number": "JADA123456789" + } + } + + Figure 8: JSON Representation of an Offline Voucher-Request + +3.4. YANG Module + + Following is a YANG module [RFC7950] that formally extends a voucher + [RFC8366] into a voucher-request. This YANG module references + [ITU.X690]. + + <CODE BEGINS> file "ietf-voucher-request@2021-05-20.yang" + module ietf-voucher-request { + yang-version 1.1; + namespace "urn:ietf:params:xml:ns:yang:ietf-voucher-request"; + prefix vcr; + + 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 { + prefix vch; + description + "This module defines the format for a voucher, + which is produced by a pledge's manufacturer or + delegate (MASA) to securely assign a pledge to + an 'owner', so that the pledge may establish a secure + connection to the owner's network infrastructure."; + reference + "RFC 8366: A Voucher Artifact for + Bootstrapping Protocols"; + } + + organization + "IETF ANIMA Working Group"; + contact + "WG Web: <https://datatracker.ietf.org/wg/anima/> + WG List: <mailto:anima@ietf.org> + Author: Kent Watsen + <mailto:kent+ietf@watsen.net> + Author: Michael H. Behringer + <mailto:Michael.H.Behringer@gmail.com> + Author: Toerless Eckert + <mailto:tte+ietf@cs.fau.de> + Author: Max Pritikin + <mailto:pritikin@cisco.com> + Author: Michael Richardson + <mailto:mcr+ietf@sandelman.ca>"; + description + "This module defines the format for a voucher-request. + It is a superset of the voucher itself. + It provides content to the MASA for consideration + during a voucher-request. + + The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL + NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', + 'MAY', and 'OPTIONAL' in this document are to be interpreted as + described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, + they appear in all capitals, as shown here. + + Copyright (c) 2021 IETF Trust and the persons identified as + authors of the code. All rights reserved. + + Redistribution and use in source and binary forms, with or + without modification, is permitted pursuant to, and subject + to the license terms contained in, the Simplified BSD License + set forth in Section 4.c of the IETF Trust's Legal Provisions + Relating to IETF Documents + (https://trustee.ietf.org/license-info). + + This version of this YANG module is part of RFC 8995; see the + RFC itself for full legal notices."; + + revision 2021-05-20 { + description + "Initial version"; + reference + "RFC 8995: Bootstrapping Remote Secure Key Infrastructure + (BRSKI)"; + } + + // Top-level statement + rc:yang-data voucher-request-artifact { + uses voucher-request-grouping; + } + + // Grouping defined for future usage + + grouping voucher-request-grouping { + description + "Grouping to allow reuse/extensions in future work."; + uses vch:voucher-artifact-grouping { + refine "voucher/created-on" { + mandatory false; + } + refine "voucher/pinned-domain-cert" { + mandatory false; + description + "A pinned-domain-cert field is not valid in a + voucher-request, and any occurrence MUST be ignored."; + } + refine "voucher/last-renewal-date" { + description + "A last-renewal-date field is not valid in a + voucher-request, and any occurrence MUST be ignored."; + } + refine "voucher/domain-cert-revocation-checks" { + description + "The domain-cert-revocation-checks field is not valid in a + voucher-request, and any occurrence MUST be ignored."; + } + refine "voucher/assertion" { + mandatory false; + description + "Any assertion included in registrar voucher-requests + SHOULD be ignored by the MASA."; + } + augment "voucher" { + description + "Adds leaf nodes appropriate for requesting vouchers."; + leaf prior-signed-voucher-request { + type binary; + description + "If it is necessary to change a voucher, or re-sign and + forward a voucher that was previously provided along a + protocol path, then the previously signed voucher SHOULD + be included in this field. + + For example, a pledge might sign a voucher-request + with a proximity-registrar-cert, and the registrar + then includes it as the prior-signed-voucher-request + field. This is a simple mechanism for a chain of + trusted parties to change a voucher-request, while + maintaining the prior signature information. + + The registrar and MASA MAY examine the prior-signed + voucher information for the + purposes of policy decisions. For example, this + information could be useful to a MASA to determine + that both the pledge and registrar agree on proximity + assertions. The MASA SHOULD remove all + prior-signed-voucher-request information when + signing a voucher for imprinting so as to minimize + the final voucher size."; + } + leaf 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 pledge. This MUST be populated in a pledge's + voucher-request when a 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"; + } + } + } + } + } + <CODE ENDS> + + Figure 9: YANG Module for Voucher-Request + +4. Proxying Details (Pledge -- Proxy -- Registrar) + + This section is normative for uses with an ANIMA ACP. The use of the + GRASP mechanism is part of the ACP. Other users of BRSKI will need + to define an equivalent proxy mechanism and an equivalent mechanism + to configure the proxy. + + The role of the proxy is to facilitate communications. The proxy + forwards packets between the pledge and a registrar that has been + provisioned to the proxy via full GRASP ACP discovery. + + This section defines a stateful proxy mechanism that is referred to + as a "circuit" proxy. This is a form of Application Level Gateway + (see [RFC2663], Section 2.9). + + The proxy does not terminate the TLS handshake: it passes streams of + bytes onward without examination. A proxy MUST NOT assume any + specific TLS version. Please see [RFC8446], Section 9.3 for details + on TLS invariants. + + A registrar can directly provide the proxy announcements described + below, in which case the announced port can point directly to the + registrar itself. In this scenario, the pledge is unaware that there + is no proxying occurring. This is useful for registrars that are + servicing pledges on directly connected networks. + + As a result of the proxy discovery process in Section 4.1.1, the port + number exposed by the proxy does not need to be well known or require + an IANA allocation. + + During the discovery of the registrar by the Join Proxy, the Join + Proxy will also learn which kinds of proxy mechanisms are available. + This will allow the Join Proxy to use the lowest impact mechanism + that the Join Proxy and registrar have in common. + + In order to permit the proxy functionality to be implemented on the + maximum variety of devices, the chosen mechanism should use the + minimum amount of state on the proxy device. While many devices in + the ANIMA target space will be rather large routers, the proxy + function is likely to be implemented in the control-plane CPU of such + a device, with available capabilities for the proxy function similar + to many class 2 IoT devices. + + The document [ANIMA-STATE] provides a more extensive analysis and + background of the alternative proxy methods. + +4.1. Pledge Discovery of Proxy + + The result of discovery is a logical communication with a registrar, + through a proxy. The proxy is transparent to the pledge. The + communication between the pledge and Join Proxy is over IPv6 link- + local addresses. + + To discover the proxy, the pledge performs the following actions: + + 1. MUST: Obtain a local address using IPv6 methods as described in + "IPv6 Stateless Address Autoconfiguration" [RFC4862]. Use of + temporary addresses [RFC8981] is encouraged. To limit pervasive + monitoring [RFC7258], a new temporary address MAY use a short + lifetime (that is, set TEMP_PREFERRED_LIFETIME to be short). + Pledges will generally prefer use of IPv6 link-local addresses, + and discovery of the proxy will be by link-local mechanisms. + IPv4 methods are described in Appendix A. + + 2. MUST: Listen for GRASP M_FLOOD [RFC8990] announcements of the + objective: "AN_Proxy". See Section 4.1.1 for the details of the + objective. The pledge MAY listen concurrently for other sources + of information; see Appendix B. + + Once a proxy is discovered, the pledge communicates with a registrar + through the proxy using the bootstrapping protocol defined in + Section 5. + + While the GRASP M_FLOOD mechanism is passive for the pledge, the non- + normative other methods (mDNS and IPv4 methods) described in + Appendix B are active. The pledge SHOULD run those methods in + parallel with listening for the M_FLOOD. The active methods SHOULD + back off by doubling to a maximum of one hour to avoid overloading + the network with discovery attempts. Detection of physical link + status change (Ethernet carrier, for instance) SHOULD reset the back- + off timers. + + The pledge could discover more than one proxy on a given physical + interface. The pledge can have a multitude of physical interfaces as + well: a Layer 2/3 Ethernet switch may have hundreds of physical + ports. + + Each possible proxy offer SHOULD be attempted up to the point where a + valid voucher is received: while there are many ways in which the + attempt may fail, it does not succeed until the voucher has been + validated. + + The connection attempts via a single proxy SHOULD exponentially back + off to a maximum of one hour to avoid overloading the network + infrastructure. The back-off timer for each MUST be independent of + other connection attempts. + + Connection attempts SHOULD be run in parallel to avoid head-of-queue + problems wherein an attacker running a fake proxy or registrar could + intentionally perform protocol actions slowly. Connection attempts + to different proxies SHOULD be sent with an interval of 3 to 5s. The + pledge SHOULD continue to listen for additional GRASP M_FLOOD + messages during the connection attempts. + + Each connection attempt through a distinct Join Proxy MUST have a + unique nonce in the voucher-request. + + Once a connection to a registrar is established (e.g., establishment + of a TLS session key), there are expectations of more timely + responses; see Section 5.2. + + Once all discovered services are attempted (assuming that none + succeeded), the device MUST return to listening for GRASP M_FLOOD. + It SHOULD periodically retry any manufacturer-specific mechanisms. + The pledge MAY prioritize selection order as appropriate for the + anticipated environment. + +4.1.1. Proxy GRASP Announcements + + A proxy uses the DULL GRASP M_FLOOD mechanism to announce itself. + This announcement can be within the same message as the ACP + announcement detailed in [RFC8994]. + + The formal Concise Data Definition Language (CDDL) [RFC8610] + definition is: + + <CODE BEGINS> file "proxygrasp.cddl" + flood-message = [M_FLOOD, session-id, initiator, ttl, + +[objective, (locator-option / [])]] + + objective = ["AN_Proxy", objective-flags, loop-count, + objective-value] + + ttl = 180000 ; 180,000 ms (3 minutes) + initiator = ACP address to contact registrar + objective-flags = sync-only ; as in the GRASP spec + sync-only = 4 ; M_FLOOD only requires + ; synchronization + loop-count = 1 ; one hop only + objective-value = any ; none + + locator-option = [ O_IPv6_LOCATOR, ipv6-address, + transport-proto, port-number ] + ipv6-address = the v6 LL of the Proxy + $transport-proto /= IPPROTO_TCP ; note that this can be any value + ; from the IANA protocol registry, + ; as per RFC 8990, Section 2.9.5.1, + ; Note 3. + port-number = selected by Proxy + <CODE ENDS> + + Figure 10: CDDL Definition of Proxy Discovery Message + + Here is an example M_FLOOD announcing a proxy at fe80::1, on TCP port + 4443. + + [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000, + [["AN_Proxy", 4, 1, ""], + [O_IPv6_LOCATOR, + h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]]] + + Figure 11: Example of Proxy Discovery Message + + On a small network, the registrar MAY include the GRASP M_FLOOD + announcements to locally connected networks. + + The $transport-proto above indicates the method that the pledge- + proxy-registrar will use. The TCP method described here is + mandatory, and other proxy methods, such as CoAP methods not defined + in this document, are optional. Other methods MUST NOT be enabled + unless the Join Registrar ASA indicates support for them in its own + announcement. + +4.2. CoAP Connection to Registrar + + The use of CoAP to connect from pledge to registrar is out of scope + for this document and is described in future work. See + [ANIMA-CONSTRAINED-VOUCHER]. + +4.3. Proxy Discovery and Communication of Registrar + + The registrar SHOULD announce itself so that proxies can find it and + determine what kind of connections can be terminated. + + The registrar announces itself using GRASP M_FLOOD messages, with the + "AN_join_registrar" objective, within the ACP instance. A registrar + may announce any convenient port number, including use of stock port + 443. ANI proxies MUST support GRASP discovery of registrars. + + The M_FLOOD is formatted as follows: + + [M_FLOOD, 51804321, h'fda379a6f6ee00000200000064000001', 180000, + [["AN_join_registrar", 4, 255, "EST-TLS"], + [O_IPv6_LOCATOR, + h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443]]] + + Figure 12: An Example of a Registrar Announcement Message + + The formal CDDL definition is: + + <CODE BEGINS> file "jrcgrasp.cddl" + flood-message = [M_FLOOD, session-id, initiator, ttl, + +[objective, (locator-option / [])]] + + objective = ["AN_join_registrar", objective-flags, loop-count, + objective-value] + + initiator = ACP address to contact registrar + objective-flags = sync-only ; as in the GRASP spec + sync-only = 4 ; M_FLOOD only requires + ; synchronization + loop-count = 255 ; mandatory maximum + objective-value = text ; name of the (list of) supported + ; protocols: "EST-TLS" for RFC 7030. + <CODE ENDS> + + Figure 13: CDDL Definition for Registrar Announcement Message + + The M_FLOOD message MUST be sent periodically. The default period + SHOULD be 60 seconds, and the value SHOULD be operator configurable + but SHOULD NOT be smaller than 60 seconds. The frequency of sending + MUST be such that the aggregate amount of periodic M_FLOODs from all + flooding sources causes only negligible traffic across the ACP. + + Here are some examples of locators for illustrative purposes. Only + the first one ($transport-protocol = 6, TCP) is defined in this + document and is mandatory to implement. + + locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] + locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] + locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] + + A protocol of 6 indicates that TCP proxying on the indicated port is + desired. + + Registrars MUST announce the set of protocols that they support, and + they MUST support TCP traffic. + + Registrars MUST accept HTTPS/EST traffic on the TCP ports indicated. + + Registrars MUST support the ANI TLS Circuit Proxy and therefore BRSKI + across HTTPS/TLS native across the ACP. + + In the ANI, the ACP-secured instance of GRASP [RFC8990] MUST be used + for discovery of ANI registrar ACP addresses and ports by ANI + proxies. Therefore, the TCP leg of the proxy connection between the + ANI proxy and ANI registrar also runs across the ACP. + +5. Protocol Details (Pledge -- Registrar -- MASA) + + The pledge MUST initiate BRSKI after boot if it is unconfigured. The + pledge MUST NOT automatically initiate BRSKI if it has been + configured or is in the process of being configured. + + BRSKI is described as extensions to EST [RFC7030]. The goal of these + extensions is to reduce the number of TLS connections and crypto + operations required on the pledge. The registrar implements the + BRSKI REST interface within the "/.well-known/brski" URI tree and + implements the existing EST URIs as described in EST [RFC7030], + Section 3.2.2. The communication channel between the pledge and the + registrar is referred to as "BRSKI-EST" (see Figure 1). + + The communication channel between the registrar and MASA is a new + communication channel, similar to EST, within the newly registered + "/.well-known/brski" tree. For clarity, this channel is referred to + as "BRSKI-MASA" (see Figure 1). + + The MASA URI is "https://" authority "/.well-known/brski". + + BRSKI uses existing CMS message formats for existing EST operations. + BRSKI uses JSON [RFC8259] for all new operations defined here and for + voucher formats. In all places where a binary value must be carried + in a JSON string, a base64 format ([RFC4648], Section 4) is to be + used, as per [RFC7951], Section 6.6. + + While EST ([RFC7030], Section 3.2) does not insist upon use of HTTP + persistent connections ([RFC7230], Section 6.3), BRSKI-EST + connections SHOULD use persistent connections. The intention of this + guidance is to ensure the provisional TLS state occurs only once, and + that the subsequent resolution of the provision state is not subject + to a Man-in-the-Middle (MITM) attack during a critical phase. + + If non-persistent connections are used, then both the pledge and the + registrar MUST remember the certificates that have been seen and also + sent for the first connection. They MUST check each subsequent + connection for the same certificates, and each end MUST use the same + certificates as well. This places a difficult restriction on rolling + certificates on the registrar. + + Summarized automation extensions for the BRSKI-EST flow are: + + * The pledge either attempts concurrent connections via each + discovered proxy or times out quickly and tries connections in + series, as explained at the end of Section 5.1. + + * The pledge provisionally accepts the registrar certificate during + the TLS handshake as detailed in Section 5.1. + + * The pledge requests a voucher using the new REST calls described + below. This voucher is then validated. + + * The pledge completes authentication of the server certificate as + detailed in Section 5.6.1. This moves the BRSKI-EST TLS + connection out of the provisional state. + + * Mandatory bootstrap steps conclude with voucher status telemetry + (see Section 5.7). + + The BRSKI-EST TLS connection can now be used for EST enrollment. + + The extensions for a registrar (equivalent to an EST server) are: + + * Client authentication is automated using IDevID as per the EST + certificate-based client authentication. The subject field's DN + encoding MUST include the "serialNumber" attribute with the + device's unique serial number as explained in Section 2.3.1. + + * The registrar requests and validates the voucher from the MASA. + + * The registrar forwards the voucher to the pledge when requested. + + * The registrar performs log verifications (described in + Section 5.8.3) in addition to local authorization checks before + accepting optional pledge device enrollment requests. + +5.1. BRSKI-EST TLS Establishment Details + + The pledge establishes the TLS connection with the registrar through + the Circuit Proxy (see Section 4), but the TLS handshake is with the + registrar. The BRSKI-EST pledge is the TLS client, and the BRSKI-EST + registrar is the TLS server. All security associations established + are between the pledge and the registrar regardless of proxy + operations. + + Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is + REQUIRED on the pledge side. TLS 1.3 (or newer) SHOULD be available + on the registrar server interface, and the registrar client + interface, but TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be + available on the MASA server interface, but TLS 1.2 MAY be used. + + Establishment of the BRSKI-EST TLS connection is as specified in + "Bootstrap Distribution of CA Certificates" (Section 4.1.1) of + [RFC7030], wherein the client is authenticated with the IDevID + certificate, and the EST server (the registrar) is provisionally + authenticated with an unverified server certificate. Configuration + or distribution of the trust anchor database used for validating the + IDevID certificate is out of scope of this specification. Note that + the trust anchors in / excluded from the database will affect which + manufacturers' devices are acceptable to the registrar as pledges and + can also be used to limit the set of MASAs that are trusted for + enrollment. + + The signature in the certificate MUST be validated even if a signing + key cannot (yet) be validated. The certificate (or chain) MUST be + retained for later validation. + + A self-signed certificate for the registrar is acceptable as the + voucher can validate it upon successful enrollment. + + The pledge performs input validation of all data received until a + voucher is verified as specified in Section 5.6.1 and the TLS + connection leaves the provisional state. Until these operations are + complete, the pledge could be communicating with an attacker. + + The pledge code needs to be written with the assumption that all data + is being transmitted at this point to an unauthenticated peer, and + that received data, while inside a TLS connection, MUST be considered + untrusted. This particularly applies to HTTP headers and CMS + structures that make up the voucher. + + A pledge that can connect to multiple registrars concurrently SHOULD + do so. Some devices may be unable to do so for lack of threading, or + resource issues. Concurrent connections defeat attempts by a + malicious proxy from causing a TCP Slowloris-like attack (see + [slowloris]). + + A pledge that cannot maintain as many connections as there are + eligible proxies will need to rotate among the various choices, + terminating connections that do not appear to be making progress. If + no connection is making progress after 5 seconds, then the pledge + SHOULD drop the oldest connection and go on to a different proxy: the + proxy that has been communicated with least recently. If there were + no other proxies discovered, the pledge MAY continue to wait, as long + as it is concurrently listening for new proxy announcements. + +5.2. Pledge Requests Voucher from the Registrar + + When the pledge bootstraps, it makes a request for a voucher from a + registrar. + + This is done with an HTTPS POST using the operation path value of + "/.well-known/brski/requestvoucher". + + The pledge voucher-request Content-Type is as follows. + + application/voucher-cms+json: [RFC8366] defines a "YANG-defined JSON + document that has been signed using a Cryptographic Message Syntax + (CMS) structure", and the voucher-request described in Section 3 + is created in the same way. The media type is the same as defined + in [RFC8366]. This is also used for the pledge voucher-request. + The pledge MUST sign the request using the credentials in + Section 2.3. + + Registrar implementations SHOULD anticipate future media types but, + of course, will simply fail the request if those types are not yet + known. + + The pledge SHOULD include an "Accept" header field (see [RFC7231], + Section 5.3.2) indicating the acceptable media type for the voucher + response. The "application/voucher-cms+json" media type is defined + in [RFC8366], but constrained voucher formats are expected in the + future. Registrars and MASA are expected to be flexible in what they + accept. + + The pledge populates the voucher-request fields as follows: + + created-on: Pledges that have a real-time clock are RECOMMENDED to + populate this field with the current date and time in yang:date- + and-time format. This provides additional information to the + MASA. Pledges that have no real-time clocks MAY omit this field. + + nonce: The pledge voucher-request MUST contain a cryptographically + strong random or pseudo-random number nonce (see [RFC4086], + Section 6.2). As the nonce is usually generated very early in the + boot sequence, there is a concern that the same nonce might be + generated across multiple boots, or after a factory reset. + Different nonces MUST be generated for each bootstrapping attempt, + whether in series or concurrently. The freshness of this nonce + mitigates against the lack of a real-time clock as explained in + Section 2.6.1. + + assertion: The pledge indicates support for the mechanism described + in this document, by putting the value "proximity" in the voucher- + request, and MUST include the proximity-registrar-cert field + (below). + + proximity-registrar-cert: In a pledge voucher-request, this is the + first certificate in the TLS server "certificate_list" sequence + (see [RFC8446], Section 4.4.2) presented by the registrar to the + pledge. That is, it is the end-entity certificate. This MUST be + populated in a pledge voucher-request. + + serial-number: The serial number of the pledge is included in the + voucher-request from the pledge. This value is included as a + sanity check only, but it is not to be forwarded by the registrar + as described in Section 5.5. + + All other fields MAY be omitted in the pledge voucher-request. + + See an example JSON payload of a pledge voucher-request in + Section 3.3, Example 1. + + The registrar confirms that the assertion is "proximity" and that + pinned proximity-registrar-cert is the registrar's certificate. If + this validation fails, then there is an on-path attacker (MITM), and + the connection MUST be closed after the returning of an HTTP 401 + error code. + +5.3. Registrar Authorization of Pledge + + In a fully automated network, all devices must be securely identified + and authorized to join the domain. + + A registrar accepts or declines a request to join the domain, based + on the authenticated identity presented. For different networks, + examples of automated acceptance may include the allowance of: + + * any device of a specific type (as determined by the X.509 IDevID), + + * any device from a specific vendor (as determined by the X.509 + IDevID), + + * a specific device from a vendor (as determined by the X.509 + IDevID) against a domain acceptlist. (The mechanism for checking + a shared acceptlist potentially used by multiple registrars is out + of scope.) + + If validation fails, the registrar SHOULD respond with the HTTP 404 + error code. If the voucher-request is in an unknown format, then an + HTTP 406 error code is more appropriate. A situation that could be + resolved with administrative action (such as adding a vendor to an + acceptlist) MAY be responded to with a 403 HTTP error code. + + If authorization is successful, the registrar obtains a voucher from + the MASA service (see Section 5.5) and returns that MASA-signed + voucher to the pledge as described in Section 5.6. + +5.4. BRSKI-MASA TLS Establishment Details + + The BRSKI-MASA TLS connection is a "normal" TLS connection + appropriate for HTTPS REST interfaces. The registrar initiates the + connection and uses the MASA URL that is obtained as described in + Section 2.8. The mechanisms in [RFC6125] SHOULD be used in + authentication of the MASA using a DNS-ID that matches that which is + found in the IDevID. Registrars MAY include a mechanism to override + the MASA URL on a manufacturer-by-manufacturer basis, and within that + override, it is appropriate to provide alternate anchors. This will + typically be used by some vendors to establish explicit (or private) + trust anchors for validating their MASA that is part of a sales + channel integration. + + Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is + REQUIRED. TLS 1.3 (or newer) SHOULD be available. + + As described in [RFC7030], the MASA and the registrars SHOULD be + prepared to support TLS Client Certificate authentication and/or HTTP + Basic, Digest, or Salted Challenge Response Authentication Mechanism + (SCRAM) authentication. This connection MAY also have no client + authentication at all. + + Registrars SHOULD permit trust anchors to be preconfigured on a per- + vendor (MASA) basis. Registrars SHOULD include the ability to + configure a TLS Client Certificate on a per-MASA basis, or to use no + Client Certificate. Registrars SHOULD also permit HTTP Basic and + Digest authentication to be configured. + + The authentication of the BRSKI-MASA connection does not change the + voucher-request process, as voucher-requests are already signed by + the registrar. Instead, this authentication provides access control + to the audit-log as described in Section 5.8. + + Implementers are advised that contacting the MASA establishes a + secured API connection with a web service, and that there are a + number of authentication models being explored within the industry. + Registrars are RECOMMENDED to fail gracefully and generate useful + administrative notifications or logs in the advent of unexpected HTTP + 401 (Unauthorized) responses from the MASA. + +5.4.1. MASA Authentication of Customer Registrar + + Providing per-customer options requires the customer's registrar to + be uniquely identified. This can be done by any stateless method + that HTTPS supports such as HTTP Basic or Digest authentication (that + is using a password), but the use of TLS Client Certificate + authentication is RECOMMENDED. + + Stateful methods involving API tokens, or HTTP Cookies, are not + recommended. + + It is expected that the setup and configuration of per-customer + Client Certificates is done as part of a sales ordering process. + + The use of public PKI (i.e., WebPKI) end-entity certificates to + identify the registrar is reasonable, and if done universally, this + would permit a MASA to identify a customer's registrar simply by a + Fully Qualified Domain Name (FQDN). + + The use of DANE records in DNSSEC-signed zones would also permit use + of a FQDN to identify customer registrars. + + A third (and simplest, but least flexible) mechanism would be for the + MASA to simply store the registrar's certificate pinned in a + database. + + A MASA without any supply-chain integration can simply accept + registrars without any authentication or on a blind TOFU basis as + described in Section 7.4.2. + + This document does not make a specific recommendation on how the MASA + authenticates the registrar as there are likely different tradeoffs + in different environments and product values. Even within the ANIMA + ACP applicability, there is a significant difference between supply- + chain logistics for $100 CPE devices and $100,000 core routers. + +5.5. Registrar Requests Voucher from MASA + + When a registrar receives a pledge voucher-request, it in turn + submits a registrar voucher-request to the MASA service via an HTTPS + interface [RFC7231]. + + This is done with an HTTP POST using the operation path value of + "/.well-known/brski/requestvoucher". + + The voucher media type "application/voucher-cms+json" is defined in + [RFC8366] and is also used for the registrar voucher-request. It is + a JSON document that has been signed using a CMS structure. The + registrar MUST sign the registrar voucher-request. + + MASA implementations SHOULD anticipate future media ntypes but, of + course, will simply fail the request if those types are not yet + known. + + The voucher-request CMS object includes some number of certificates + that are input to the MASA as it populates the pinned-domain-cert. + As [RFC8366] is quite flexible in what may be put into the pinned- + domain-cert, the MASA needs some signal as to what certificate would + be effective to populate the field with: it may range from the end- + entity certificate that the registrar uses to the entire private + Enterprise CA certificate. More-specific certificates result in a + tighter binding of the voucher to the domain, while less-specific + certificates result in more flexibility in how the domain is + represented by certificates. + + A registrar that is seeking a nonceless voucher for later offline use + benefits from a less-specific certificate, as it permits the actual + key pair used by a future registrar to be determined by the pinned + CA. + + In some cases, a less-specific certificate, such as a public WebPKI + CA, could be too open and could permit any entity issued a + certificate by that authority to assume ownership of a device that + has a voucher pinned. Future work may provide a solution to pin both + a certificate and a name that would reduce such risk of malicious + ownership assertions. + + The registrar SHOULD request a voucher with the most specificity + consistent with the mode that it is operating in. In order to do + this, when the registrar prepares the CMS structure for the signed + voucher-request, it SHOULD include only certificates that are a part + of the chain that it wishes the MASA to pin. This MAY be as small as + only the end-entity certificate (with id-kp-cmcRA set) that it uses + as its TLS server certificate, or it MAY be the entire chain, + including the domain CA. + + The registrar SHOULD include an "Accept" header field (see [RFC7231], + Section 5.3.2) indicating the response media types that are + acceptable. This list SHOULD be the entire list presented to the + registrar in the pledge's original request (see Section 5.2), but it + MAY be a subset. The MASA is expected to be flexible in what it + accepts. + + The registrar populates the voucher-request fields as follows: + + created-on: The registrar SHOULD populate this field with the + current date and time when the voucher-request is formed. This + field provides additional information to the MASA. + + nonce: This value, if present, is copied from the pledge voucher- + request. The registrar voucher-request MAY omit the nonce as per + Section 3.1. + + serial-number: The serial number of the pledge the registrar would + like a voucher for. The registrar determines this value by + parsing the authenticated pledge IDevID certificate; see + Section 2.3. The registrar MUST verify that the serial-number + field it parsed matches the serial-number field the pledge + provided in its voucher-request. This provides a sanity check + useful for detecting error conditions and logging. The registrar + MUST NOT simply copy the serial-number field from a pledge + voucher-request as that field is claimed but not certified. + + idevid-issuer: The Issuer value from the pledge IDevID certificate + is included to ensure unique interpretation of the serial-number. + In the case of a nonceless (offline) voucher-request, an + appropriate value needs to be configured from the same out-of-band + source as the serial-number. + + prior-signed-voucher-request: The signed pledge voucher-request + SHOULD be included in the registrar voucher-request. The entire + CMS-signed structure is to be included and base64 encoded for + transport in the JSON structure. + + A nonceless registrar voucher-request MAY be submitted to the MASA. + Doing so allows the registrar to request a voucher when the pledge is + offline, or when the registrar anticipates not being able to connect + to the MASA while the pledge is being deployed. Some use cases + require the registrar to learn the appropriate IDevID serialNumber + field and appropriate "Accept" header field values from the physical + device labeling or from the sales channel (which is out of scope for + this document). + + All other fields MAY be omitted in the registrar voucher-request. + + The proximity-registrar-cert field MUST NOT be present in the + registrar voucher-request. + + See example JSON payloads of registrar voucher-requests in + Section 3.3, Examples 2 through 4. + + The MASA verifies that the registrar voucher-request is internally + consistent but does not necessarily authenticate the registrar + certificate since the registrar MAY be unknown to the MASA in + advance. The MASA performs the actions and validation checks + described in the following subsections before issuing a voucher. + +5.5.1. MASA Renewal of Expired Vouchers + + As described in [RFC8366], vouchers are normally short lived to avoid + revocation issues. If the request is for a previous (expired) + voucher using the same registrar (that is, a registrar with the same + domain CA), then the request for a renewed voucher SHOULD be + automatically authorized. The MASA has sufficient information to + determine this by examining the request, the registrar + authentication, and the existing audit-log. The issuance of a + renewed voucher is logged as detailed in Section 5.6. + + To inform the MASA that existing vouchers are not to be renewed, one + can update or revoke the registrar credentials used to authorize the + request (see Sections 5.5.4 and 5.5.3). More flexible methods will + likely involve sales channel integration and authorizations (details + are out of scope of this document). + +5.5.2. MASA Pinning of Registrar + + A certificate chain is extracted from the registrar's signed CMS + container. This chain may be as short as a single end-entity + certificate, up to the entire registrar certificate chain, including + the domain CA certificate, as specified in Section 5.5. + + If the domain's CA is unknown to the MASA, then it is considered a + temporary trust anchor for the rest of the steps in this section. + The intention is not to authenticate the message as having come from + a fully validated origin but to establish the consistency of the + domain PKI. + + The MASA MAY use the certificate in the chain that is farthest from + the end-entity certificate of the registrar, as determined by MASA + policy. A MASA MAY have a local policy in which it only pins the + end-entity certificate. This is consistent with [RFC8366]. Details + of the policy will typically depend upon the degree of supply-chain + integration and the mechanism used by the registrar to authenticate. + Such a policy would also determine how the MASA will respond to a + request for a nonceless voucher. + +5.5.3. MASA Check of the Voucher-Request Signature + + As described in Section 5.5.2, the MASA has extracted the registrar's + domain CA. This is used to validate the CMS signature [RFC5652] on + the voucher-request. + + Normal PKIX revocation checking is assumed during voucher-request + signature validation. This CA certificate MAY have Certificate + Revocation List (CRL) distribution points or Online Certificate + Status Protocol (OCSP) information [RFC6960]. If they are present, + the MASA MUST be able to reach the relevant servers belonging to the + registrar's domain CA to perform the revocation checks. + + The use of OCSP Stapling is preferred. + +5.5.4. MASA Verification of the Domain Registrar + + The MASA MUST verify that the registrar voucher-request is signed by + a registrar. This is confirmed by verifying that the id-kp-cmcRA + extended key usage extension field (as detailed in EST [RFC7030], + Section 3.6.1) exists in the certificate of the entity that signed + the registrar voucher-request. This verification is only a + consistency check to ensure that the unauthenticated domain CA + intended the voucher-request signer to be a registrar. Performing + this check provides value to the domain PKI by assuring the domain + administrator that the MASA service will only respect claims from + authorized registration authorities of the domain. + + Even when a domain CA is authenticated to the MASA, and there is + strong sales channel integration to understand who the legitimate + owner is, the above id-kp-cmcRA check prevents arbitrary end-entity + certificates (such as an LDevID certificate) from having vouchers + issued against them. + + Other cases of inappropriate voucher issuance are detected by + examination of the audit-log. + + If a nonceless voucher-request is submitted, the MASA MUST + authenticate the registrar either as described in EST (see Sections + 3.2.3 and 3.3.2 of [RFC7030]) or by validating the registrar's + certificate used to sign the registrar voucher-request using a + configured trust anchor. Any of these methods reduce the risk of + DDoS attacks and provide an authenticated identity as an input to + sales channel integration and authorizations (details are out of + scope of this document). + + In the nonced case, validation of the registrar's identity (via TLS + Client Certificate or HTTP authentication) MAY be omitted if the MASA + knows that the device policy is to accept audit-only vouchers. + +5.5.5. MASA Verification of the Pledge 'prior-signed-voucher-request' + + The MASA MAY verify that the registrar voucher-request includes the + prior-signed-voucher-request field. If so, the prior-signed-voucher- + request MUST include a proximity-registrar-cert that is consistent + with the certificate used to sign the registrar voucher-request. + Additionally, the voucher-request serial-number leaf MUST match the + pledge serial-number that the MASA extracts from the signing + certificate of the prior-signed-voucher-request. The consistency + check described above entails checking that the proximity-registrar- + cert Subject Public Key Info (SPKI) Fingerprint exists within the + registrar voucher-request CMS signature's certificate chain. This is + substantially the same as the pin validation described in [RFC7469], + Section 2.6. + + If these checks succeed, the MASA updates the voucher and audit-log + assertion leafs with the "proximity" assertion, as defined by + [RFC8366], Section 5.3. + +5.5.6. MASA Nonce Handling + + The MASA does not verify the nonce itself. If the registrar voucher- + request contains a nonce, and the prior-signed-voucher-request + exists, then the MASA MUST verify that the nonce is consistent. + (Recall from above that the voucher-request might not contain a + nonce; see Sections 5.5 and 5.5.4.) + + The MASA populates the audit-log with the nonce that was verified. + If a nonceless voucher is issued, then the audit-log is to be + populated with the JSON value "null". + +5.6. MASA and Registrar Voucher Response + + The MASA voucher response to the registrar is forwarded without + changes to the pledge; therefore, this section applies to both the + MASA and the registrar. The HTTP signaling described applies to both + the MASA and registrar responses. + + When a voucher-request arrives at the registrar, if it has a cached + response from the MASA for the corresponding registrar voucher- + request, that cached response can be used according to local policy; + otherwise, the registrar constructs a new registrar voucher-request + and sends it to the MASA. + + Registrar evaluation of the voucher itself is purely for transparency + and audit purposes to further inform log verification (see + Section 5.8.3); therefore, a registrar could accept future voucher + formats that are opaque to the registrar. + + If the voucher-request is successful, the server (a MASA responding + to a registrar or a registrar responding to a pledge) response MUST + contain an HTTP 200 response code. The server MUST answer with a + suitable 4xx or 5xx HTTP [RFC7230] error code when a problem occurs. + In this case, the response data from the MASA MUST be a plain text + human-readable (UTF-8) error message containing explanatory + information describing why the request was rejected. + + The registrar MAY respond with an HTTP 202 ("the request has been + accepted for processing, but the processing has not been completed") + as described in EST [RFC7030], Section 4.2.3, wherein the client + "MUST wait at least the specified "retry-after" time before repeating + the same request" (also see [RFC7231], Section 6.6.4). The pledge is + RECOMMENDED to provide local feedback (blinked LED, etc.) during this + wait cycle if mechanisms for this are available. To prevent an + attacker registrar from significantly delaying bootstrapping, the + pledge MUST limit the Retry-After time to 60 seconds. Ideally, the + pledge would keep track of the appropriate Retry-After header field + values for any number of outstanding registrars, but this would + involve a state table on the pledge. Instead, the pledge MAY ignore + the exact Retry-After value in favor of a single hard-coded value (a + registrar that is unable to complete the transaction after the first + 60 seconds has another chance a minute later). A pledge SHOULD be + willing to maintain a 202 retry-state for up to 4 days, which is + longer than a long weekend, after which time the enrollment attempt + fails, and the pledge returns to Discovery state. This allows time + for an alert to get from the registrar to a human operator who can + make a decision as to whether or not to proceed with the enrollment. + + A pledge that retries a request after receiving a 202 message MUST + resend the same voucher-request. It MUST NOT sign a new voucher- + request each time, and in particular, it MUST NOT change the nonce + value. + + In order to avoid infinite redirect loops, which a malicious + registrar might do in order to keep the pledge from discovering the + correct registrar, the pledge MUST NOT follow more than one + redirection (3xx code) to another web origin. EST supports + redirection but requires user input; this change allows the pledge to + follow a single redirection without a user interaction. + + A 403 (Forbidden) response is appropriate if the voucher-request is + not signed correctly or is stale or if the pledge has another + outstanding voucher that cannot be overridden. + + A 404 (Not Found) response is appropriate when the request is for a + device that is not known to the MASA. + + A 406 (Not Acceptable) response is appropriate if a voucher of the + desired type or that uses the desired algorithms (as indicated by the + "Accept" header fields and algorithms used in the signature) cannot + be issued as such because the MASA knows the pledge cannot process + that type. The registrar SHOULD use this response if it determines + the pledge is unacceptable due to inventory control, MASA audit-logs, + or any other reason. + + A 415 (Unsupported Media Type) response is appropriate for a request + that has a voucher-request or "Accept" value that is not understood. + + The voucher response format is as indicated in the submitted "Accept" + header fields or based on the MASA's prior understanding of proper + format for this pledge. Only the "application/voucher-cms+json" + media type [RFC8366] is defined at this time. The syntactic details + of vouchers are described in detail in [RFC8366]. Figure 14 shows a + sample of the contents of a voucher. + + { + "ietf-voucher:voucher": { + "nonce": "62a2e7693d82fcda2624de58fb6722e5", + "assertion": "logged", + "pinned-domain-cert": "base64encodedvalue==", + "serial-number": "JADA123456789" + } + } + + Figure 14: An Example Voucher + + The MASA populates the voucher fields as follows: + + nonce: The nonce from the pledge if available. See Section 5.5.6. + + assertion: The method used to verify the relationship between the + pledge and registrar. See Section 5.5.5. + + pinned-domain-cert: A certificate; see Section 5.5.2. This figure + is illustrative; for an example, see Appendix C.2 where an end- + entity certificate is used. + + serial-number: The serial-number as provided in the voucher-request. + Also see Section 5.5.5. + + domain-cert-revocation-checks: Set as appropriate for the pledge's + capabilities and as documented in [RFC8366]. The MASA MAY set + this field to "false" since setting it to "true" would require + that revocation information be available to the pledge, and this + document does not make normative requirements for [RFC6961], + Section 4.4.2.1 of [RFC8446], or equivalent integrations. + + expires-on: This is set for nonceless vouchers. The MASA ensures + the voucher lifetime is consistent with any revocation or pinned- + domain-cert consistency checks the pledge might perform. See + Section 2.6.1. There are three times to consider: (a) a + configured voucher lifetime in the MASA, (b) the expiry time for + the registrar's certificate, and (c) any CRL lifetime. The + expires-on field SHOULD be before the earliest of these three + values. Typically, (b) will be some significant time in the + future, but (c) will typically be short (on the order of a week or + less). The RECOMMENDED period for (a) is on the order of 20 + minutes, so it will typically determine the life span of the + resulting voucher. 20 minutes is sufficient time to reach the + post-provisional state in the pledge, at which point there is an + established trust relationship between the pledge and registrar. + The subsequent operations can take as long as required from that + point onwards. The lifetime of the voucher has no impact on the + life span of the ownership relationship. + + Whenever a voucher is issued, the MASA MUST update the audit-log + sufficiently to generate the response as described in Section 5.8.1. + The internal state requirements to maintain the audit-log are out of + scope. + +5.6.1. Pledge Voucher Verification + + The pledge MUST verify the voucher signature using the manufacturer- + installed trust anchor(s) associated with the manufacturer's MASA + (this is likely included in the pledge's firmware). Management of + the manufacturer-installed trust anchor(s) is out of scope of this + document; this protocol does not update this trust anchor(s). + + The pledge MUST verify that the serial-number field of the signed + voucher matches the pledge's own serial-number. + + The pledge MUST verify the nonce information in the voucher. If + present, the nonce in the voucher must match the nonce the pledge + submitted to the registrar; vouchers with no nonce can also be + accepted (according to local policy; see Section 7.2). + + The pledge MUST be prepared to parse and fail gracefully from a + voucher response that does not contain a pinned-domain-cert field. + Such a thing indicates a failure to enroll in this domain, and the + pledge MUST attempt joining with other available Join Proxies. + + The pledge MUST be prepared to ignore additional fields that it does + not recognize. + +5.6.2. Pledge Authentication of Provisional TLS Connection + + Following the process described in [RFC8366], the pledge should + consider the public key from the pinned-domain-cert as the sole + temporary trust anchor. + + The pledge then evaluates the TLS server certificate chain that it + received when the TLS connection was formed using this trust anchor. + It is possible that the public key in the pinned-domain-cert directly + matches the public key in the end-entity certificate provided by the + TLS server. + + If a registrar's credentials cannot be verified using the pinned- + domain-cert trust anchor from the voucher, then the TLS connection is + discarded, and the pledge abandons attempts to bootstrap with this + discovered registrar. The pledge SHOULD send voucher status + telemetry (described below) before closing the TLS connection. The + pledge MUST attempt to enroll using any other proxies it has found. + It SHOULD return to the same proxy again after unsuccessful attempts + with other proxies. Attempts should be made at repeated intervals + according to the back-off timer described earlier. Attempts SHOULD + be repeated as failure may be the result of a temporary inconsistency + (an inconsistently rolled registrar key, or some other + misconfiguration). The inconsistency could also be the result of an + active MITM attack on the EST connection. + + The registrar MUST use a certificate that chains to the pinned- + domain-cert as its TLS server certificate. + + The pledge's PKIX path validation of a registrar certificate's + validity period information is as described in Section 2.6.1. Once + the PKIX path validation is successful, the TLS connection is no + longer provisional. + + The pinned-domain-cert MAY be installed as a trust anchor for future + operations such as enrollment (e.g., as recommended per [RFC7030]) or + trust anchor management or raw protocols that do not need full PKI- + based key management. It can be used to authenticate any dynamically + discovered EST server that contains the id-kp-cmcRA extended key + usage extension as detailed in EST (see [RFC7030], Section 3.6.1); + but to reduce system complexity, the pledge SHOULD avoid additional + discovery operations. Instead, the pledge SHOULD communicate + directly with the registrar as the EST server. The pinned-domain- + cert is not a complete distribution of the CA certificate response, + as described in [RFC7030], Section 4.1.3, which is an additional + justification for the recommendation to proceed with EST key + management operations. Once a full CA certificate response is + obtained, it is more authoritative for the domain than the limited + pinned-domain-cert response. + +5.7. Pledge BRSKI Status Telemetry + + The domain is expected to provide indications to the system + administrators concerning device life-cycle status. To facilitate + this, it needs telemetry information concerning the device's status. + + The pledge MUST indicate its pledge status regarding the voucher. It + does this by sending a status message to the registrar. + + The posted data media type: application/json + + The client sends an HTTP POST to the server at the URI ".well- + known/brski/voucher_status". + + The format and semantics described below are for version 1. A + version field is included to permit significant changes to this + feedback in the future. A registrar that receives a status message + with a version larger than it knows about SHOULD log the contents and + alert a human. + + The status field indicates if the voucher was acceptable. Boolean + values are acceptable, where "true" indicates the voucher was + acceptable. + + If the voucher was not acceptable, the Reason string indicates why. + In a failure case, this message may be sent to an unauthenticated, + potentially malicious registrar; therefore, the Reason string SHOULD + NOT provide information beneficial to an attacker. The operational + benefit of this telemetry information is balanced against the + operational costs of not recording that a voucher was ignored by a + client that the registrar expected was going to continue joining the + domain. + + The reason-context attribute is an arbitrary JSON object (literal + value or hash of values) that provides additional information + specific to this pledge. The contents of this field are not subject + to standardization. + + The version and status fields MUST be present. The Reason field + SHOULD be present whenever the status field is false. The Reason- + Context field is optional. In the case of a SUCCESS, the Reason + string MAY be omitted. + + The keys to this JSON object are case sensitive and MUST be + lowercase. Figure 16 shows an example JSON. + + <CODE BEGINS> file "voucherstatus.cddl" + voucherstatus-post = { + "version": uint, + "status": bool, + ? "reason": text, + ? "reason-context" : { $$arbitrary-map } + } + } + <CODE ENDS> + + Figure 15: CDDL for Voucher Status POST + + { + "version": 1, + "status":false, + "reason":"Informative human-readable message", + "reason-context": { "additional" : "JSON" } + } + + Figure 16: Example Status Telemetry + + The server SHOULD respond with an HTTP 200 but MAY simply fail with + an HTTP 404 error. The client ignores any response. The server + SHOULD capture this telemetry information within the server logs. + + Additional standard JSON fields in this POST MAY be added; see + Section 8.5. A server that sees unknown fields should log them, but + otherwise ignore them. + +5.8. Registrar Audit-Log Request + + After receiving the pledge status telemetry (see Section 5.7), the + registrar SHOULD request the MASA audit-log from the MASA service. + + This is done with an HTTP POST using the operation path value of + "/.well-known/brski/requestauditlog". + + The registrar SHOULD HTTP POST the same registrar voucher-request as + it did when requesting a voucher (using the same Content-Type). It + is posted to the /requestauditlog URI instead. The idevid-issuer and + serial-number informs the MASA which log is requested, so the + appropriate log can be prepared for the response. Using the same + media type and message minimizes cryptographic and message + operations, although it results in additional network traffic. The + relying MASA implementation MAY leverage internal state to associate + this request with the original, and by now already validated, + voucher-request so as to avoid an extra crypto validation. + + A registrar MAY request logs at future times. If the registrar + generates a new request, then the MASA is forced to perform the + additional cryptographic operations to verify the new request. + + A MASA that receives a request for a device that does not exist, or + for which the requesting owner was never an owner, returns an HTTP + 404 ("Not found") code. + + It is reasonable for a registrar, that the MASA does not believe to + be the current owner, to request the audit-log. There are probably + reasons for this, which are hard to predict in advance. For + instance, such a registrar may not be aware that the device has been + resold; it may be that the device has been resold inappropriately, + and this is how the original owner will learn of the occurrence. It + is also possible that the device legitimately spends time in two + different networks. + + Rather than returning the audit-log as a response to the POST (with a + return code 200), the MASA MAY instead return a 201 ("Created") + response ([RFC7231], Sections 6.3.2 and 7.1), with the URL to the + prepared (and idempotent, therefore cachable) audit response in the + "Location" header field. + + In order to avoid enumeration of device audit-logs, a MASA that + returns URLs SHOULD take care to make the returned URL unguessable. + [W3C.capability-urls] provides very good additional guidance. For + instance, rather than returning URLs containing a database number + such as https://example.com/auditlog/1234 or the Extended Unique + Identifier (EUI) of the device such https://example.com/ + auditlog/10-00-00-11-22-33, the MASA SHOULD return a randomly + generated value (a "slug" in web parlance). The value is used to + find the relevant database entry. + + A MASA that returns a code 200 MAY also include a "Location" header + for future reference by the registrar. + +5.8.1. MASA Audit-Log Response + + A log data file is returned consisting of all log entries associated + with the device selected by the IDevID presented in the request. The + audit-log may be abridged by removal of old or repeated values as + explained below. The returned data is in JSON format [RFC8259], and + the Content-Type SHOULD be "application/json". + + The following CDDL [RFC8610] explains the structure of the JSON + format audit-log response: + + <CODE BEGINS> file "auditlog.cddl" + audit-log-response = { + "version": uint, + "events": [ + event ] + "truncation": { + ? "nonced duplicates": uint, + ? "nonceless duplicates": uint, + ? "arbitrary": uint, + } + } + + event = { + "date": text, + "domainID": text, + "nonce": text / null, + "assertion": "verified" / "logged" / "proximity", + ? "truncated": uint, + } + <CODE ENDS> + + Figure 17: CDDL for Audit-Log Response + + An example: + + { + "version":"1", + "events":[ + { + "date":"2019-05-15T17:25:55.644-04:00", + "domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=", + "nonce":"VOUFT-WwrEv0NuAQEHoV7Q", + "assertion":"proximity", + "truncated":"0" + }, + { + "date":"2017-05-15T17:25:55.644-04:00", + "domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=", + "nonce":"f4G6Vi1t8nKo/FieCVgpBg==", + "assertion":"proximity" + } + ], + "truncation": { + "nonced duplicates": "0", + "nonceless duplicates": "1", + "arbitrary": "2" + } + } + + Figure 18: Example of an Audit-Log Response + + The domainID is a binary SubjectKeyIdentifier value calculated + according to Section 5.8.2. It is encoded once in base64 in order to + be transported in this JSON container. + + The date is formatted per [RFC3339], which is consistent with typical + JavaScript usage of JSON. + + The truncation structure MAY be omitted if all values are zero. Any + counter missing from the truncation structure is assumed to be zero. + + The nonce is a string, as provided in the voucher-request, and is + used in the voucher. If no nonce was placed in the resulting + voucher, then a value of null SHOULD be used in preference to + omitting the entry. While the nonce is often created as a + base64-encoded random series of bytes, this should not be assumed. + + Distribution of a large log is less than ideal. This structure can + be optimized as follows: nonced or nonceless entries for the same + domainID MAY be abridged from the log leaving only the single most + recent nonced or nonceless entry for that domainID. In the case of + truncation, the "event" truncation value SHOULD contain a count of + the number of events for this domainID that were omitted. The log + SHOULD NOT be further reduced, but an operational situation could + exist where maintaining the full log is not possible. In such + situations, the log MAY be arbitrarily abridged for length, with the + number of removed entries indicated as "arbitrary". + + If the truncation count exceeds 1024, then the MASA MAY use this + value without further incrementing it. + + A log where duplicate entries for the same domain have been omitted + ("nonced duplicates" and/or "nonceless duplicates") could still be + acceptable for informed decisions. A log that has had "arbitrary" + truncations is less acceptable, but manufacturer transparency is + better than hidden truncations. + + A registrar that sees a version value greater than 1 indicates an + audit-log format that has been enhanced with additional information. + No information will be removed in future versions; should an + incompatible change be desired in the future, then a new HTTP + endpoint will be used. + + This document specifies a simple log format as provided by the MASA + service to the registrar. This format could be improved by + distributed consensus technologies that integrate vouchers with + technologies such as block-chain or hash trees or optimized logging + approaches. Doing so is out of the scope of this document but is an + anticipated improvement for future work. As such, the registrar + SHOULD anticipate new kinds of responses and SHOULD provide operator + controls to indicate how to process unknown responses. + +5.8.2. Calculation of domainID + + The domainID is a binary value (a BIT STRING) that uniquely + identifies a registrar by the pinned-domain-cert. + + If the pinned-domain-cert certificate includes the + SubjectKeyIdentifier ([RFC5280], Section 4.2.1.2), then it is used as + the domainID. If not, the SPKI Fingerprint as described in + [RFC7469], Section 2.4 is used. This value needs to be calculated by + both the MASA (to populate the audit-log) and the registrar (to + recognize itself in the audit-log). + + [RFC5280], Section 4.2.1.2 does not mandate that the + SubjectKeyIdentifier extension be present in non-CA certificates. It + is RECOMMENDED that registrar certificates (even if self-signed) + always include the SubjectKeyIdentifier to be used as a domainID. + + The domainID is determined from the certificate chain associated with + the pinned-domain-cert and is used to update the audit-log. + +5.8.3. Registrar Audit-Log Verification + + Each time the MASA issues a voucher, it appends details of the + assignment to an internal audit-log for that device. The internal + audit-log is processed when responding to requests for details as + described in Section 5.8. The contents of the audit-log can express + a variety of trust levels, and this section explains what kind of + trust a registrar can derive from the entries. + + While the audit-log provides a list of vouchers that were issued by + the MASA, the vouchers are issued in response to voucher-requests, + and it is the content of the voucher-requests that determines how + meaningful the audit-log entries are. + + A registrar SHOULD use the log information to make an informed + decision regarding the continued bootstrapping of the pledge. The + exact policy is out of scope of this document as it depends on the + security requirements within the registrar domain. Equipment that is + purchased preowned can be expected to have an extensive history. The + following discussion is provided to help explain the value of each + log element: + + date: The date field provides the registrar an opportunity to divide + the log around known events such as the purchase date. Depending + on the context known to the registrar or administrator, events + before/after certain dates can have different levels of + importance. For example, for equipment that is expected to be + new, and thus has no history, it would be a surprise to find prior + entries. + + domainID: If the log includes an unexpected domainID, then the + pledge could have imprinted on an unexpected domain. The + registrar can be expected to use a variety of techniques to define + "unexpected" ranging from acceptlists of prior domains to anomaly + detection (e.g., "this device was previously bound to a different + domain than any other device deployed"). Log entries can also be + compared against local history logs in search of discrepancies + (e.g., "this device was re-deployed some number of times + internally, but the external audit-log shows additional re- + deployments our internal logs are unaware of"). + + nonce: Nonceless entries mean the logged domainID could + theoretically trigger a reset of the pledge and then take over + management by using the existing nonceless voucher. + + assertion: The assertion leaf in the voucher and audit-log indicates + why the MASA issued the voucher. A "verified" entry means that + the MASA issued the associated voucher as a result of positive + verification of ownership. However, this entry does not indicate + whether or not the pledge was actually deployed in the prior + domain. A "logged" assertion informs the registrar that the prior + vouchers were issued with minimal verification. A "proximity" + assertion assures the registrar that the pledge was truly + communicating with the prior domain and thus provides assurance + that the prior domain really has deployed the pledge. + + A relatively simple policy is to acceptlist known (internal or + external) domainIDs and require all vouchers to have a nonce. An + alternative is to require that all nonceless vouchers be from a + subset (e.g., only internal) of domainIDs. If the policy is + violated, a simple action is to revoke any locally issued credentials + for the pledge in question or to refuse to forward the voucher. The + registrar MUST then refuse any EST actions and SHOULD inform a human + via a log. A registrar MAY be configured to ignore (i.e., override + the above policy) the history of the device, but it is RECOMMENDED + that this only be configured if hardware-assisted (i.e., Transport + Performance Metrics (TPM) anchored) Network Endpoint Assessment (NEA) + [RFC5209] is supported. + +5.9. EST Integration for PKI Bootstrapping + + The pledge SHOULD follow the BRSKI operations with EST enrollment + operations including "CA Certificates Request", "CSR Attributes + Request", and "Client Certificate Request" or "Server-Side Key + Generation", etc. This is a relatively seamless integration since + BRSKI API calls provide an automated alternative to the manual + bootstrapping method described in [RFC7030]. As noted above, use of + HTTP-persistent connections simplifies the pledge state machine. + + Although EST allows clients to obtain multiple certificates by + sending multiple Certificate Signing Requests (CSRs), BRSKI does not + support this mechanism directly. This is because BRSKI pledges MUST + use the CSR Attributes request ([RFC7030], Section 4.5). The + registrar MUST validate the CSR against the expected attributes. + This implies that client requests will "look the same" and therefore + result in a single logical certificate being issued even if the + client were to make multiple requests. Registrars MAY contain more + complex logic, but doing so is out of scope of this specification. + BRSKI does not signal any enhancement or restriction to this + capability. + +5.9.1. EST Distribution of CA Certificates + + The pledge SHOULD request the full EST Distribution of CA certificate + messages; see [RFC7030], Section 4.1. + + This ensures that the pledge has the complete set of current CA + certificates beyond the pinned-domain-cert (see Section 5.6.2 for a + discussion of the limitations inherent in having a single certificate + instead of a full CA certificate response). Although these + limitations are acceptable during initial bootstrapping, they are not + appropriate for ongoing PKIX end-entity certificate validation. + +5.9.2. EST CSR Attributes + + Automated bootstrapping occurs without local administrative + configuration of the pledge. In some deployments, it is plausible + that the pledge generates a certificate request containing only + identity information known to the pledge (essentially the X.509 + IDevID information) and ultimately receives a certificate containing + domain-specific identity information. Conceptually, the CA has + complete control over all fields issued in the end-entity + certificate. Realistically, this is operationally difficult with the + current status of PKI CA deployments, where the CSR is submitted to + the CA via a number of non-standard protocols. Even with all + standardized protocols used, it could operationally be problematic to + expect that service-specific certificate fields can be created by a + CA that is likely operated by a group that has no insight into + different network services/protocols used. For example, the CA could + even be outsourced. + + To alleviate these operational difficulties, the pledge MUST request + the EST "CSR Attributes" from the EST server, and the EST server + needs to be able to reply with the attributes necessary for use of + the certificate in its intended protocols/services. This approach + allows for minimal CA integrations, and instead, the local + infrastructure (EST server) informs the pledge of the proper fields + to include in the generated CSR (such as rfc822Name). This approach + is beneficial to automated bootstrapping in the widest number of + environments. + + In networks using the BRSKI enrolled certificate to authenticate the + ACP, the EST CSR Attributes MUST include the ACP domain information + fields defined in [RFC8994], Section 6.2.2. + + The registrar MUST also confirm that the resulting CSR is formatted + as indicated before forwarding the request to a CA. If the registrar + is communicating with the CA using a protocol such as full + Certificate Management over CMS (CMC), which provides mechanisms to + override the CSR Attributes, then these mechanisms MAY be used even + if the client ignores the guidance for the CSR Attributes. + +5.9.3. EST Client Certificate Request + + The pledge MUST request a new Client Certificate; see [RFC7030], + Section 4.2. + +5.9.4. Enrollment Status Telemetry + + For automated bootstrapping of devices, the administrative elements + that provide bootstrapping also provide indications to the system + administrators concerning device life-cycle status. This might + include information concerning attempted bootstrapping messages seen + by the client. The MASA provides logs and the status of credential + enrollment. Since an end user is assumed per [RFC7030], a final + success indication back to the server is not included. This is + insufficient for automated use cases. + + The client MUST send an indicator to the registrar about its + enrollment status. It does this by using an HTTP POST of a JSON + dictionary with the attributes described below to the new EST + endpoint at "/.well-known/brski/enrollstatus". + + When indicating a successful enrollment, the client SHOULD first re- + establish the EST TLS session using the newly obtained credentials. + TLS 1.3 supports doing this in-band, but TLS 1.2 does not. The + client SHOULD therefore always close the existing TLS connection and + start a new one, using the same Join Proxy. + + In the case of a failed enrollment, the client MUST send the + telemetry information over the same TLS connection that was used for + the enrollment attempt, with a Reason string indicating why the most + recent enrollment failed. (For failed attempts, the TLS connection + is the most reliable way to correlate server-side information with + what the client provides.) + + The version and status fields MUST be present. The Reason field + SHOULD be present whenever the status field is false. In the case of + a SUCCESS, the Reason string MAY be omitted. + + The reason-context attribute is an arbitrary JSON object (literal + value or hash of values) that provides additional information + specific to the failure to unroll from this pledge. The contents of + this field are not subject to standardization. This is represented + by the group-socket "$$arbitrary-map" in the CDDL. + + <CODE BEGINS> file "enrollstatus.cddl" + enrollstatus-post = { + "version": uint, + "status": bool, + ? "reason": text, + ? "reason-context" : { $$arbitrary-map } + } + } + <CODE ENDS> + + Figure 19: CDDL for Enrollment Status POST + + An example status report can be seen below. It is sent with the + media type: application/json + + { + "version": 1, + "status":true, + "reason":"Informative human readable message", + "reason-context": { "additional" : "JSON" } + } + + Figure 20: Example of Enrollment Status POST + + The server SHOULD respond with an HTTP 200 but MAY simply fail with + an HTTP 404 error. + + Within the server logs, the server MUST capture if this message was + received over a TLS session with a matching Client Certificate. + +5.9.5. Multiple Certificates + + Pledges that require multiple certificates could establish direct EST + connections to the registrar. + +5.9.6. EST over CoAP + + This document describes extensions to EST for the purpose of + bootstrapping remote key infrastructures. Bootstrapping is relevant + for CoAP enrollment discussions as well. The definition of EST and + BRSKI over CoAP is not discussed within this document beyond ensuring + proxy support for CoAP operations. Instead, it is anticipated that a + definition of CoAP mappings will occur in subsequent documents such + as [ACE-COAP-EST] and that CoAP mappings for BRSKI will be discussed + either there or in future work. + +6. Clarification of Transfer-Encoding + + [RFC7030] defines endpoints to include a "Content-Transfer-Encoding" + heading and payloads to be base64-encoded DER [RFC4648]. + + When used within BRSKI, the original EST endpoints remain base64 + encoded [RFC7030] (as clarified by [RFC8951]), but the new BRSKI + endpoints that send and receive binary artifacts (specifically, + "/.well-known/brski/requestvoucher") are binary. That is, no + encoding is used. + + In the BRSKI context, the EST "Content-Transfer-Encoding" header + field SHOULD be ignored if present. This header field does not need + to be included. + +7. Reduced Security Operational Modes + + A common requirement of bootstrapping is to support less secure + operational modes for support-specific use cases. This section + suggests a range of mechanisms that would alter the security + assurance of BRSKI to accommodate alternative deployment + architectures and mitigate life-cycle management issues identified in + Section 10. They are presented here as informative (non-normative) + design guidance for future standardization activities. Section 9 + provides standardization applicability statements for the ANIMA ACP. + Other users would expect that subsets of these mechanisms could be + profiled with accompanying applicability statements similar to the + one described in Section 9. + + This section is considered non-normative in the generality of the + protocol. Use of the suggested mechanisms here MUST be detailed in + specific profiles of BRSKI, such as in Section 9. + +7.1. Trust Model + + This section explains the trust relationships detailed in + Section 2.4: + + +--------+ +---------+ +------------+ +------------+ + | Pledge | | Join | | Domain | |Manufacturer| + | | | Proxy | | Registrar | | Service | + | | | | | | | (Internet) | + +--------+ +---------+ +------------+ +------------+ + + Figure 21: Elements of BRSKI Trust Model + + Pledge: The pledge could be compromised and provide an attack vector + for malware. The entity is trusted to only imprint using secure + methods described in this document. Additional endpoint + assessment techniques are RECOMMENDED but are out of scope of this + document. + + Join Proxy: Provides proxy functionalities but is not involved in + security considerations. + + Registrar: When interacting with a MASA, a registrar makes all + decisions. For Ownership Audit Vouchers (see [RFC8366]), the + registrar is provided an opportunity to accept MASA decisions. + + Vendor Service, MASA: This form of manufacturer service is trusted + to accurately log all claim attempts and to provide authoritative + log information to registrars. The MASA does not know which + devices are associated with which domains. These claims could be + strengthened by using cryptographic log techniques to provide + append only, cryptographic assured, publicly auditable logs. + + Vendor Service, Ownership Validation: This form of manufacturer + service is trusted to accurately know which device is owned by + which domain. + +7.2. Pledge Security Reductions + + The following is a list of alternative behaviors that the pledge can + be programmed to implement. These behaviors are not mutually + exclusive, nor are they dependent upon each other. Some of these + methods enable offline and emergency (touch-based) deployment use + cases. Normative language is used as these behaviors are referenced + in later sections in a normative fashion. + + 1. The pledge MUST accept nonceless vouchers. This allows for a use + case where the registrar cannot connect to the MASA at the + deployment time. Logging and validity periods address the + security considerations of supporting these use cases. + + 2. Many devices already support "trust on first use" for physical + interfaces such as console ports. This document does not change + that reality. Devices supporting this protocol MUST NOT support + "trust on first use" on network interfaces. This is because + "trust on first use" over network interfaces would undermine the + logging based security protections provided by this + specification. + + 3. The pledge MAY have an operational mode where it skips voucher + validation one time, for example, if a physical button is + depressed during the bootstrapping operation. This can be useful + if the manufacturer service is unavailable. This behavior SHOULD + be available via local configuration or physical presence methods + (such as use of a serial/craft console) to ensure new entities + can always be deployed even when autonomic methods fail. This + allows for unsecured imprint. + + 4. A craft/serial console could include a command such as "est- + enroll [2001:db8:0:1]:443" that begins the EST process from the + point after the voucher is validated. This process SHOULD + include server certificate verification using an on-screen + fingerprint. + + It is RECOMMENDED that "trust on first use" or any method of skipping + voucher validation (including use of a craft serial console) only be + available if hardware-assisted Network Endpoint Assessment (NEA) + [RFC5209] is supported. This recommendation ensures that domain + network monitoring can detect inappropriate use of offline or + emergency deployment procedures when voucher-based bootstrapping is + not used. + +7.3. Registrar Security Reductions + + A registrar can choose to accept devices using less secure methods. + They MUST NOT be the default behavior. These methods may be + acceptable in situations where threat models indicate that low + security is adequate. This includes situations where security + decisions are being made by the local administrator: + + 1. A registrar MAY choose to accept all devices, or all devices of a + particular type. The administrator could make this choice in + cases where it is operationally difficult to configure the + registrar with the unique identifier of each new device expected. + + 2. A registrar MAY choose to accept devices that claim a unique + identity without the benefit of authenticating that claimed + identity. This could occur when the pledge does not include an + X.509 IDevID factory-installed credential. New entities without + an X.509 IDevID credential MAY form the request per Section 5.2 + using the format per Section 5.5 to ensure the pledge's serial + number information is provided to the registrar (this includes + the IDevID AuthorityKeyIdentifier value, which would be + statically configured on the pledge). The pledge MAY refuse to + provide a TLS Client Certificate (as one is not available). The + pledge SHOULD support HTTP-based or certificate-less TLS + authentication as described in EST [RFC7030], Section 3.3.2. A + registrar MUST NOT accept unauthenticated new entities unless it + has been configured to do so by an administrator that has + verified that only expected new entities can communicate with a + registrar (presumably via a physically secured perimeter.) + + 3. A registrar MAY submit a nonceless voucher-request to the MASA + service (by not including a nonce in the voucher-request). The + resulting vouchers can then be stored by the registrar until they + are needed during bootstrapping operations. This is for use + cases where the target network is protected by an air gap and + therefore cannot contact the MASA service during pledge + deployment. + + 4. A registrar MAY ignore unrecognized nonceless log entries. This + could occur when used equipment is purchased with a valid history + of being deployed in air gap networks that required offline + vouchers. + + 5. A registrar MAY accept voucher formats of future types that + cannot be parsed by the registrar. This reduces the registrar's + visibility into the exact voucher contents but does not change + the protocol operations. + +7.4. MASA Security Reductions + + Lower security modes chosen by the MASA service affect all device + deployments unless the lower security behavior is tied to specific + device identities. The modes described below can be applied to + specific devices via knowledge of what devices were sold. They can + also be bound to specific customers (independent of the device + identity) by authenticating the customer's registrar. + +7.4.1. Issuing Nonceless Vouchers + + A MASA has the option of not including a nonce in the voucher and/or + not requiring one to be present in the voucher-request. This results + in distribution of a voucher that may never expire and, in effect, + makes the specified domain an always trusted entity to the pledge + during any subsequent bootstrapping attempts. The log information + captures when a nonceless voucher is issued so that the registrar can + make appropriate security decisions when a pledge joins the domain. + Nonceless vouchers are useful to support use cases where registrars + might not be online during actual device deployment. + + While a nonceless voucher may include an expiry date, a typical use + for a nonceless voucher is for it to be long lived. If the device + can be trusted to have an accurate clock (the MASA will know), then a + nonceless voucher CAN be issued with a limited lifetime. + + A more typical case for a nonceless voucher is for use with offline + onboarding scenarios where it is not possible to pass a fresh + voucher-request to the MASA. The use of a long-lived voucher also + eliminates concern about the availability of the MASA many years in + the future. Thus, many nonceless vouchers will have no expiry dates. + + Thus, the long-lived nonceless voucher does not require proof that + the device is online. Issuing such a thing is only accepted when the + registrar is authenticated by the MASA and the MASA is authorized to + provide this functionality to this customer. The MASA is RECOMMENDED + to use this functionality only in concert with an enhanced level of + ownership tracking, the details of which are out of scope for this + document. + + If the pledge device is known to have a real-time clock that is set + from the factory, use of a voucher validity period is RECOMMENDED. + +7.4.2. Trusting Owners on First Use + + A MASA has the option of not verifying ownership before responding + with a voucher. This is expected to be a common operational model + because doing so relieves the manufacturer providing MASA services + from having to track ownership during shipping and throughout the + supply chain, and it allows for a very low overhead MASA service. A + registrar uses the audit-log information as an in-depth defense + strategy to ensure that this does not occur unexpectedly (for + example, when purchasing new equipment, the registrar would throw an + error if any audit-log information is reported). The MASA SHOULD + verify the prior-signed-voucher-request information for pledges that + support that functionality. This provides a proof-of-proximity check + that reduces the need for ownership verification. The proof-of- + proximity comes from the assumption that the pledge and Join Proxy + are on the same link-local connection. + + A MASA that practices TOFU for registrar identity may wish to + annotate the origin of the connection by IP address or netblock and + restrict future use of that identity from other locations. A MASA + that does this SHOULD take care to not create nuisance situations for + itself when a customer has multiple registrars or uses outgoing IPv4- + to-IPv4 NAT (NAT44) connections that change frequently. + +7.4.3. Updating or Extending Voucher Trust Anchors + + This section deals with two problems: A MASA that is no longer + available due to a failed business and a MASA that is uncooperative + to a secondary sale. + + A manufacturer could offer a management mechanism that allows the + list of voucher verification trust anchors to be extended. + [YANG-KEYSTORE] describes one such interface that could be + implemented using YANG. Pretty much any configuration mechanism used + today could be extended to provide the needed additional update. A + manufacturer could even decide to install the domain CA trust anchors + received during the EST "cacerts" step as voucher verification + anchors. Some additional signals will be needed to clearly identify + which keys have voucher validation authority from among those signed + by the domain CA. This is future work. + + With the above change to the list of anchors, vouchers can be issued + by an alternate MASA. This could be the previous owner (the seller) + or some other trusted third party who is mediating the sale. If it + is a third party, the seller would need to take steps to introduce + the third-party configuration to the device prior to disconnection. + The third party (e.g., a wholesaler of used equipment) could, + however, use a mechanism described in Section 7.2 to take control of + the device after receiving it physically. This would permit the + third party to act as the MASA for future onboarding actions. As the + IDevID certificate probably cannot be replaced, the new owner's + registrar would have to support an override of the MASA URL. + + To be useful for resale or other transfers of ownership, one of two + situations will need to occur. The simplest is that the device is + not put through any kind of factory default/reset before going + through onboarding again. Some other secure, physical signal would + be needed to initiate it. This is most suitable for redeploying a + device within the same enterprise. This would entail having previous + configuration in the system until entirely replaced by the new owner, + and it represents some level of risk. + + For the second scenario, there would need to be two levels of factory + reset. One would take the system back entirely to manufacturer + state, including removing any added trust anchors, and the other + (more commonly used) one would just restore the configuration back to + a known default without erasing trust anchors. This weaker factory + reset might leave valuable credentials on the device, and this may be + unacceptable to some owners. + + As a third option, the manufacturer's trust anchors could be entirely + overwritten with local trust anchors. A factory default would never + restore those anchors. This option comes with a lot of power but is + also a lot of responsibility: if access to the private part of the + new anchors are lost, the manufacturer may be unable to help. + +8. IANA Considerations + + Per this document, IANA has completed the following actions. + +8.1. The IETF XML Registry + + This document registers a URI in the "IETF XML Registry" [RFC3688]. + IANA has registered the following: + + URI: urn:ietf:params:xml:ns:yang:ietf-voucher-request + Registrant Contact: The ANIMA WG of the IETF. + XML: N/A; the requested URI is an XML namespace. + +8.2. YANG Module Names Registry + + This document registers a YANG module in the "YANG Module Names" + registry [RFC6020]. IANA has registered the following: + + Name: ietf-voucher-request + Namespace: urn:ietf:params:xml:ns:yang:ietf-voucher-request + Prefix: vch + Reference: RFC 8995 + +8.3. BRSKI Well-Known Considerations + +8.3.1. BRSKI .well-known Registration + + To the "Well-Known URIs" registry at + https://www.iana.org/assignments/well-known-uris/, this document + registers the well-known name "brski" with the following filled-in + template from [RFC8615]: + + URI Suffix: brski + Change Controller: IETF + + IANA has changed the registration of "est" to now only include + [RFC7030] and no longer this document. Earlier draft versions of + this document used "/.well-known/est" rather than "/.well-known/ + brski". + +8.3.2. BRSKI .well-known Registry + + IANA has created a new registry entitled: "BRSKI Well-Known URIs". + The registry has three columns: URI, Description, and Reference. New + items can be added using the Specification Required [RFC8126] + process. The initial contents of this registry are: + + +=================+==========================+===========+ + | URI | Description | Reference | + +=================+==========================+===========+ + | requestvoucher | pledge to registrar, and | RFC 8995 | + | | from registrar to MASA | | + +-----------------+--------------------------+-----------+ + | voucher_status | pledge to registrar | RFC 8995 | + +-----------------+--------------------------+-----------+ + | requestauditlog | registrar to MASA | RFC 8995 | + +-----------------+--------------------------+-----------+ + | enrollstatus | pledge to registrar | RFC 8995 | + +-----------------+--------------------------+-----------+ + + Table 1: BRSKI Well-Known URIs + +8.4. PKIX Registry + + IANA has registered the following: + + a number for id-mod-MASAURLExtn2016(96) from the pkix(7) id-mod(0) + Registry. + + IANA has assigned a number from the id-pe registry (Structure of + Management Information (SMI) Security for PKIX Certificate Extension) + for id-pe-masa-url with the value 32, resulting in an OID of + 1.3.6.1.5.5.7.1.32. + +8.5. Pledge BRSKI Status Telemetry + + IANA has created a new registry entitled "BRSKI Parameters" and has + created, within that registry, a table called: "Pledge BRSKI Status + Telemetry Attributes". New items can be added using the + Specification Required process. The following items are in the + initial registration, with this document (see Section 5.7) as the + reference: + + * version + + * Status + + * Reason + + * reason-context + +8.6. DNS Service Names + + IANA has registered the following service names: + + Service Name: brski-proxy + Transport Protocol(s): tcp + Assignee: IESG <iesg@ietf.org> + Contact: IESG <iesg@ietf.org> + Description: The Bootstrapping Remote Secure Key Infrastructure + Proxy + Reference: RFC 8995 + + Service Name: brski-registrar + Transport Protocol(s): tcp + Assignee: IESG <iesg@ietf.org> + Contact: IESG <iesg@ietf.org> + Description: The Bootstrapping Remote Secure Key Infrastructure + Registrar + Reference: RFC 8995 + +8.7. GRASP Objective Names + + IANA has registered the following GRASP Objective Names: + + IANA has registered the value "AN_Proxy" (without quotes) to the + "GRASP Objective Names" table in the GRASP Parameter registry. The + specification for this value is Section 4.1.1 of this document. + + The IANA has registered the value "AN_join_registrar" (without + quotes) to the "GRASP Objective Names" table in the GRASP Parameter + registry. The specification for this value is Section 4.3 of this + document. + +9. Applicability to the Autonomic Control Plane (ACP) + + This document provides a solution to the requirements for secure + bootstrapping as defined in "Using an Autonomic Control Plane for + Stable Connectivity of Network Operations, Administration, and + Maintenance (OAM)" [RFC8368], "A Reference Model for Autonomic + Networking" [RFC8993], and specifically "An Autonomic Control Plane + (ACP)" [RFC8994]; see Sections 3.2 ("Secure Bootstrap over an + Unconfigured Network") and 6.2 ("ACP Domain, Certificate, and + Network"). + + The protocol described in this document has appeal in a number of + other non-ANIMA use cases. Such uses of the protocol will be + deployed into other environments with different tradeoffs of privacy, + security, reliability, and autonomy from manufacturers. As such, + those use cases will need to provide their own applicability + statements and will need to address unique privacy and security + considerations for the environments in which they are used. + + The ACP that is bootstrapped by the BRSKI protocol is typically used + in medium to large Internet service provider organizations. + Equivalent enterprises that have significant Layer 3 router + connectivity also will find significant benefit, particularly if the + enterprise has many sites. (A network consisting of primarily Layer + 2 is not excluded, but the adjacencies that the ACP will create and + maintain will not reflect the topology until all devices participate + in the ACP.) + + In the ACP, the Join Proxy is found to be proximal because + communication between the pledge and the Join Proxy is exclusively on + IPv6 link-local addresses. The proximity of the Join Proxy to the + registrar is validated by the registrar using ANI ACP IPv6 ULAs. + ULAs are not routable over the Internet, so as long as the Join Proxy + is operating correctly, the proximity assertion is satisfied. Other + uses of BRSKI will need similar analysis if they use proximity + assertions. + + As specified in the ANIMA charter, this work "focuses on + professionally-managed networks." Such a network has an operator and + can do things like install, configure, and operate the registrar + function. The operator makes purchasing decisions and is aware of + what manufacturers it expects to see on its network. + + Such an operator is also capable of performing bootstrapping of a + device using a serial console (craft console). The zero-touch + mechanism presented in this and the ACP document [RFC8994] represents + a significant efficiency: in particular, it reduces the need to put + senior experts on airplanes to configure devices in person. + + As the technology evolves, there is recognition that not every + situation may work out, and occasionally a human may still have to + visit. Given this, some mechanisms are presented in Section 7.2. + The manufacturer MUST provide at least one of the one-touch + mechanisms described that permit enrollment to proceed without the + availability of any manufacturer server (such as the MASA). + + The BRSKI protocol is going into environments where there have + already been quite a number of vendor proprietary management systems. + Those are not expected to go away quickly but rather to leverage the + secure credentials that are provisioned by BRSKI. The connectivity + requirements of the said management systems are provided by the ACP. + +9.1. Operational Requirements + + This section collects operational requirements based upon the three + roles involved in BRSKI: the MASA, the (domain) owner, and the + device. It should be recognized that the manufacturer may be + involved in two roles, as it creates the software/firmware for the + device and may also be the operator of the MASA. + + The requirements in this section are presented using BCP 14 language + [RFC2119] [RFC8174]. These do not represent new normative + statements, just a review of a few such things in one place by role. + They also apply specifically to the ANIMA ACP use case. Other use + cases likely have similar, but MAY have different, requirements. + +9.1.1. MASA Operational Requirements + + The manufacturer MUST arrange for an online service called the MASA + to be available. It MUST be available at the URL that is encoded in + the IDevID certificate extensions described in Section 2.3.2. + + The online service MUST have access to a private key with which to + sign voucher artifacts [RFC8366]. The public key, certificate, or + certificate chain MUST be built into the device as part of the + firmware. + + It is RECOMMENDED that the manufacturer arrange for this signing key + (or keys) to be escrowed according to typical software source code + escrow practices [softwareescrow]. + + The MASA accepts voucher-requests from domain owners according to an + operational practice appropriate for the device. This can range from + any domain owner (first-come first-served, on a TOFU-like basis), to + full sales channel integration where domain owners need to be + positively identified by TLS pinned Client Certificates or an HTTP + authentication process. The MASA creates signed voucher artifacts + according to its internally defined policies. + + The MASA MUST operate an audit-log for devices that is accessible. + The audit-log is designed to be easily cacheable, and the MASA MAY + find it useful to put this content on a Content Delivery Network + (CDN). + +9.1.2. Domain Owner Operational Requirements + + The domain owner MUST operate an EST [RFC7030] server with the + extensions described in this document. This is the JRC or registrar. + This JRC/EST server MUST announce itself using GRASP within the ACP. + This EST server will typically reside with the Network Operations + Center for the organization. + + The domain owner MAY operate an internal CA that is separate from the + EST server, or it MAY combine all activities into a single device. + The determination of the architecture depends upon the scale and + resiliency requirements of the organization. Multiple JRC instances + MAY be announced into the ACP from multiple locations to achieve an + appropriate level of redundancy. + + In order to recognize which devices and which manufacturers are + welcome on the domain owner's network, the domain owner SHOULD + maintain an acceptlist of manufacturers. This MAY extend to + integration with purchasing departments to know the serial numbers of + devices. + + The domain owner SHOULD use the resulting overlay ACP network to + manage devices, replacing legacy out-of-band mechanisms. + + The domain owner SHOULD operate one or more EST servers that can be + used to renew the domain certificates (LDevIDs), which are deployed + to devices. These servers MAY be the same as the JRC or MAY be a + distinct set of devices, as appropriate for resiliency. + + The organization MUST take appropriate precautions against loss of + access to the CA private key. Hardware security modules and/or + secret splitting are appropriate. + +9.1.3. Device Operational Requirements + + Devices MUST come with built-in trust anchors that permit the device + to validate vouchers from the MASA. + + Devices MUST come with (unique, per-device) IDevID certificates that + include their serial numbers and the MASA URL extension. + + Devices are expected to find Join Proxies using GRASP, and then + connect to the JRC using the protocol described in this document. + + Once a domain owner has been validated with the voucher, devices are + expected to enroll into the domain using EST. Devices are then + expected to form ACPs using IPsec over IPv6 link-local addresses as + described in [RFC8994]. + + Once a device has been enrolled, it SHOULD listen for the address of + the JRC using GRASP, and it SHOULD enable itself as a Join Proxy and + announce itself on all links/interfaces using GRASP DULL. + + Devices are expected to renew their certificates before they expire. + +10. Privacy Considerations + +10.1. MASA Audit-Log + + The MASA audit-log includes the domainID for each domain a voucher + has been issued to. This information is closely related to the + actual domain identity. A MASA may need additional defenses against + Denial-of-Service attacks (Section 11.1), and this may involve + collecting additional (unspecified here) information. This could + provide sufficient information for the MASA service to build a + detailed understanding of the devices that have been provisioned + within a domain. + + There are a number of design choices that mitigate this risk. The + domain can maintain some privacy since it has not necessarily been + authenticated and is not authoritatively bound to the supply chain. + + Additionally, the domainID captures only the unauthenticated subject + key identifier of the domain. A privacy-sensitive domain could + theoretically generate a new domainID for each device being deployed. + Similarly, a privacy-sensitive domain would likely purchase devices + that support proximity assertions from a manufacturer that does not + require sales channel integrations. This would result in a + significant level of privacy while maintaining the security + characteristics provided by the registrar-based audit-log inspection. + +10.2. What BRSKI-EST Reveals + + During the provisional phase of the BRSKI-EST connection between the + pledge and the registrar, each party reveals its certificates to each + other. For the pledge, this includes the serialNumber attribute, the + MASA URL, and the identity that signed the IDevID certificate. + + TLS 1.2 reveals the certificate identities to on-path observers, + including the Join Proxy. + + TLS 1.3 reveals the certificate identities only to the end parties, + but as the connection is provisional; an on-path attacker (MITM) can + see the certificates. This includes not just malicious attackers but + also registrars that are visible to the pledge but are not part of + the intended domain. + + The certificate of the registrar is rather arbitrary from the point + of view of the BRSKI protocol. As no validations [RFC6125] are + expected to be done, the contents could be easily pseudonymized. Any + device that can see a Join Proxy would be able to connect to the + registrar and learn the identity of the network in question. Even if + the contents of the certificate are pseudonymized, it would be + possible to correlate different connections in different locations + that belong to the same entity. This is unlikely to present a + significant privacy concern to ANIMA ACP uses of BRSKI, but it may be + a concern to other users of BRSKI. + + The certificate of the pledge could be revealed by a malicious Join + Proxy that performed a MITM attack on the provisional TLS connection. + Such an attacker would be able to reveal the identity of the pledge + to third parties if it chose to do so. + + Research into a mechanism to do multistep, multiparty authenticated + key agreement, incorporating some kind of zero-knowledge proof, would + be valuable. Such a mechanism would ideally avoid disclosing + identities until the pledge, registrar, and MASA agree to the + transaction. Such a mechanism would need to discover the location of + the MASA without knowing the identity of the pledge or the identity + of the MASA. This part of the problem may be unsolvable. + +10.3. What BRSKI-MASA Reveals to the Manufacturer + + With consumer-oriented devices, the "call-home" mechanism in IoT + devices raises significant privacy concerns. See [livingwithIoT] and + [IoTstrangeThings] for exemplars. The ACP usage of BRSKI is not + targeted at individual usage of IoT devices but rather at the + enterprise and ISP creation of networks in a zero-touch fashion where + the "call-home" represents a different class of privacy and life- + cycle management concerns. + + It needs to be reiterated that the BRSKI-MASA mechanism only occurs + once during the commissioning of the device. It is well defined, and + although encrypted with TLS, it could in theory be made auditable as + the contents are well defined. This connection does not occur when + the device powers on or is restarted for normal routines. (It is + conceivable, but remarkably unusual, that a device could be forced to + go through a full factory reset during an exceptional firmware update + situation, after which enrollment would have to be repeated, and a + new connection would occur.) + + The BRSKI call-home mechanism is mediated via the owner's registrar, + and the information that is transmitted is directly auditable by the + device owner. This is in stark contrast to many "call-home" + protocols where the device autonomously calls home and uses an + undocumented protocol. + + While the contents of the signed part of the pledge voucher-request + cannot be changed, they are not encrypted at the registrar. The + ability to audit the messages by the owner of the network is a + mechanism to defend against exfiltration of data by a nefarious + pledge. Both are, to reiterate, encrypted by TLS while in transit. + + The BRSKI-MASA exchange reveals the following information to the + manufacturer: + + * the identity of the device being enrolled. This is revealed by + transmission of a signed voucher-request containing the serial- + number. The manufacturer can usually link the serial number to a + device model. + + * an identity of the domain owner in the form of the domain trust + anchor. However, this is not a global PKI-anchored name within + the WebPKI, so this identity could be pseudonymous. If there is + sales channel integration, then the MASA will have authenticated + the domain owner, via either a pinned certificate or perhaps + another HTTP authentication method, as per Section 5.5.4. + + * the time the device is activated. + + * the IP address of the domain owner's registrar. For ISPs and + enterprises, the IP address provides very clear geolocation of the + owner. No amount of IP address privacy extensions [RFC8981] can + do anything about this, as a simple whois lookup likely identifies + the ISP or enterprise from the upper bits anyway. A passive + attacker who observes the connection definitely may conclude that + the given enterprise/ISP is a customer of the particular equipment + vendor. The precise model that is being enrolled will remain + private. + + Based upon the above information, the manufacturer is able to track a + specific device from pseudonymous domain identity to the next + pseudonymous domain identity. If there is sales-channel integration, + then the identities are not pseudonymous. + + The manufacturer knows the IP address of the registrar, but it cannot + see the IP address of the device itself. The manufacturer cannot + track the device to a detailed physical or network location, only to + the location of the registrar. That is likely to be at the + enterprise or ISP's headquarters. + + The above situation is to be distinguished from a residential/ + individual person who registers a device from a manufacturer. + Individuals do not tend to have multiple offices, and their registrar + is likely on the same network as the device. A manufacturer that + sells switching/routing products to enterprises should hardly be + surprised if additional purchases of switching/routing products are + made. Deviations from a historical trend or an established baseline + would, however, be notable. + + The situation is not improved by the enterprise/ISP using + anonymization services such as Tor [Dingledine], as a TLS 1.2 + connection will reveal the ClientCertificate used, clearly + identifying the enterprise/ISP involved. TLS 1.3 is better in this + regard, but an active attacker can still discover the parties + involved by performing a MITM attack on the first attempt (breaking/ + killing it with a TCP reset (RST)), and then letting subsequent + connection pass through. + + A manufacturer could attempt to mix the BRSKI-MASA traffic in with + general traffic on their site by hosting the MASA behind the same + (set) of load balancers that the company's normal marketing site is + hosted behind. This makes a lot of sense from a straight capacity + planning point of view as the same set of services (and the same set + of Distributed Denial-of-Service mitigations) may be used. + Unfortunately, as the BRSKI-MASA connections include TLS + ClientCertificate exchanges, this may easily be observed in TLS 1.2, + and a traffic analysis may reveal it even in TLS 1.3. This does not + make such a plan irrelevant. There may be other organizational + reasons to keep the marketing site (which is often subject to + frequent redesigns, outsourcing, etc.) separate from the MASA, which + may need to operate reliably for decades. + +10.4. Manufacturers and Used or Stolen Equipment + + As explained above, the manufacturer receives information each time a + device that is in factory-default mode does a zero-touch bootstrap + and attempts to enroll into a domain owner's registrar. + + The manufacturer is therefore in a position to decline to issue a + voucher if it detects that the new owner is not the same as the + previous owner. + + 1. This can be seen as a feature if the equipment is believed to + have been stolen. If the legitimate owner notifies the + manufacturer of the theft, then when the new owner brings the + device up, if they use the zero-touch mechanism, the new + (illegitimate) owner reveals their location and identity. + + 2. In the case of used equipment, the initial owner could inform the + manufacturer of the sale, or the manufacturer may just permit + resales unless told otherwise. In which case, the transfer of + ownership simply occurs. + + 3. A manufacturer could, however, decide not to issue a new voucher + in response to a transfer of ownership. This is essentially the + same as the stolen case, with the manufacturer having decided + that the sale was not legitimate. + + 4. There is a fourth case, if the manufacturer is providing + protection against stolen devices. The manufacturer then has a + responsibility to protect the legitimate owner against fraudulent + claims that the equipment was stolen. In the absence of such + manufacturer protection, such a claim would cause the + manufacturer to refuse to issue a new voucher. Should the device + go through a deep factory reset (for instance, replacement of a + damaged main board component), the device would not bootstrap. + + 5. Finally, there is a fifth case: the manufacturer has decided to + end-of-line the device, or the owner has not paid a yearly + support amount, and the manufacturer refuses to issue new + vouchers at that point. This last case is not new to the + industry: many license systems are already deployed that have a + significantly worse effect. + + This section has outlined five situations in which a manufacturer + could use the voucher system to enforce what are clearly license + terms. A manufacturer that attempted to enforce license terms via + vouchers would find it rather ineffective as the terms would only be + enforced when the device is enrolled, and this is not (to repeat) a + daily or even monthly occurrence. + +10.5. Manufacturers and Grey Market Equipment + + Manufacturers of devices often sell different products into different + regional markets. Which product is available in which market can be + driven by price differentials, support issues (some markets may + require manuals and tech support to be done in the local language), + and government export regulation (such as whether strong crypto is + permitted to be exported or permitted to be used in a particular + market). When a domain owner obtains a device from a different + market (they can be new) and transfers it to a different location, + this is called a Grey Market. + + A manufacturer could decide not to issue a voucher to an enterprise/ + ISP based upon their location. There are a number of ways that this + could be determined: from the geolocation of the registrar, from + sales channel knowledge about the customer, and from what products + are available or unavailable in that market. If the device has a + GPS, the coordinates of the device could even be placed into an + extension of the voucher. + + The above actions are not illegal, and not new. Many manufacturers + have shipped crypto-weak (exportable) versions of firmware as the + default on equipment for decades. The first task of an enterprise/ + ISP has always been to login to a manufacturer system, show one's + "entitlement" (country information, proof that support payments have + been made), and receive either a new updated firmware or a license + key that will activate the correct firmware. + + BRSKI permits the above process to be automated (in an autonomic + fashion) and therefore perhaps encourages this kind of + differentiation by reducing the cost of doing it. + + An issue that manufacturers will need to deal with in the above + automated process is when a device is shipped to one country with one + set of rules (or laws or entitlements), but the domain registry is in + another one. Which rules apply is something that will have to be + worked out: the manufacturer could believe they are dealing with Grey + Market equipment when they are simply dealing with a global + enterprise. + +10.6. Some Mitigations for Meddling by Manufacturers + + The most obvious mitigation is not to buy the product. Pick + manufacturers that are up front about their policies and who do not + change them gratuitously. + + Section 7.4.3 describes some ways in which a manufacturer could + provide a mechanism to manage the trust anchors and built-in + certificates (IDevID) as an extension. There are a variety of + mechanisms, and some may take a substantial amount of work to get + exactly correct. These mechanisms do not change the flow of the + protocol described here but rather allow the starting trust + assumptions to be changed. This is an area for future + standardization work. + + Replacement of the voucher validation anchors (usually pointing to + the original manufacturer's MASA) with those of the new owner permits + the new owner to issue vouchers to subsequent owners. This would be + done by having the selling (old) owner run a MASA. + + The BRSKI protocol depends upon a trust anchor and an identity on the + device. Management of these entities facilitates a few new + operational modes without making any changes to the BRSKI protocol. + Those modes include: offline modes where the domain owner operates an + internal MASA for all devices, resell modes where the first domain + owner becomes the MASA for the next (resold-to) domain owner, and + services where an aggregator acquires a large variety of devices and + then acts as a pseudonymized MASA for a variety of devices from a + variety of manufacturers. + + Although replacement of the IDevID is not required for all modes + described above, a manufacturer could support such a thing. Some may + wish to consider replacement of the IDevID as an indication that the + device's warranty is terminated. For others, the privacy + requirements of some deployments might consider this a standard + operating practice. + + As discussed at the end of Section 5.8.1, new work could be done to + use a distributed consensus technology for the audit-log. This would + permit the audit-log to continue to be useful, even when there is a + chain of MASA due to changes of ownership. + +10.7. Death of a Manufacturer + + A common concern has been that a manufacturer could go out of + business, leaving owners of devices unable to get new vouchers for + existing products. Said products might have been previously deployed + but need to be reinitialized, used, or kept in a warehouse as long- + term spares. + + The MASA was named the Manufacturer *Authorized* Signing Authority to + emphasize that it need not be the manufacturer itself that performs + this. It is anticipated that specialist service providers will come + to exist that deal with the creation of vouchers in much the same way + that many companies have outsourced email, advertising, and + janitorial services. + + Further, it is expected that as part of any service agreement, the + manufacturer would arrange to escrow appropriate private keys such + that a MASA service could be provided by a third party. This has + routinely been done for source code for decades. + +11. Security Considerations + + This document details a protocol for bootstrapping that balances + operational concerns against security concerns. As detailed in the + introduction, and touched on again in Section 7, the protocol allows + for reduced security modes. These attempt to deliver additional + control to the local administrator and owner in cases where less + security provides operational benefits. This section goes into more + detail about a variety of specific considerations. + + To facilitate logging and administrative oversight, in addition to + triggering registrar verification of MASA logs, the pledge reports on + the voucher parsing status to the registrar. In the case of a + failure, this information is informative to a potentially malicious + registrar. This is mandated anyway because of the operational + benefits of an informed administrator in cases where the failure is + indicative of a problem. The registrar is RECOMMENDED to verify MASA + logs if voucher status telemetry is not received. + + To facilitate truly limited clients, EST requires that the client + MUST support a client authentication model (see [RFC7030], + Section 3.3.2); Section 7 updates these requirements by stating that + the registrar MAY choose to accept devices that fail cryptographic + authentication. This reflects current (poor) practices in shipping + devices without a cryptographic identity that are NOT RECOMMENDED. + + During the provisional period of the connection, the pledge MUST + treat all HTTP header and content data as untrusted data. HTTP + libraries are regularly exposed to non-secured HTTP traffic: mature + libraries should not have any problems. + + Pledges might chose to engage in protocol operations with multiple + discovered registrars in parallel. As noted above, they will only do + so with distinct nonce values, but the end result could be multiple + vouchers issued from the MASA if all registrars attempt to claim the + device. This is not a failure, and the pledge chooses whichever + voucher to accept based on internal logic. The registrars verifying + log information will see multiple entries and take this into account + for their analytic purposes. + +11.1. Denial of Service (DoS) against MASA + + There are use cases where the MASA could be unavailable or + uncooperative to the registrar. They include active DoS attacks, + planned and unplanned network partitions, changes to MASA policy, or + other instances where MASA policy rejects a claim. These introduce + an operational risk to the registrar owner in that MASA behavior + might limit the ability to bootstrap a pledge device. For example, + this might be an issue during disaster recovery. This risk can be + mitigated by registrars that request and maintain long-term copies of + "nonceless" vouchers. In that way, they are guaranteed to be able to + bootstrap their devices. + + The issuance of nonceless vouchers themselves creates a security + concern. If the registrar of a previous domain can intercept + protocol communications, then it can use a previously issued + nonceless voucher to establish management control of a pledge device + even after having sold it. This risk is mitigated by recording the + issuance of such vouchers in the MASA audit-log that is verified by + the subsequent registrar and by pledges only bootstrapping when in a + factory default state. This reflects a balance between enabling MASA + independence during future bootstrapping and the security of + bootstrapping itself. Registrar control over requesting and auditing + nonceless vouchers allows device owners to choose an appropriate + balance. + + The MASA is exposed to DoS attacks wherein attackers claim an + unbounded number of devices. Ensuring a registrar is representative + of a valid manufacturer customer, even without validating ownership + of specific pledge devices, helps to mitigate this. Pledge + signatures on the pledge voucher-request, as forwarded by the + registrar in the prior-signed-voucher-request field of the registrar + voucher-request, significantly reduce this risk by ensuring the MASA + can confirm proximity between the pledge and the registrar making the + request. Supply-chain integration ("know your customer") is an + additional step that MASA providers and device vendors can explore. + +11.2. DomainID Must Be Resistant to Second-Preimage Attacks + + The domainID is used as the reference in the audit-log to the domain. + The domainID is expected to be calculated by a hash that is resistant + to a second-preimage attack. Such an attack would allow a second + registrar to create audit-log entries that are fake. + +11.3. Availability of Good Random Numbers + + The nonce used by the pledge in the voucher-request SHOULD be + generated by a Strong Cryptographic Sequence ([RFC4086], + Section 6.2). TLS has a similar requirement. + + In particular, implementations should pay attention to the advance in + [RFC4086]; see Sections 3 and, in particular, 3.4. The random seed + used by a device at boot MUST be unique across all devices and all + bootstraps. Resetting a device to factory default state does not + obviate this requirement. + +11.4. Freshness in Voucher-Requests + + A concern has been raised that the pledge voucher-request should + contain some content (a nonce) provided by the registrar and/or MASA + in order for those actors to verify that the pledge voucher-request + is fresh. + + There are a number of operational problems with getting a nonce from + the MASA to the pledge. It is somewhat easier to collect a random + value from the registrar, but as the registrar is not yet vouched + for, such a registrar nonce has little value. There are privacy and + logistical challenges to addressing these operational issues, so if + such a thing were to be considered, it would have to provide some + clear value. This section examines the impacts of not having a fresh + pledge voucher-request. + + Because the registrar authenticates the pledge, a full MITM attack is + not possible, despite the provisional TLS authentication by the + pledge (see Section 5.) Instead, we examine the case of a fake + registrar (Rm) that communicates with the pledge in parallel or in + close-time proximity with the intended registrar. (This scenario is + intentionally supported as described in Section 4.1.) + + The fake registrar (Rm) can obtain a voucher signed by the MASA + either directly or through arbitrary intermediaries. Assuming that + the MASA accepts the registrar voucher-request (because either the Rm + is collaborating with a legitimate registrar according to supply- + chain information or the MASA is in audit-log only mode), then a + voucher linking the pledge to the registrar Rm is issued. + + Such a voucher, when passed back to the pledge, would link the pledge + to registrar Rm and permit the pledge to end the provisional state. + It now trusts the Rm and, if it has any security vulnerabilities + leverageable by an Rm with full administrative control, can be + assumed to be a threat against the intended registrar. + + This flow is mitigated by the intended registrar verifying the audit- + logs available from the MASA as described in Section 5.8. The Rm + might chose to collect a voucher-request but wait until after the + intended registrar completes the authorization process before + submitting it. This pledge voucher-request would be "stale" in that + it has a nonce that no longer matches the internal state of the + pledge. In order to successfully use any resulting voucher, the Rm + would need to remove the stale nonce or anticipate the pledge's + future nonce state. Reducing the possibility of this is why the + pledge is mandated to generate a strong random or pseudo-random + number nonce. + + Additionally, in order to successfully use the resulting voucher, the + Rm would have to attack the pledge and return it to a bootstrapping- + enabled state. This would require wiping the pledge of current + configuration and triggering a rebootstrapping of the pledge. This + is no more likely than simply taking control of the pledge directly, + but if this is a consideration, it is RECOMMENDED that the target + network take the following steps: + + * Ongoing network monitoring for unexpected bootstrapping attempts + by pledges. + + * Retrieval and examination of MASA log information upon the + occurrence of any such unexpected events. The Rm will be listed + in the logs along with nonce information for analysis. + +11.5. Trusting Manufacturers + + The BRSKI extensions to EST permit a new pledge to be completely + configured with domain-specific trust anchors. The link from built- + in manufacturer-provided trust anchors to domain-specific trust + anchors is mediated by the signed voucher artifact. + + If the manufacturer's IDevID signing key is not properly validated, + then there is a risk that the network will accept a pledge that + should not be a member of the network. As the address of the + manufacturer's MASA is provided in the IDevID using the extension + from Section 2.3, the malicious pledge will have no problem + collaborating with its MASA to produce a completely valid voucher. + + BRSKI does not, however, fundamentally change the trust model from + domain owner to manufacturer. Assuming that the pledge used its + IDevID with EST [RFC7030] and BRSKI, the domain (registrar) still + needs to trust the manufacturer. + + Establishing this trust between domain and manufacturer is outside + the scope of BRSKI. There are a number of mechanisms that can be + adopted including: + + * Manually configuring each manufacturer's trust anchor. + + * A TOFU mechanism. A human would be queried upon seeing a + manufacturer's trust anchor for the first time, and then the trust + anchor would be installed to the trusted store. There are risks + with this; even if the key to name mapping is validated using + something like the WebPKI, there remains the possibility that the + name is a look alike: e.g., dem0.example. vs. demO.example. + + * scanning the trust anchor from a QR code that came with the + packaging (this is really a manual TOFU mechanism). + + * some sales integration processing where trust anchors are provided + as part of the sales process, probably included in a digital + packing "slip", or a sales invoice. + + * consortium membership, where all manufacturers of a particular + device category (e.g, a light bulb or a cable modem) are signed by + a CA specifically for this. This is done by CableLabs today. It + is used for authentication and authorization as part of + [docsisroot] and [TR069]. + + The existing WebPKI provides a reasonable anchor between manufacturer + name and public key. It authenticates the key. It does not provide + a reasonable authorization for the manufacturer, so it is not + directly usable on its own. + +11.6. Manufacturer Maintenance of Trust Anchors + + BRSKI depends upon the manufacturer building in trust anchors to the + pledge device. The voucher artifact that is signed by the MASA will + be validated by the pledge using that anchor. This implies that the + manufacturer needs to maintain access to a signing key that the + pledge can validate. + + The manufacturer will need to maintain the ability to make signatures + that can be validated for the lifetime that the device could be + onboarded. Whether this onboarding lifetime is less than the device + lifetime depends upon how the device is used. An inventory of + devices kept in a warehouse as spares might not be onboarded for many + decades. + + There are good cryptographic hygiene reasons why a manufacturer would + not want to maintain access to a private key for many decades. A + manufacturer in that situation can leverage a long-term CA anchor, + built-in to the pledge, and then a certificate chain may be + incorporated using the normal CMS certificate set. This may increase + the size of the voucher artifacts, but that is not a significant + issue in non-constrained environments. + + There are a few other operational variations that manufacturers could + consider. For instance, there is no reason that every device need + have the same set of trust anchors preinstalled. Devices built in + different factories, or on different days, or in any other + consideration, could have different trust anchors built in, and the + record of which batch the device is in would be recorded in the asset + database. The manufacturer would then know which anchor to sign an + artifact against. + + Aside from the concern about long-term access to private keys, a + major limiting factor for the shelf life of many devices will be the + age of the cryptographic algorithms included. A device produced in + 2019 will have hardware and software capable of validating algorithms + common in 2019 and will have no defense against attacks (both quantum + and von Neumann brute-force attacks) that have not yet been invented. + This concern is orthogonal to the concern about access to private + keys, but this concern likely dominates and limits the life span of a + device in a warehouse. If any update to the firmware to support new + cryptographic mechanisms were possible (while the device was in a + warehouse), updates to trust anchors would also be done at the same + time. + + The set of standard operating procedures for maintaining high-value + private keys is well documented. For instance, the WebPKI provides a + number of options for audits in [cabforumaudit], and the DNSSEC root + operations are well documented in [dnssecroot]. + + It is not clear if manufacturers will take this level of precaution, + or how strong the economic incentives are to maintain an appropriate + level of security. + + The next section examines the risk due to a compromised manufacturer + IDevID signing key. This is followed by examination of the risk due + to a compromised MASA key. The third section below examines the + situation where a MASA web server itself is under attacker control, + but the MASA signing key itself is safe in a not-directly connected + hardware module. + +11.6.1. Compromise of Manufacturer IDevID Signing Keys + + An attacker that has access to the key that the manufacturer uses to + sign IDevID certificates can create counterfeit devices. Such + devices can claim to be from a particular manufacturer but can be + entirely different devices: Trojan horses in effect. + + As the attacker controls the MASA URL in the certificate, the + registrar can be convinced to talk to the attacker's MASA. The + registrar does not need to be in any kind of promiscuous mode to be + vulnerable. + + In addition to creating fake devices, the attacker may also be able + to issue revocations for existing certificates if the IDevID + certificate process relies upon CRL lists that are distributed. + + There does not otherwise seem to be any risk from this compromise to + devices that are already deployed or that are sitting locally in + boxes waiting for deployment (local spares). The issue is that + operators will be unable to trust devices that have been in an + uncontrolled warehouse as they do not know if those are real devices. + +11.6.2. Compromise of MASA Signing Keys + + There are two periods of time in which to consider: when the MASA key + has fallen into the hands of an attacker and after the MASA + recognizes that the key has been compromised. + +11.6.2.1. Attacker Opportunities with a Compromised MASA Key + + An attacker that has access to the MASA signing key could create + vouchers. These vouchers could be for existing deployed devices or + for devices that are still in a warehouse. In order to exploit these + vouchers, two things need to occur: the device has to go through a + factory default boot cycle, and the registrar has to be convinced to + contact the attacker's MASA. + + If the attacker controls a registrar that is visible to the device, + then there is no difficulty in delivery of the false voucher. A + possible practical example of an attack like this would be in a data + center, at an ISP peering point (whether a public IX or a private + peering point). In such a situation, there are already cables + attached to the equipment that lead to other devices (the peers at + the IX), and through those links, the false voucher could be + delivered. The difficult part would be to put the device through a + factory reset. This might be accomplished through social engineering + of data center staff. Most locked cages have ventilation holes, and + possibly a long "paperclip" could reach through to depress a factory + reset button. Once such a piece of ISP equipment has been + compromised, it could be used to compromise equipment that it was + connected to (through long haul links even), assuming that those + pieces of equipment could also be forced through a factory reset. + + The above scenario seems rather unlikely as it requires some element + of physical access; but if there was a remote exploit that did not + cause a direct breach, but rather a fault that resulted in a factory + reset, this could provide a reasonable path. + + The above deals with ANI uses of BRSKI. For cases where IEEE 802.11 + or 802.15.4 is involved, the need to connect directly to the device + is eliminated, but the need to do a factory reset is not. Physical + possession of the device is not required as above, provided that + there is some way to force a factory reset. With some consumer + devices that have low overall implementation quality, end users might + be familiar with the need to reset the device regularly. + + The authors are unable to come up with an attack scenario where a + compromised voucher signature enables an attacker to introduce a + compromised pledge into an existing operator's network. This is the + case because the operator controls the communication between + registrar and MASA, and there is no opportunity to introduce the fake + voucher through that conduit. + +11.6.2.2. Risks after Key Compromise is Known + + Once the operator of the MASA realizes that the voucher signing key + has been compromised, it has to do a few things. + + First, it MUST issue a firmware update to all devices that had that + key as a trust anchor, such that they will no longer trust vouchers + from that key. This will affect devices in the field that are + operating, but those devices, being in operation, are not performing + onboarding operations, so this is not a critical patch. + + Devices in boxes (in warehouses) are vulnerable and remain vulnerable + until patched. An operator would be prudent to unbox the devices, + onboard them in a safe environment, and then perform firmware + updates. This does not have to be done by the end-operator; it could + be done by a distributor that stores the spares. A recommended + practice for high-value devices (which typically have a <4hr service + window) may be to validate the device operation on a regular basis + anyway. + + If the onboarding process includes attestations about firmware + versions, then through that process, the operator would be advised to + upgrade the firmware before going into production. Unfortunately, + this does not help against situations where the attacker operates + their own registrar (as listed above). + + The need for short-lived vouchers is explained in [RFC8366], + Section 6.1. The nonce guarantees freshness, and the short-lived + nature of the voucher means that the window to deliver a fake voucher + is very short. A nonceless, long-lived voucher would be the only + option for the attacker, and devices in the warehouse would be + vulnerable to such a thing. + + A key operational recommendation is for manufacturers to sign + nonceless, long-lived vouchers with a different key than what is used + to sign short-lived vouchers. That key needs significantly better + protection. If both keys come from a common trust-anchor (the + manufacturer's CA), then a compromise of the manufacturer's CA would + compromise both keys. Such a compromise of the manufacturer's CA + likely compromises all keys outlined in this section. + +11.6.3. Compromise of MASA Web Service + + An attacker that takes over the MASA web service can inflict a number + of attacks. The most obvious one is simply to take the database + listing of customers and devices and sell the data to other attackers + who will now know where to find potentially vulnerable devices. + + The second most obvious thing that the attacker can do is to kill the + service, or make it operate unreliably, making customers frustrated. + This could have a serious effect on the ability to deploy new + services by customers and would be a significant issue during + disaster recovery. + + While the compromise of the MASA web service may lead to the + compromise of the MASA voucher signing key, if the signing occurs + offboard (such as in a hardware signing module (HSM)), then the key + may well be safe, but control over it resides with the attacker. + + Such an attacker can issue vouchers for any device presently in + service. Said device still needs to be convinced to go through a + factory reset process before an attack. + + If the attacker has access to a key that is trusted for long-lived + nonceless vouchers, then they could issue vouchers for devices that + are not yet in service. This attack may be very hard to verify as it + would involve doing firmware updates on every device in warehouses (a + potentially ruinously expensive process); a manufacturer might be + reluctant to admit this possibility. + +11.7. YANG Module Security Considerations + + As described in Section 7.4 (Security Considerations) of [RFC8366], + the YANG module specified in this document defines the schema for + data that is subsequently encapsulated by a CMS signed-data content + type, as described in Section 5 of [RFC5652]. As such, all of the + YANG-modeled data is protected from modification. + + The use of YANG to define data structures, via the "yang-data" + statement, is relatively new and distinct from the traditional use of + YANG to define an API accessed by network management protocols such + as NETCONF [RFC6241] and RESTCONF [RFC8040]. For this reason, these + guidelines do not follow the template described by Section 3.7 of + [RFC8407]. + +12. References + +12.1. Normative References + + [IDevID] IEEE, "IEEE Standard for Local and metropolitan area + networks - Secure Device Identity", IEEE 802.1AR, + <https://1.ieee802.org/security/802-1ar>. + + [ITU.X690] ITU-T, "Information Technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), Canonical + Encoding Rules (CER) and Distinguished Encoding Rules + (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2015, + August 2015, <https://www.itu.int/rec/T-REC-X.690>. + + [REST] Fielding, R.F., "Architectural Styles and the Design of + Network-based Software Architectures", 2000, + <http://www.ics.uci.edu/~fielding/pubs/dissertation/ + fielding_dissertation.pdf>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: + Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, + <https://www.rfc-editor.org/info/rfc3339>. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + <https://www.rfc-editor.org/info/rfc3688>. + + [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. + Levkowetz, Ed., "Extensible Authentication Protocol + (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, + <https://www.rfc-editor.org/info/rfc3748>. + + [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic + Configuration of IPv4 Link-Local Addresses", RFC 3927, + DOI 10.17487/RFC3927, May 2005, + <https://www.rfc-editor.org/info/rfc3927>. + + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + DOI 10.17487/RFC4086, June 2005, + <https://www.rfc-editor.org/info/rfc4086>. + + [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol + (LDAP): Schema for User Applications", RFC 4519, + DOI 10.17487/RFC4519, June 2006, + <https://www.rfc-editor.org/info/rfc4519>. + + [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, + <https://www.rfc-editor.org/info/rfc4648>. + + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", RFC 4862, + DOI 10.17487/RFC4862, September 2007, + <https://www.rfc-editor.org/info/rfc4862>. + + [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS + (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, + <https://www.rfc-editor.org/info/rfc5272>. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + <https://www.rfc-editor.org/info/rfc5280>. + + [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, + RFC 5652, DOI 10.17487/RFC5652, September 2009, + <https://www.rfc-editor.org/info/rfc5652>. + + [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for + the Network Configuration Protocol (NETCONF)", RFC 6020, + DOI 10.17487/RFC6020, October 2010, + <https://www.rfc-editor.org/info/rfc6020>. + + [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and + Verification of Domain-Based Application Service Identity + within Internet Public Key Infrastructure Using X.509 + (PKIX) Certificates in the Context of Transport Layer + Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March + 2011, <https://www.rfc-editor.org/info/rfc6125>. + + [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., + and A. Bierman, Ed., "Network Configuration Protocol + (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, + <https://www.rfc-editor.org/info/rfc6241>. + + [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, + DOI 10.17487/RFC6762, February 2013, + <https://www.rfc-editor.org/info/rfc6762>. + + [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service + Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, + <https://www.rfc-editor.org/info/rfc6763>. + + [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., + "Enrollment over Secure Transport", RFC 7030, + DOI 10.17487/RFC7030, October 2013, + <https://www.rfc-editor.org/info/rfc7030>. + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, DOI 10.17487/RFC7230, June 2014, + <https://www.rfc-editor.org/info/rfc7230>. + + [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Semantics and Content", RFC 7231, + DOI 10.17487/RFC7231, June 2014, + <https://www.rfc-editor.org/info/rfc7231>. + + [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning + Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April + 2015, <https://www.rfc-editor.org/info/rfc7469>. + + [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", + RFC 7950, DOI 10.17487/RFC7950, August 2016, + <https://www.rfc-editor.org/info/rfc7950>. + + [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", + RFC 7951, DOI 10.17487/RFC7951, August 2016, + <https://www.rfc-editor.org/info/rfc7951>. + + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF + Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, + <https://www.rfc-editor.org/info/rfc8040>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data + Interchange Format", STD 90, RFC 8259, + DOI 10.17487/RFC8259, December 2017, + <https://www.rfc-editor.org/info/rfc8259>. + + [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, + "A Voucher Artifact for Bootstrapping Protocols", + RFC 8366, DOI 10.17487/RFC8366, May 2018, + <https://www.rfc-editor.org/info/rfc8366>. + + [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic + Control Plane for Stable Connectivity of Network + Operations, Administration, and Maintenance (OAM)", + RFC 8368, DOI 10.17487/RFC8368, May 2018, + <https://www.rfc-editor.org/info/rfc8368>. + + [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of + Documents Containing YANG Data Models", BCP 216, RFC 8407, + DOI 10.17487/RFC8407, October 2018, + <https://www.rfc-editor.org/info/rfc8407>. + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + + [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data + Definition Language (CDDL): A Notational Convention to + Express Concise Binary Object Representation (CBOR) and + JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, + June 2019, <https://www.rfc-editor.org/info/rfc8610>. + + [RFC8951] Richardson, M., Werner, T., and W. Pan, "Clarification of + Enrollment over Secure Transport (EST): Transfer Encodings + and ASN.1", RFC 8951, DOI 10.17487/RFC8951, November 2020, + <https://www.rfc-editor.org/info/rfc8951>. + + [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, + "Temporary Address Extensions for Stateless Address + Autoconfiguration in IPv6", RFC 8981, + DOI 10.17487/RFC8981, February 2021, + <https://www.rfc-editor.org/info/rfc8981>. + + [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic + Autonomic Signaling Protocol (GRASP)", RFC 8990, + DOI 10.17487/RFC8990, May 2021, + <https://www.rfc-editor.org/rfc/rfc8990>. + + [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An + Autonomic Control Plane (ACP)", RFC 8994, + DOI 10.17487/RFC8994, May 2021, + <https://www.rfc-editor.org/rfc/rfc8994>. + +12.2. Informative References + + [ACE-COAP-EST] + van der Stok, P., Kampanakis, P., Richardson, M., and S. + Raza, "EST over secure CoAP (EST-coaps)", Work in + Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6 + January 2020, + <https://tools.ietf.org/html/draft-ietf-ace-coap-est-18>. + + [ANIMA-CONSTRAINED-VOUCHER] + Richardson, M., van der Stok, P., Kampanakis, P., and E. + Dijk, "Constrained Voucher Artifacts for Bootstrapping + Protocols", Work in Progress, Internet-Draft, draft-ietf- + anima-constrained-voucher-10, 21 February 2021, + <https://tools.ietf.org/html/draft-ietf-anima-constrained- + voucher-10>. + + [ANIMA-STATE] + Richardson, M., "Considerations for stateful vs stateless + join router in ANIMA bootstrap", Work in Progress, + Internet-Draft, draft-richardson-anima-state-for- + joinrouter-03, 22 September 2020, + <https://tools.ietf.org/html/draft-richardson-anima-state- + for-joinrouter-03>. + + [brewski] Urban Dictionary, "brewski", March 2003, + <https://www.urbandictionary.com/define.php?term=brewski>. + + [cabforumaudit] + CA/Browser Forum, "Information for Auditors and + Assessors", August 2019, <https://cabforum.org/ + information-for-auditors-and-assessors/>. + + [Dingledine] + Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The + Second-Generation Onion Router", August 2004, + <https://svn-archive.torproject.org/svn/projects/design- + paper/tor-design.pdf>. + + [dnssecroot] + "DNSSEC Practice Statement for the Root Zone ZSK + Operator", December 2017, + <https://www.iana.org/dnssec/procedures/zsk-operator/dps- + zsk-operator-v2.1.pdf>. + + [docsisroot] + "CableLabs Digital Certificate Issuance Service", February + 2018, <https://www.cablelabs.com/resources/digital- + certificate-issuance-service/>. + + [imprinting] + Wikipedia, "Imprinting (psychology)", January 2021, + <https://en.wikipedia.org/w/ + index.php?title=Imprinting_(psychology)&=999211441>. + + [IoTstrangeThings] + ESET, "IoT of toys stranger than fiction: Cybersecurity + and data privacy update", March 2017, + <https://www.welivesecurity.com/2017/03/03/internet-of- + things-security-privacy-iot-update/>. + + [livingwithIoT] + Silicon Republic, "What is it actually like to live in a + house filled with IoT devices?", February 2018, + <https://www.siliconrepublic.com/machines/iot-smart- + devices-reality>. + + [minerva] Richardson, M., "Minerva reference implementation for + BRSKI", 2020, <https://minerva.sandelman.ca/>. + + [minervagithub] + "ANIMA Minerva toolkit", + <https://github.com/ANIMAgus-minerva>. + + [openssl] OpenSSL, "OpenSSL X509 Utility", September 2019, + <https://www.openssl.org/docs/man1.1.1/man1/openssl- + x509.html/>. + + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", + RFC 2131, DOI 10.17487/RFC2131, March 1997, + <https://www.rfc-editor.org/info/rfc2131>. + + [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address + Translator (NAT) Terminology and Considerations", + RFC 2663, DOI 10.17487/RFC2663, August 1999, + <https://www.rfc-editor.org/info/rfc2663>. + + [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. + Tardo, "Network Endpoint Assessment (NEA): Overview and + Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, + <https://www.rfc-editor.org/info/rfc5209>. + + [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., + Galperin, S., and C. Adams, "X.509 Internet Public Key + Infrastructure Online Certificate Status Protocol - OCSP", + RFC 6960, DOI 10.17487/RFC6960, June 2013, + <https://www.rfc-editor.org/info/rfc6960>. + + [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) + Multiple Certificate Status Request Extension", RFC 6961, + DOI 10.17487/RFC6961, June 2013, + <https://www.rfc-editor.org/info/rfc6961>. + + [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for + Constrained-Node Networks", RFC 7228, + DOI 10.17487/RFC7228, May 2014, + <https://www.rfc-editor.org/info/rfc7228>. + + [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an + Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May + 2014, <https://www.rfc-editor.org/info/rfc7258>. + + [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection + Most of the Time", RFC 7435, DOI 10.17487/RFC7435, + December 2014, <https://www.rfc-editor.org/info/rfc7435>. + + [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., + Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic + Networking: Definitions and Design Goals", RFC 7575, + DOI 10.17487/RFC7575, June 2015, + <https://www.rfc-editor.org/info/rfc7575>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + + [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", + BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, + <https://www.rfc-editor.org/info/rfc8340>. + + [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers + (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, + <https://www.rfc-editor.org/info/rfc8615>. + + [RFC8993] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia, + L., and J. Nobre, "A Reference Model for Autonomic + Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021, + <https://www.rfc-editor.org/info/rfc8993>. + + [slowloris] + Wikipedia, "Slowloris (computer security)", January 2021, + <https://en.wikipedia.org/w/index.php?title=Slowloris_(com + puter_security)&oldid=1001473290/>. + + [softwareescrow] + Wikipedia, "Source code escrow", March 2020, + <https://en.wikipedia.org/w/ + index.php?title=Source_code_escrow&oldid=948073074>. + + [Stajano99theresurrecting] + Stajano, F. and R. Anderson, "The Resurrecting Duckling: + Security Issues for Ad-hoc Wireless Networks", 1999, + <https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd- + duckling.pdf>. + + [TR069] Broadband Forum, "CPE WAN Management Protocol", TR-069, + Issue 1, Amendment 6, March 2018, <https://www.broadband- + forum.org/download/TR-069_Amendment-6.pdf>. + + [W3C.capability-urls] + Tennison, J., "Good Practices for Capability URLs", W3C + First Public Working Draft, World Wide Web Consortium WD + WD-capability-urls-20140218, February 2014, + <https://www.w3.org/TR/2014/WD-capability-urls>. + + [YANG-KEYSTORE] + Watsen, K., "A YANG Data Model for a Keystore", Work in + Progress, Internet-Draft, draft-ietf-netconf-keystore-22, + 18 May 2021, <https://tools.ietf.org/html/draft-ietf- + netconf-keystore-22>. + +Appendix A. IPv4 and Non-ANI Operations + + The specification of BRSKI in Section 4 intentionally covers only the + mechanisms for an IPv6 pledge using link-local addresses. This + section describes non-normative extensions that can be used in other + environments. + +A.1. IPv4 Link-Local Addresses + + Instead of an IPv6 link-local address, an IPv4 address may be + generated using "Dynamic Configuration of IPv4 Link-Local Addresses" + [RFC3927]. + + In the case where an IPv4 link-local address is formed, the bootstrap + process would continue, as in an IPv6 case, by looking for a + (circuit) proxy. + +A.2. Use of DHCPv4 + + The pledge MAY obtain an IP address via DHCP ([RFC2131]. The DHCP- + provided parameters for the Domain Name System can be used to perform + DNS operations if all local discovery attempts fail. + +Appendix B. mDNS / DNS-SD Proxy Discovery Options + + Pledge discovery of the proxy (Section 4.1) MAY be performed with + DNS-based Service Discovery [RFC6763] over Multicast DNS [RFC6762] to + discover the proxy at "_brski-proxy._tcp.local.". + + Proxy discovery of the registrar (Section 4.3) MAY be performed with + DNS-based Service Discovery over Multicast DNS to discover registrars + by searching for the service "_brski-registrar._tcp.local.". + + To prevent unacceptable levels of network traffic, when using mDNS, + the congestion avoidance mechanisms specified in [RFC6762], Section 7 + MUST be followed. The pledge SHOULD listen for an unsolicited + broadcast response as described in [RFC6762]. This allows devices to + avoid announcing their presence via mDNS broadcasts and instead + silently join a network by watching for periodic unsolicited + broadcast responses. + + Discovery of the registrar MAY also be performed with DNS-based + Service Discovery by searching for the service "_brski- + registrar._tcp.example.com". In this case, the domain "example.com" + is discovered as described in [RFC6763], Section 11 (Appendix A.2 of + this document suggests the use of DHCP parameters). + + If no local proxy or registrar service is located using the GRASP + mechanisms or the above-mentioned DNS-based Service Discovery + methods, the pledge MAY contact a well-known manufacturer-provided + bootstrapping server by performing a DNS lookup using a well-known + URI such as "brski-registrar.manufacturer.example.com". The details + of the URI are manufacturer specific. Manufacturers that leverage + this method on the pledge are responsible for providing the registrar + service. Also see Section 2.7. + + The current DNS services returned during each query are maintained + until bootstrapping is completed. If bootstrapping fails and the + pledge returns to the Discovery state, it picks up where it left off + and continues attempting bootstrapping. For example, if the first + Multicast DNS _bootstrapks._tcp.local response doesn't work, then the + second and third responses are tried. If these fail, the pledge + moves on to normal DNS-based Service Discovery. + +Appendix C. Example Vouchers + + Three entities are involved in a voucher: the MASA issues (signs) it, + the registrar's public key is mentioned in it, and the pledge + validates it. In order to provide reproducible examples, the public + and private keys for an example MASA and registrar are listed first. + + The keys come from an open source reference implementation of BRSKI, + called "Minerva" [minerva]. It is available on GitHub + [minervagithub]. The keys presented here are used in the unit and + integration tests. The MASA code is called "highway", the registrar + code is called "fountain", and the example client is called "reach". + + The public key components of each are presented as base64 + certificates and are decoded by openssl's x509 utility so that the + extensions can be seen. This was version 1.1.1c of the library and + utility of [openssl]. + +C.1. Keys Involved + + The manufacturer has a CA that signs the pledge's IDevID. In + addition, the Manufacturer's signing authority (the MASA) signs the + vouchers, and that certificate must distributed to the devices at + manufacturing time so that vouchers can be validated. + +C.1.1. Manufacturer Certification Authority for IDevID Signatures + + This private key is the CA that signs IDevID certificates: + + <CODE BEGINS> file "vendor.key" + -----BEGIN EC PRIVATE KEY----- + MIGkAgEBBDCAYkoLW1IEA5SKKhMMdkTK7sJxk5ybKqYq9Yr5aR7tNwqXyLGS7z8G + 8S4w/UJ58BqgBwYFK4EEACKhZANiAAQu5/yktJbFLjMC87h7b+yTreFuF8GwewKH + L4mS0r0dVAQubqDUQcTrjvpXrXCpTojiLCzgp8fzkcUDkZ9LD/M90LDipiLNIOkP + juF8QkoAbT8pMrY83MS8y76wZ7AalNQ= + -----END EC PRIVATE KEY----- + <CODE ENDS> + + This public key validates IDevID certificates: + + file: examples/vendor.key + + <CODE BEGINS> file "vendor.cert" + Certificate: + Data: + Version: 3 (0x2) + Serial Number: 1216069925 (0x487bc125) + Signature Algorithm: ecdsa-with-SHA256 + Issuer: CN = highway-test.example.com CA + Validity + Not Before: Apr 13 20:34:24 2021 GMT + Not After : Apr 13 20:34:24 2023 GMT + Subject: CN = highway-test.example.com CA + Subject Public Key Info: + Public Key Algorithm: id-ecPublicKey + Public-Key: (384 bit) + pub: + 04:2e:e7:fc:a4:b4:96:c5:2e:33:02:f3:b8:7b:6f: + ec:93:ad:e1:6e:17:c1:b0:7b:02:87:2f:89:92:d2: + bd:1d:54:04:2e:6e:a0:d4:41:c4:eb:8e:fa:57:ad: + 70:a9:4e:88:e2:2c:2c:e0:a7:c7:f3:91:c5:03:91: + 9f:4b:0f:f3:3d:d0:b0:e2:a6:22:cd:20:e9:0f:8e: + e1:7c:42:4a:00:6d:3f:29:32:b6:3c:dc:c4:bc:cb: + be:b0:67:b0:1a:94:d4 + ASN1 OID: secp384r1 + NIST CURVE: P-384 + X509v3 extensions: + X509v3 Basic Constraints: critical + CA:TRUE + X509v3 Key Usage: critical + Certificate Sign, CRL Sign + X509v3 Subject Key Identifier: + 5E:0C:A9:52:5A:8C:DF:A9:0F:03:14:E9:96:F1:80:76: + 8C:53:8A:08 + X509v3 Authority Key Identifier: + keyid:5E:0C:A9:52:5A:8C:DF:A9:0F:03:14:E9:96:F1: + 80:76:8C:53:8A:08 + + Signature Algorithm: ecdsa-with-SHA256 + 30:64:02:30:60:37:a0:66:89:80:27:e1:0d:e5:43:9a:62:f1: + 02:bc:0f:72:6d:a9:e9:cb:84:a5:c6:44:d3:41:9e:5d:ce:7d: + 46:16:6e:15:de:f7:cc:e8:3e:61:f9:03:7c:20:c4:b7:02:30: + 7f:e9:f3:12:bb:06:c6:24:00:2b:41:aa:21:6b:d8:25:ed:81: + 07:11:ef:66:8f:06:bf:c8:be:f0:58:74:24:45:39:4d:04:fc: + 31:69:6f:cf:db:fe:61:7b:c3:24:31:ff + -----BEGIN CERTIFICATE----- + MIIB3TCCAWSgAwIBAgIESHvBJTAKBggqhkjOPQQDAjAmMSQwIgYDVQQDDBtoaWdo + d2F5LXRlc3QuZXhhbXBsZS5jb20gQ0EwHhcNMjEwNDEzMjAzNDI0WhcNMjMwNDEz + MjAzNDI0WjAmMSQwIgYDVQQDDBtoaWdod2F5LXRlc3QuZXhhbXBsZS5jb20gQ0Ew + djAQBgcqhkjOPQIBBgUrgQQAIgNiAAQu5/yktJbFLjMC87h7b+yTreFuF8GwewKH + L4mS0r0dVAQubqDUQcTrjvpXrXCpTojiLCzgp8fzkcUDkZ9LD/M90LDipiLNIOkP + juF8QkoAbT8pMrY83MS8y76wZ7AalNSjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYD + VR0PAQH/BAQDAgEGMB0GA1UdDgQWBBReDKlSWozfqQ8DFOmW8YB2jFOKCDAfBgNV + HSMEGDAWgBReDKlSWozfqQ8DFOmW8YB2jFOKCDAKBggqhkjOPQQDAgNnADBkAjBg + N6BmiYAn4Q3lQ5pi8QK8D3JtqenLhKXGRNNBnl3OfUYWbhXe98zoPmH5A3wgxLcC + MH/p8xK7BsYkACtBqiFr2CXtgQcR72aPBr/IvvBYdCRFOU0E/DFpb8/b/mF7wyQx + /w== + -----END CERTIFICATE----- + <CODE ENDS> + +C.1.2. MASA Key Pair for Voucher Signatures + + The MASA is the Manufacturer Authorized Signing Authority. This key + pair signs vouchers. An example TLS certificate (see Section 5.4) + HTTP authentication is not provided as it is a common form. + + This private key signs the vouchers that are presented below: + + <CODE BEGINS> file "masa.key" + -----BEGIN EC PRIVATE KEY----- + MHcCAQEEIFhdd0eDdzip67kXx72K+KHGJQYJHNy8pkiLJ6CcvxMGoAoGCCqGSM49 + AwEHoUQDQgAEqgQVo0S54kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+ + gqi4tMFfSJ0iEwt8kszfWXK4rLgJS2mnpQ== + -----END EC PRIVATE KEY----- + <CODE ENDS> + + This public key validates vouchers, and it has been signed by the CA + above: + + file: examples/masa.key + + <CODE BEGINS> file "masa.cert" + Certificate: + Data: + Version: 3 (0x2) + Serial Number: 193399345 (0xb870a31) + Signature Algorithm: ecdsa-with-SHA256 + Issuer: CN = highway-test.example.com CA + Validity + Not Before: Apr 13 21:40:16 2021 GMT + Not After : Apr 13 21:40:16 2023 GMT + Subject: CN = highway-test.example.com MASA + Subject Public Key Info: + Public Key Algorithm: id-ecPublicKey + Public-Key: (256 bit) + pub: + 04:aa:04:15:a3:44:b9:e2:44:f8:c9:f9:1b:07:1b: + a6:74:73:9c:1e:ba:6c:a9:b3:a9:30:a9:a2:32:59: + f7:a0:1d:47:01:6d:b9:30:95:7e:82:a8:b8:b4:c1: + 5f:48:9d:22:13:0b:7c:92:cc:df:59:72:b8:ac:b8: + 09:4b:69:a7:a5 + ASN1 OID: prime256v1 + NIST CURVE: P-256 + X509v3 extensions: + X509v3 Basic Constraints: critical + CA:FALSE + Signature Algorithm: ecdsa-with-SHA256 + 30:66:02:31:00:ae:cb:61:2d:d4:5c:8d:6e:86:aa:0b:06:1d: + c6:d3:60:ba:32:73:36:25:d3:23:85:49:87:1c:ce:94:23:79: + 1a:9e:41:55:24:1d:15:22:a1:48:bb:0a:c0:ab:3c:13:73:02: + 31:00:86:3c:67:b3:95:a2:e2:e5:f9:ad:f9:1d:9c:c1:34:32: + 78:f5:cf:ea:d5:47:03:9f:00:bf:d0:59:cb:51:c2:98:04:81: + 24:8a:51:13:50:b1:75:b2:2f:9d:a8:b4:f4:b9 + -----BEGIN CERTIFICATE----- + MIIBcDCB9qADAgECAgQLhwoxMAoGCCqGSM49BAMCMCYxJDAiBgNVBAMMG2hpZ2h3 + YXktdGVzdC5leGFtcGxlLmNvbSBDQTAeFw0yMTA0MTMyMTQwMTZaFw0yMzA0MTMy + MTQwMTZaMCgxJjAkBgNVBAMMHWhpZ2h3YXktdGVzdC5leGFtcGxlLmNvbSBNQVNB + MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqgQVo0S54kT4yfkbBxumdHOcHrps + qbOpMKmiMln3oB1HAW25MJV+gqi4tMFfSJ0iEwt8kszfWXK4rLgJS2mnpaMQMA4w + DAYDVR0TAQH/BAIwADAKBggqhkjOPQQDAgNpADBmAjEArsthLdRcjW6GqgsGHcbT + YLoyczYl0yOFSYcczpQjeRqeQVUkHRUioUi7CsCrPBNzAjEAhjxns5Wi4uX5rfkd + nME0Mnj1z+rVRwOfAL/QWctRwpgEgSSKURNQsXWyL52otPS5 + -----END CERTIFICATE----- + <CODE ENDS> + +C.1.3. Registrar Certification Authority + + This CA enrolls the pledge once it is authorized, and it also signs + the registrar's certificate. + + <CODE BEGINS> file "ownerca_secp384r1.key" + -----BEGIN EC PRIVATE KEY----- + MIGkAgEBBDCHnLI0MSOLf8XndiZqoZdqblcPR5YSoPGhPOuFxWy1gFi9HbWv8b/R + EGdRgGEVSjKgBwYFK4EEACKhZANiAAQbf1m6F8MavGaNjGzgw/oxcQ9l9iKRvbdW + gAfb37h6pUVNeYpGlxlZljGxj2l9Mr48yD5bY7VG9qjVb5v5wPPTuRQ/ckdRpHbd + 0vC/9cqPMAF/+MJf0/UgA0SLi/IHbLQ= + -----END EC PRIVATE KEY----- + <CODE ENDS> + + The public key is indicated in a pledge voucher-request to show + proximity. + + file: examples/ownerca_secp384r1.key + + <CODE BEGINS> file "ownerca_secp384r1.cert" + Certificate: + Data: + Version: 3 (0x2) + Serial Number: 694879833 (0x296b0659) + Signature Algorithm: ecdsa-with-SHA256 + Issuer: DC = ca, DC = sandelman, + CN = fountain-test.example.com Unstrung Fountain Root CA + Validity + Not Before: Feb 25 21:31:45 2020 GMT + Not After : Feb 24 21:31:45 2022 GMT + Subject: DC = ca, DC = sandelman, + CN = fountain-test.example.com Unstrung Fountain Root CA + Subject Public Key Info: + Public Key Algorithm: id-ecPublicKey + Public-Key: (384 bit) + pub: + 04:1b:7f:59:ba:17:c3:1a:bc:66:8d:8c:6c:e0:c3: + fa:31:71:0f:65:f6:22:91:bd:b7:56:80:07:db:df: + b8:7a:a5:45:4d:79:8a:46:97:19:59:96:31:b1:8f: + 69:7d:32:be:3c:c8:3e:5b:63:b5:46:f6:a8:d5:6f: + 9b:f9:c0:f3:d3:b9:14:3f:72:47:51:a4:76:dd:d2: + f0:bf:f5:ca:8f:30:01:7f:f8:c2:5f:d3:f5:20:03: + 44:8b:8b:f2:07:6c:b4 + ASN1 OID: secp384r1 + NIST CURVE: P-384 + X509v3 extensions: + X509v3 Basic Constraints: critical + CA:TRUE + X509v3 Key Usage: critical + Certificate Sign, CRL Sign + X509v3 Subject Key Identifier: + B9:A5:F6:CB:11:E1:07:A4:49:2C:A7:08:C6:7C:10:BC: + 87:B3:74:26 + X509v3 Authority Key Identifier: + keyid:B9:A5:F6:CB:11:E1:07:A4:49:2C:A7:08:C6:7C: + 10:BC:87:B3:74:26 + + Signature Algorithm: ecdsa-with-SHA256 + 30:64:02:30:20:83:06:ce:8d:98:a4:54:7a:66:4c:4a:3a:70: + c2:52:36:5a:52:8d:59:7d:20:9b:2a:69:14:58:87:38:d8:55: + 79:dd:fd:29:38:95:1e:91:93:76:b4:f5:66:29:44:b4:02:30: + 6f:38:f9:af:12:ed:30:d5:85:29:7c:b1:16:58:bd:67:91:43: + c4:0d:30:f9:d8:1c:ac:2f:06:dd:bc:d5:06:42:2c:84:a2:04: + ea:02:a4:5f:17:51:26:fb:d9:2f:d2:5c + -----BEGIN CERTIFICATE----- + MIICazCCAfKgAwIBAgIEKWsGWTAKBggqhkjOPQQDAjBtMRIwEAYKCZImiZPyLGQB + GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xPDA6BgNVBAMMM2ZvdW50 + YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9vdCBDQTAe + Fw0yMDAyMjUyMTMxNDVaFw0yMjAyMjQyMTMxNDVaMG0xEjAQBgoJkiaJk/IsZAEZ + FgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjE8MDoGA1UEAwwzZm91bnRh + aW4tdGVzdC5leGFtcGxlLmNvbSBVbnN0cnVuZyBGb3VudGFpbiBSb290IENBMHYw + EAYHKoZIzj0CAQYFK4EEACIDYgAEG39ZuhfDGrxmjYxs4MP6MXEPZfYikb23VoAH + 29+4eqVFTXmKRpcZWZYxsY9pfTK+PMg+W2O1Rvao1W+b+cDz07kUP3JHUaR23dLw + v/XKjzABf/jCX9P1IANEi4vyB2y0o2MwYTAPBgNVHRMBAf8EBTADAQH/MA4GA1Ud + DwEB/wQEAwIBBjAdBgNVHQ4EFgQUuaX2yxHhB6RJLKcIxnwQvIezdCYwHwYDVR0j + BBgwFoAUuaX2yxHhB6RJLKcIxnwQvIezdCYwCgYIKoZIzj0EAwIDZwAwZAIwIIMG + zo2YpFR6ZkxKOnDCUjZaUo1ZfSCbKmkUWIc42FV53f0pOJUekZN2tPVmKUS0AjBv + OPmvEu0w1YUpfLEWWL1nkUPEDTD52BysLwbdvNUGQiyEogTqAqRfF1Em+9kv0lw= + -----END CERTIFICATE----- + <CODE ENDS> + +C.1.4. Registrar Key Pair + + The registrar is the representative of the domain owner. This key + signs registrar voucher-requests and terminates the TLS connection + from the pledge. + + <CODE BEGINS> file "jrc_prime256v1.key" + -----BEGIN EC PRIVATE KEY----- + MHcCAQEEIFZodk+PC5Mu24+ra0sbOjKzan+dW5rvDAR7YuJUOC1YoAoGCCqGSM49 + AwEHoUQDQgAElmVQcjS6n+Xd5l/28IFv6UiegQwSBztGj5dkK2MAjQIPV8l8lH+E + jLIOYdbJiI0VtEIf1/Jqt+TOBfinTNOLOg== + -----END EC PRIVATE KEY----- + <CODE ENDS> + + The public key is indicated in a pledge voucher-request to show + proximity. + + <CODE BEGINS> file "jrc_prime256v1.cert" + Certificate: + Data: + Version: 3 (0x2) + Serial Number: 1066965842 (0x3f989b52) + Signature Algorithm: ecdsa-with-SHA256 + Issuer: DC = ca, DC = sandelman, + CN = fountain-test.example.com Unstrung Fountain Root CA + Validity + Not Before: Feb 25 21:31:54 2020 GMT + Not After : Feb 24 21:31:54 2022 GMT + Subject: DC = ca, DC = sandelman, + CN = fountain-test.example.com + Subject Public Key Info: + Public Key Algorithm: id-ecPublicKey + Public-Key: (256 bit) + pub: + 04:96:65:50:72:34:ba:9f:e5:dd:e6:5f:f6:f0:81: + 6f:e9:48:9e:81:0c:12:07:3b:46:8f:97:64:2b:63: + 00:8d:02:0f:57:c9:7c:94:7f:84:8c:b2:0e:61:d6: + c9:88:8d:15:b4:42:1f:d7:f2:6a:b7:e4:ce:05:f8: + a7:4c:d3:8b:3a + ASN1 OID: prime256v1 + NIST CURVE: P-256 + X509v3 extensions: + X509v3 Extended Key Usage: critical + CMC Registration Authority + X509v3 Key Usage: critical + Digital Signature + Signature Algorithm: ecdsa-with-SHA256 + 30:65:02:30:66:4f:60:4c:55:48:1e:96:07:f8:dd:1f:b9:c8: + 12:8d:45:36:87:9b:23:c0:bc:bb:f1:cb:3d:26:15:56:6f:5f: + 1f:bf:d5:1c:0e:6a:09:af:1b:76:97:99:19:23:fd:7e:02:31: + 00:bc:ac:c3:41:b0:ba:0d:af:52:f9:9c:6e:7a:7f:00:1d:23: + c8:62:01:61:bc:4b:c5:c0:47:99:35:0a:0c:77:61:44:01:4a: + 07:52:70:57:00:75:ff:be:07:0e:98:cb:e5 + -----BEGIN CERTIFICATE----- + MIIB/DCCAYKgAwIBAgIEP5ibUjAKBggqhkjOPQQDAjBtMRIwEAYKCZImiZPyLGQB + GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xPDA6BgNVBAMMM2ZvdW50 + YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9vdCBDQTAe + Fw0yMDAyMjUyMTMxNTRaFw0yMjAyMjQyMTMxNTRaMFMxEjAQBgoJkiaJk/IsZAEZ + FgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjEiMCAGA1UEAwwZZm91bnRh + aW4tdGVzdC5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJZl + UHI0up/l3eZf9vCBb+lInoEMEgc7Ro+XZCtjAI0CD1fJfJR/hIyyDmHWyYiNFbRC + H9fyarfkzgX4p0zTizqjKjAoMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMcMA4GA1Ud + DwEB/wQEAwIHgDAKBggqhkjOPQQDAgNoADBlAjBmT2BMVUgelgf43R+5yBKNRTaH + myPAvLvxyz0mFVZvXx+/1RwOagmvG3aXmRkj/X4CMQC8rMNBsLoNr1L5nG56fwAd + I8hiAWG8S8XAR5k1Cgx3YUQBSgdScFcAdf++Bw6Yy+U= + -----END CERTIFICATE----- + <CODE ENDS> + +C.1.5. Pledge Key Pair + + The pledge has an IDevID key pair built in at manufacturing time: + + <CODE BEGINS> file "idevid_00-D0-E5-F2-00-02.key" + -----BEGIN EC PRIVATE KEY----- + MHcCAQEEIBHNh6r8QRevRuo+tEmBJeFjQKf6bpFA/9NGoltv+9sNoAoGCCqGSM49 + AwEHoUQDQgAEA6N1Q4ezfMAKmoecrfb0OBMc1AyEH+BATkF58FsTSyBxs0SbSWLx + FjDOuwB9gLGn2TsTUJumJ6VPw5Z/TP4hJw== + -----END EC PRIVATE KEY----- + <CODE ENDS> + + The certificate is used by the registrar to find the MASA. + + <CODE BEGINS> file "idevid_00-D0-E5-F2-00-02.cert" + Certificate: + Data: + Version: 3 (0x2) + Serial Number: 521731815 (0x1f18fee7) + Signature Algorithm: ecdsa-with-SHA256 + Issuer: CN = highway-test.example.com CA + Validity + Not Before: Apr 27 18:29:30 2021 GMT + Not After : Dec 31 00:00:00 2999 GMT + Subject: serialNumber = 00-D0-E5-F2-00-02 + Subject Public Key Info: + Public Key Algorithm: id-ecPublicKey + Public-Key: (256 bit) + pub: + 04:03:a3:75:43:87:b3:7c:c0:0a:9a:87:9c:ad:f6: + f4:38:13:1c:d4:0c:84:1f:e0:40:4e:41:79:f0:5b: + 13:4b:20:71:b3:44:9b:49:62:f1:16:30:ce:bb:00: + 7d:80:b1:a7:d9:3b:13:50:9b:a6:27:a5:4f:c3:96: + 7f:4c:fe:21:27 + ASN1 OID: prime256v1 + NIST CURVE: P-256 + X509v3 extensions: + X509v3 Subject Key Identifier: + 45:88:CC:96:96:00:64:37:B0:BA:23:65:64:64:54:08: + 06:6C:56:AD + X509v3 Basic Constraints: + CA:FALSE + 1.3.6.1.5.5.7.1.32: + ..highway-test.example.com:9443 + Signature Algorithm: ecdsa-with-SHA256 + 30:65:02:30:62:2a:db:be:34:f7:1b:cb:85:de:26:8e:43:00: + f9:0d:88:c8:77:a8:dd:3c:08:40:54:bc:ec:3d:b6:dc:70:2b: + c3:7f:ca:19:21:9a:a0:ab:c5:51:8e:aa:df:36:de:8b:02:31: + 00:b2:5d:59:f8:47:c7:ed:03:97:a8:c0:c7:a8:81:fa:a8:86: + ed:67:64:37:51:7a:6e:9c:a3:82:4d:6d:ad:bc:f3:35:9e:9d: + 6a:a2:6d:7f:7f:25:1c:03:ef:f0:ba:9b:71 + -----BEGIN CERTIFICATE----- + MIIBrzCCATWgAwIBAgIEHxj+5zAKBggqhkjOPQQDAjAmMSQwIgYDVQQDDBtoaWdo + d2F5LXRlc3QuZXhhbXBsZS5jb20gQ0EwIBcNMjEwNDI3MTgyOTMwWhgPMjk5OTEy + MzEwMDAwMDBaMBwxGjAYBgNVBAUTETAwLUQwLUU1LUYyLTAwLTAyMFkwEwYHKoZI + zj0CAQYIKoZIzj0DAQcDQgAEA6N1Q4ezfMAKmoecrfb0OBMc1AyEH+BATkF58FsT + SyBxs0SbSWLxFjDOuwB9gLGn2TsTUJumJ6VPw5Z/TP4hJ6NZMFcwHQYDVR0OBBYE + FEWIzJaWAGQ3sLojZWRkVAgGbFatMAkGA1UdEwQCMAAwKwYIKwYBBQUHASAEHxYd + aGlnaHdheS10ZXN0LmV4YW1wbGUuY29tOjk0NDMwCgYIKoZIzj0EAwIDaAAwZQIw + YirbvjT3G8uF3iaOQwD5DYjId6jdPAhAVLzsPbbccCvDf8oZIZqgq8VRjqrfNt6L + AjEAsl1Z+EfH7QOXqMDHqIH6qIbtZ2Q3UXpunKOCTW2tvPM1np1qom1/fyUcA+/w + uptx + -----END CERTIFICATE----- + <CODE ENDS> + +C.2. Example Process + + The JSON examples below are wrapped at 60 columns. This results in + strings that have newlines in them, which makes them invalid JSON as + is. The strings would otherwise be too long, so they need to be + unwrapped before processing. + + For readability, the output of the asn1parse has been truncated at 68 + columns rather than wrapped. + +C.2.1. Pledge to Registrar + + As described in Section 5.2, the pledge will sign a pledge voucher- + request containing the registrar's public key in the proximity- + registrar-cert field. The base64 has been wrapped at 60 characters + for presentation reasons. + + <CODE BEGINS> file "vr_00-D0-E5-F2-00-02.b64" + MIIGcAYJKoZIhvcNAQcCoIIGYTCCBl0CAQExDTALBglghkgBZQMEAgEwggOJBgkqhkiG + 9w0BBwGgggN6BIIDdnsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3Nl + cnRpb24iOiJwcm94aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAyMS0wNC0xM1QxNzo0Mzoy + My43NDctMDQ6MDAiLCJzZXJpYWwtbnVtYmVyIjoiMDAtRDAtRTUtRjItMDAtMDIiLCJu + b25jZSI6Ii1fWEU5eks5cThMbDFxeWxNdExLZWciLCJwcm94aW1pdHktcmVnaXN0cmFy + LWNlcnQiOiJNSUlCL0RDQ0FZS2dBd0lCQWdJRVA1aWJVakFLQmdncWhrak9QUVFEQWpC + dE1SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdvSmtpYUprL0lzWkFFWkZn + bHpZVzVrWld4dFlXNHhQREE2QmdOVkJBTU1NMlp2ZFc1MFlXbHVMWFJsYzNRdVpYaGhi + WEJzWlM1amIyMGdWVzV6ZEhKMWJtY2dSbTkxYm5SaGFXNGdVbTl2ZENCRFFUQWVGdzB5 + TURBeU1qVXlNVE14TlRSYUZ3MHlNakF5TWpReU1UTXhOVFJhTUZNeEVqQVFCZ29Ka2lh + SmsvSXNaQUVaRmdKallURVpNQmNHQ2dtU0pvbVQ4aXhrQVJrV0NYTmhibVJsYkcxaGJq + RWlNQ0FHQTFVRUF3d1pabTkxYm5SaGFXNHRkR1Z6ZEM1bGVHRnRjR3hsTG1OdmJUQlpN + Qk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJKWmxVSEkwdXAvbDNlWmY5dkNC + YitsSW5vRU1FZ2M3Um8rWFpDdGpBSTBDRDFmSmZKUi9oSXl5RG1IV3lZaU5GYlJDSDlm + eWFyZmt6Z1g0cDB6VGl6cWpLakFvTUJZR0ExVWRKUUVCL3dRTU1Bb0dDQ3NHQVFVRkJ3 + TWNNQTRHQTFVZER3RUIvd1FFQXdJSGdEQUtCZ2dxaGtqT1BRUURBZ05vQURCbEFqQm1U + MkJNVlVnZWxnZjQzUis1eUJLTlJUYUhteVBBdkx2eHl6MG1GVlp2WHgrLzFSd09hZ212 + RzNhWG1Sa2ovWDRDTVFDOHJNTkJzTG9OcjFMNW5HNTZmd0FkSThoaUFXRzhTOFhBUjVr + MUNneDNZVVFCU2dkU2NGY0FkZisrQnc2WXkrVT0ifX2gggGyMIIBrjCCATWgAwIBAgIE + DYOv2TAKBggqhkjOPQQDAjAmMSQwIgYDVQQDDBtoaWdod2F5LXRlc3QuZXhhbXBsZS5j + b20gQ0EwIBcNMjEwNDEzMjAzNzM5WhgPMjk5OTEyMzEwMDAwMDBaMBwxGjAYBgNVBAUM + ETAwLUQwLUU1LUYyLTAwLTAyMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEA6N1Q4ez + fMAKmoecrfb0OBMc1AyEH+BATkF58FsTSyBxs0SbSWLxFjDOuwB9gLGn2TsTUJumJ6VP + w5Z/TP4hJ6NZMFcwHQYDVR0OBBYEFEWIzJaWAGQ3sLojZWRkVAgGbFatMAkGA1UdEwQC + MAAwKwYIKwYBBQUHASAEHxYdaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tOjk0NDMwCgYI + KoZIzj0EAwIDZwAwZAIwTmlG8sXkKGNbwbKQcYMapFbmSbnHHURFUoFuRqvbgYX7FlXp + BczfwF2kllNuujigAjAow1kc4r55EmiH+OMEXjBNlWlBSZC5QuJjEf0Jsmxssc+pucjO + J4ShqnexMEy7bjAxggEEMIIBAAIBATAuMCYxJDAiBgNVBAMMG2hpZ2h3YXktdGVzdC5l + eGFtcGxlLmNvbSBDQQIEDYOv2TALBglghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJ + KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA0MTMyMTQzMjNaMC8GCSqGSIb3DQEJ + BDEiBCBJwhyYibIjeqeR3bOaLURzMlGrc3F2X+kvJ1errtoCtTAKBggqhkjOPQQDAgRH + MEUCIQCmYuCE61HFQXH/E16GDOCsVquDtgr+Q/6/Du/9QkzA7gIgf7MFhAIPW2PNwRa2 + vZFQAKXUbimkiHKzXBA8md0VHbU= + <CODE ENDS> + + The ASN1 decoding of the artifact: + + file: examples/vr_00-D0-E5-F2-00-02.b64 + + 0:d=0 hl=4 l=1648 cons: SEQUENCE + 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData + 15:d=1 hl=4 l=1633 cons: cont [ 0 ] + 19:d=2 hl=4 l=1629 cons: SEQUENCE + 23:d=3 hl=2 l= 1 prim: INTEGER :01 + 26:d=3 hl=2 l= 13 cons: SET + 28:d=4 hl=2 l= 11 cons: SEQUENCE + 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 + 41:d=3 hl=4 l= 905 cons: SEQUENCE + 45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data + 56:d=4 hl=4 l= 890 cons: cont [ 0 ] + 60:d=5 hl=4 l= 886 prim: OCTET STRING :{"ietf-voucher-request:v + 950:d=3 hl=4 l= 434 cons: cont [ 0 ] + 954:d=4 hl=4 l= 430 cons: SEQUENCE + 958:d=5 hl=4 l= 309 cons: SEQUENCE + 962:d=6 hl=2 l= 3 cons: cont [ 0 ] + 964:d=7 hl=2 l= 1 prim: INTEGER :02 + 967:d=6 hl=2 l= 4 prim: INTEGER :0D83AFD9 + 973:d=6 hl=2 l= 10 cons: SEQUENCE + 975:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 + 985:d=6 hl=2 l= 38 cons: SEQUENCE + 987:d=7 hl=2 l= 36 cons: SET + 989:d=8 hl=2 l= 34 cons: SEQUENCE + 991:d=9 hl=2 l= 3 prim: OBJECT :commonName + 996:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com + 1025:d=6 hl=2 l= 32 cons: SEQUENCE + 1027:d=7 hl=2 l= 13 prim: UTCTIME :210413203739Z + 1042:d=7 hl=2 l= 15 prim: GENERALIZEDTIME :29991231000000Z + 1059:d=6 hl=2 l= 28 cons: SEQUENCE + 1061:d=7 hl=2 l= 26 cons: SET + 1063:d=8 hl=2 l= 24 cons: SEQUENCE + 1065:d=9 hl=2 l= 3 prim: OBJECT :serialNumber + 1070:d=9 hl=2 l= 17 prim: UTF8STRING :00-D0-E5-F2-00-02 + 1089:d=6 hl=2 l= 89 cons: SEQUENCE + 1091:d=7 hl=2 l= 19 cons: SEQUENCE + 1093:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey + 1102:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 + 1112:d=7 hl=2 l= 66 prim: BIT STRING + 1180:d=6 hl=2 l= 89 cons: cont [ 3 ] + 1182:d=7 hl=2 l= 87 cons: SEQUENCE + 1184:d=8 hl=2 l= 29 cons: SEQUENCE + 1186:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Ident + 1191:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:04144588CC9696 + 1215:d=8 hl=2 l= 9 cons: SEQUENCE + 1217:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints + 1222:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000 + 1226:d=8 hl=2 l= 43 cons: SEQUENCE + 1228:d=9 hl=2 l= 8 prim: OBJECT :1.3.6.1.5.5.7.1.32 + 1238:d=9 hl=2 l= 31 prim: OCTET STRING [HEX DUMP]:161D6869676877 + 1271:d=5 hl=2 l= 10 cons: SEQUENCE + 1273:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 + 1283:d=5 hl=2 l= 103 prim: BIT STRING + 1388:d=3 hl=4 l= 260 cons: SET + 1392:d=4 hl=4 l= 256 cons: SEQUENCE + 1396:d=5 hl=2 l= 1 prim: INTEGER :01 + 1399:d=5 hl=2 l= 46 cons: SEQUENCE + 1401:d=6 hl=2 l= 38 cons: SEQUENCE + 1403:d=7 hl=2 l= 36 cons: SET + 1405:d=8 hl=2 l= 34 cons: SEQUENCE + 1407:d=9 hl=2 l= 3 prim: OBJECT :commonName + 1412:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com + 1441:d=6 hl=2 l= 4 prim: INTEGER :0D83AFD9 + 1447:d=5 hl=2 l= 11 cons: SEQUENCE + 1449:d=6 hl=2 l= 9 prim: OBJECT :sha256 + 1460:d=5 hl=2 l= 105 cons: cont [ 0 ] + 1462:d=6 hl=2 l= 24 cons: SEQUENCE + 1464:d=7 hl=2 l= 9 prim: OBJECT :contentType + 1475:d=7 hl=2 l= 11 cons: SET + 1477:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data + 1488:d=6 hl=2 l= 28 cons: SEQUENCE + 1490:d=7 hl=2 l= 9 prim: OBJECT :signingTime + 1501:d=7 hl=2 l= 15 cons: SET + 1503:d=8 hl=2 l= 13 prim: UTCTIME :210413214323Z + 1518:d=6 hl=2 l= 47 cons: SEQUENCE + 1520:d=7 hl=2 l= 9 prim: OBJECT :messageDigest + 1531:d=7 hl=2 l= 34 cons: SET + 1533:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:49C21C9889B223 + 1567:d=5 hl=2 l= 10 cons: SEQUENCE + 1569:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 + 1579:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:3045022100A662 + + The JSON contained in the voucher-request: + + {"ietf-voucher-request:voucher":{"assertion":"proximity","cr + eated-on":"2021-04-13T17:43:23.747-04:00","serial-number":"0 + 0-D0-E5-F2-00-02","nonce":"-_XE9zK9q8Ll1qylMtLKeg","proximit + y-registrar-cert":"MIIB/DCCAYKgAwIBAgIEP5ibUjAKBggqhkjOPQQDA + jBtMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZ + WxtYW4xPDA6BgNVBAMMM2ZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zd + HJ1bmcgRm91bnRhaW4gUm9vdCBDQTAeFw0yMDAyMjUyMTMxNTRaFw0yMjAyM + jQyMTMxNTRaMFMxEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkA + RkWCXNhbmRlbG1hbjEiMCAGA1UEAwwZZm91bnRhaW4tdGVzdC5leGFtcGxlL + mNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJZlUHI0up/l3eZf9vCBb + +lInoEMEgc7Ro+XZCtjAI0CD1fJfJR/hIyyDmHWyYiNFbRCH9fyarfkzgX4p + 0zTizqjKjAoMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMcMA4GA1UdDwEB/wQEA + wIHgDAKBggqhkjOPQQDAgNoADBlAjBmT2BMVUgelgf43R+5yBKNRTaHmyPAv + Lvxyz0mFVZvXx+/1RwOagmvG3aXmRkj/X4CMQC8rMNBsLoNr1L5nG56fwAdI + 8hiAWG8S8XAR5k1Cgx3YUQBSgdScFcAdf++Bw6Yy+U="}} + +C.2.2. Registrar to MASA + + As described in Section 5.5, the registrar will sign a registrar + voucher-request and will include the pledge's voucher-request in the + prior-signed-voucher-request. + + <CODE BEGINS> file "parboiled_vr_00-D0-E5-F2-00-02.b64" + MIIPYwYJKoZIhvcNAQcCoIIPVDCCD1ACAQExDTALBglghkgBZQMEAgEwggl4BgkqhkiG + 9w0BBwGggglpBIIJZXsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3Nl + cnRpb24iOiJwcm94aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAyMS0wNC0xM1QyMTo0Mzoy + My43ODdaIiwic2VyaWFsLW51bWJlciI6IjAwLUQwLUU1LUYyLTAwLTAyIiwibm9uY2Ui + OiItX1hFOXpLOXE4TGwxcXlsTXRMS2VnIiwicHJpb3Itc2lnbmVkLXZvdWNoZXItcmVx + dWVzdCI6Ik1JSUdjQVlKS29aSWh2Y05BUWNDb0lJR1lUQ0NCbDBDQVFFeERUQUxCZ2xn + aGtnQlpRTUVBZ0V3Z2dPSkJna3Foa2lHOXcwQkJ3R2dnZ042QklJRGRuc2lhV1YwWmkx + MmIzVmphR1Z5TFhKbGNYVmxjM1E2ZG05MVkyaGxjaUk2ZXlKaGMzTmxjblJwYjI0aU9p + SndjbTk0YVcxcGRIa2lMQ0pqY21WaGRHVmtMVzl1SWpvaU1qQXlNUzB3TkMweE0xUXhO + em8wTXpveU15NDNORGN0TURRNk1EQWlMQ0p6WlhKcFlXd3RiblZ0WW1WeUlqb2lNREF0 + UkRBdFJUVXRSakl0TURBdE1ESWlMQ0p1YjI1alpTSTZJaTFmV0VVNWVrczVjVGhNYkRG + eGVXeE5kRXhMWldjaUxDSndjbTk0YVcxcGRIa3RjbVZuYVhOMGNtRnlMV05sY25RaU9p + Sk5TVWxDTDBSRFEwRlpTMmRCZDBsQ1FXZEpSVkExYVdKVmFrRkxRbWRuY1docmFrOVFV + VkZFUVdwQ2RFMVNTWGRGUVZsTFExcEpiV2xhVUhsTVIxRkNSMUpaUTFreVJYaEhWRUZZ + UW1kdlNtdHBZVXByTDBseldrRkZXa1puYkhwWlZ6VnJXbGQ0ZEZsWE5IaFFSRUUyUW1k + T1ZrSkJUVTFOTWxwMlpGYzFNRmxYYkhWTVdGSnNZek5SZFZwWWFHaGlXRUp6V2xNMWFt + SXlNR2RXVnpWNlpFaEtNV0p0WTJkU2JUa3hZbTVTYUdGWE5HZFZiVGwyWkVOQ1JGRlVR + V1ZHZHpCNVRVUkJlVTFxVlhsTlZFMTRUbFJTWVVaM01IbE5ha0Y1VFdwUmVVMVVUWGhP + VkZKaFRVWk5lRVZxUVZGQ1oyOUthMmxoU21zdlNYTmFRVVZhUm1kS2FsbFVSVnBOUW1O + SFEyZHRVMHB2YlZRNGFYaHJRVkpyVjBOWVRtaGliVkpzWWtjeGFHSnFSV2xOUTBGSFFU + RlZSVUYzZDFwYWJUa3hZbTVTYUdGWE5IUmtSMVo2WkVNMWJHVkhSblJqUjNoc1RHMU9k + bUpVUWxwTlFrMUhRbmx4UjFOTk5EbEJaMFZIUTBOeFIxTk5ORGxCZDBWSVFUQkpRVUpL + V214VlNFa3dkWEF2YkRObFdtWTVka05DWWl0c1NXNXZSVTFGWjJNM1VtOHJXRnBEZEdw + QlNUQkRSREZtU21aS1VpOW9TWGw1UkcxSVYzbFphVTVHWWxKRFNEbG1lV0Z5Wm10Nlox + ZzBjREI2VkdsNmNXcExha0Z2VFVKWlIwRXhWV1JLVVVWQ0wzZFJUVTFCYjBkRFEzTkhR + VkZWUmtKM1RXTk5RVFJIUVRGVlpFUjNSVUl2ZDFGRlFYZEpTR2RFUVV0Q1oyZHhhR3Rx + VDFCUlVVUkJaMDV2UVVSQ2JFRnFRbTFVTWtKTlZsVm5aV3huWmpRelVpczFlVUpMVGxK + VVlVaHRlVkJCZGt4MmVIbDZNRzFHVmxwMldIZ3JMekZTZDA5aFoyMTJSek5oV0cxU2Ey + b3ZXRFJEVFZGRE9ISk5Ua0p6VEc5T2NqRk1OVzVITlRabWQwRmtTVGhvYVVGWFJ6aFRP + RmhCVWpWck1VTm5lRE5aVlZGQ1UyZGtVMk5HWTBGa1ppc3JRbmMyV1hrclZUMGlmWDJn + Z2dHeU1JSUJyakNDQVRXZ0F3SUJBZ0lFRFlPdjJUQUtCZ2dxaGtqT1BRUURBakFtTVNR + d0lnWURWUVFEREJ0b2FXZG9kMkY1TFhSbGMzUXVaWGhoYlhCc1pTNWpiMjBnUTBFd0lC + Y05NakV3TkRFek1qQXpOek01V2hnUE1qazVPVEV5TXpFd01EQXdNREJhTUJ3eEdqQVlC + Z05WQkFVTUVUQXdMVVF3TFVVMUxVWXlMVEF3TFRBeU1Ga3dFd1lIS29aSXpqMENBUVlJ + S29aSXpqMERBUWNEUWdBRUE2TjFRNGV6Zk1BS21vZWNyZmIwT0JNYzFBeUVIK0JBVGtG + NThGc1RTeUJ4czBTYlNXTHhGakRPdXdCOWdMR24yVHNUVUp1bUo2VlB3NVovVFA0aEo2 + TlpNRmN3SFFZRFZSME9CQllFRkVXSXpKYVdBR1Ezc0xvalpXUmtWQWdHYkZhdE1Ba0dB + MVVkRXdRQ01BQXdLd1lJS3dZQkJRVUhBU0FFSHhZZGFHbG5hSGRoZVMxMFpYTjBMbVY0 + WVcxd2JHVXVZMjl0T2prME5ETXdDZ1lJS29aSXpqMEVBd0lEWndBd1pBSXdUbWxHOHNY + a0tHTmJ3YktRY1lNYXBGYm1TYm5ISFVSRlVvRnVScXZiZ1lYN0ZsWHBCY3pmd0Yya2xs + TnV1amlnQWpBb3cxa2M0cjU1RW1pSCtPTUVYakJObFdsQlNaQzVRdUpqRWYwSnNteHNz + YytwdWNqT0o0U2hxbmV4TUV5N2JqQXhnZ0VFTUlJQkFBSUJBVEF1TUNZeEpEQWlCZ05W + QkFNTUcyaHBaMmgzWVhrdGRHVnpkQzVsZUdGdGNHeGxMbU52YlNCRFFRSUVEWU92MlRB + TEJnbGdoa2dCWlFNRUFnR2dhVEFZQmdrcWhraUc5dzBCQ1FNeEN3WUpLb1pJaHZjTkFR + Y0JNQndHQ1NxR1NJYjNEUUVKQlRFUEZ3MHlNVEEwTVRNeU1UUXpNak5hTUM4R0NTcUdT + SWIzRFFFSkJERWlCQ0JKd2h5WWliSWplcWVSM2JPYUxVUnpNbEdyYzNGMlgra3ZKMWVy + cnRvQ3RUQUtCZ2dxaGtqT1BRUURBZ1JITUVVQ0lRQ21ZdUNFNjFIRlFYSC9FMTZHRE9D + c1ZxdUR0Z3IrUS82L0R1LzlRa3pBN2dJZ2Y3TUZoQUlQVzJQTndSYTJ2WkZRQUtYVWJp + bWtpSEt6WEJBOG1kMFZIYlU9In19oIIEbzCCAfwwggGCoAMCAQICBD+Ym1IwCgYIKoZI + zj0EAwIwbTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVs + bWFuMTwwOgYDVQQDDDNmb3VudGFpbi10ZXN0LmV4YW1wbGUuY29tIFVuc3RydW5nIEZv + dW50YWluIFJvb3QgQ0EwHhcNMjAwMjI1MjEzMTU0WhcNMjIwMjI0MjEzMTU0WjBTMRIw + EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xIjAgBgNV + BAMMGWZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMB + BwNCAASWZVByNLqf5d3mX/bwgW/pSJ6BDBIHO0aPl2QrYwCNAg9XyXyUf4SMsg5h1smI + jRW0Qh/X8mq35M4F+KdM04s6oyowKDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDHDAOBgNV + HQ8BAf8EBAMCB4AwCgYIKoZIzj0EAwIDaAAwZQIwZk9gTFVIHpYH+N0fucgSjUU2h5sj + wLy78cs9JhVWb18fv9UcDmoJrxt2l5kZI/1+AjEAvKzDQbC6Da9S+Zxuen8AHSPIYgFh + vEvFwEeZNQoMd2FEAUoHUnBXAHX/vgcOmMvlMIICazCCAfKgAwIBAgIEKWsGWTAKBggq + hkjOPQQDAjBtMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5k + ZWxtYW4xPDA6BgNVBAMMM2ZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcg + Rm91bnRhaW4gUm9vdCBDQTAeFw0yMDAyMjUyMTMxNDVaFw0yMjAyMjQyMTMxNDVaMG0x + EjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjE8MDoG + A1UEAwwzZm91bnRhaW4tdGVzdC5leGFtcGxlLmNvbSBVbnN0cnVuZyBGb3VudGFpbiBS + b290IENBMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEG39ZuhfDGrxmjYxs4MP6MXEPZfYi + kb23VoAH29+4eqVFTXmKRpcZWZYxsY9pfTK+PMg+W2O1Rvao1W+b+cDz07kUP3JHUaR2 + 3dLwv/XKjzABf/jCX9P1IANEi4vyB2y0o2MwYTAPBgNVHRMBAf8EBTADAQH/MA4GA1Ud + DwEB/wQEAwIBBjAdBgNVHQ4EFgQUuaX2yxHhB6RJLKcIxnwQvIezdCYwHwYDVR0jBBgw + FoAUuaX2yxHhB6RJLKcIxnwQvIezdCYwCgYIKoZIzj0EAwIDZwAwZAIwIIMGzo2YpFR6 + ZkxKOnDCUjZaUo1ZfSCbKmkUWIc42FV53f0pOJUekZN2tPVmKUS0AjBvOPmvEu0w1YUp + fLEWWL1nkUPEDTD52BysLwbdvNUGQiyEogTqAqRfF1Em+9kv0lwxggFLMIIBRwIBATB1 + MG0xEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjE8 + MDoGA1UEAwwzZm91bnRhaW4tdGVzdC5leGFtcGxlLmNvbSBVbnN0cnVuZyBGb3VudGFp + biBSb290IENBAgQ/mJtSMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG + 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDQxMzIxNDMyM1owLwYJKoZIhvcNAQkEMSIE + IEnOrdWjlG70K74IhCJ7UXi+wPS+r2C8DFEqjabGP+G8MAoGCCqGSM49BAMCBEcwRQIh + AMhO3M+tSWb2wKTBOXPArN+XvjSzAhaQA/uLj3qhPwi/AiBDDthf6mjMuirqXE0yjMif + C2UY9oNUFF9Nl0wEQpBBAA== + <CODE ENDS> + + The ASN1 decoding of the artifact: + + file: examples/parboiled_vr_00_D0-E5-02-00-2D.b64 + + 0:d=0 hl=4 l=3939 cons: SEQUENCE + 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData + 15:d=1 hl=4 l=3924 cons: cont [ 0 ] + 19:d=2 hl=4 l=3920 cons: SEQUENCE + 23:d=3 hl=2 l= 1 prim: INTEGER :01 + 26:d=3 hl=2 l= 13 cons: SET + 28:d=4 hl=2 l= 11 cons: SEQUENCE + 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 + 41:d=3 hl=4 l=2424 cons: SEQUENCE + 45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data + 56:d=4 hl=4 l=2409 cons: cont [ 0 ] + 60:d=5 hl=4 l=2405 prim: OCTET STRING :{"ietf-voucher-request:v + 2469:d=3 hl=4 l=1135 cons: cont [ 0 ] + 2473:d=4 hl=4 l= 508 cons: SEQUENCE + 2477:d=5 hl=4 l= 386 cons: SEQUENCE + 2481:d=6 hl=2 l= 3 cons: cont [ 0 ] + 2483:d=7 hl=2 l= 1 prim: INTEGER :02 + 2486:d=6 hl=2 l= 4 prim: INTEGER :3F989B52 + 2492:d=6 hl=2 l= 10 cons: SEQUENCE + 2494:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 + 2504:d=6 hl=2 l= 109 cons: SEQUENCE + 2506:d=7 hl=2 l= 18 cons: SET + 2508:d=8 hl=2 l= 16 cons: SEQUENCE + 2510:d=9 hl=2 l= 10 prim: OBJECT :domainComponent + 2522:d=9 hl=2 l= 2 prim: IA5STRING :ca + 2526:d=7 hl=2 l= 25 cons: SET + 2528:d=8 hl=2 l= 23 cons: SEQUENCE + 2530:d=9 hl=2 l= 10 prim: OBJECT :domainComponent + 2542:d=9 hl=2 l= 9 prim: IA5STRING :sandelman + 2553:d=7 hl=2 l= 60 cons: SET + 2555:d=8 hl=2 l= 58 cons: SEQUENCE + 2557:d=9 hl=2 l= 3 prim: OBJECT :commonName + 2562:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co + 2615:d=6 hl=2 l= 30 cons: SEQUENCE + 2617:d=7 hl=2 l= 13 prim: UTCTIME :200225213154Z + 2632:d=7 hl=2 l= 13 prim: UTCTIME :220224213154Z + 2647:d=6 hl=2 l= 83 cons: SEQUENCE + 2649:d=7 hl=2 l= 18 cons: SET + 2651:d=8 hl=2 l= 16 cons: SEQUENCE + 2653:d=9 hl=2 l= 10 prim: OBJECT :domainComponent + 2665:d=9 hl=2 l= 2 prim: IA5STRING :ca + 2669:d=7 hl=2 l= 25 cons: SET + 2671:d=8 hl=2 l= 23 cons: SEQUENCE + 2673:d=9 hl=2 l= 10 prim: OBJECT :domainComponent + 2685:d=9 hl=2 l= 9 prim: IA5STRING :sandelman + 2696:d=7 hl=2 l= 34 cons: SET + 2698:d=8 hl=2 l= 32 cons: SEQUENCE + 2700:d=9 hl=2 l= 3 prim: OBJECT :commonName + 2705:d=9 hl=2 l= 25 prim: UTF8STRING :fountain-test.example.co + 2732:d=6 hl=2 l= 89 cons: SEQUENCE + 2734:d=7 hl=2 l= 19 cons: SEQUENCE + 2736:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey + 2745:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 + 2755:d=7 hl=2 l= 66 prim: BIT STRING + 2823:d=6 hl=2 l= 42 cons: cont [ 3 ] + 2825:d=7 hl=2 l= 40 cons: SEQUENCE + 2827:d=8 hl=2 l= 22 cons: SEQUENCE + 2829:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Extended Key Usag + 2834:d=9 hl=2 l= 1 prim: BOOLEAN :255 + 2837:d=9 hl=2 l= 12 prim: OCTET STRING [HEX DUMP]:300A06082B0601 + 2851:d=8 hl=2 l= 14 cons: SEQUENCE + 2853:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage + 2858:d=9 hl=2 l= 1 prim: BOOLEAN :255 + 2861:d=9 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:03020780 + 2867:d=5 hl=2 l= 10 cons: SEQUENCE + 2869:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 + 2879:d=5 hl=2 l= 104 prim: BIT STRING + 2985:d=4 hl=4 l= 619 cons: SEQUENCE + 2989:d=5 hl=4 l= 498 cons: SEQUENCE + 2993:d=6 hl=2 l= 3 cons: cont [ 0 ] + 2995:d=7 hl=2 l= 1 prim: INTEGER :02 + 2998:d=6 hl=2 l= 4 prim: INTEGER :296B0659 + 3004:d=6 hl=2 l= 10 cons: SEQUENCE + 3006:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 + 3016:d=6 hl=2 l= 109 cons: SEQUENCE + 3018:d=7 hl=2 l= 18 cons: SET + 3020:d=8 hl=2 l= 16 cons: SEQUENCE + 3022:d=9 hl=2 l= 10 prim: OBJECT :domainComponent + 3034:d=9 hl=2 l= 2 prim: IA5STRING :ca + 3038:d=7 hl=2 l= 25 cons: SET + 3040:d=8 hl=2 l= 23 cons: SEQUENCE + 3042:d=9 hl=2 l= 10 prim: OBJECT :domainComponent + 3054:d=9 hl=2 l= 9 prim: IA5STRING :sandelman + 3065:d=7 hl=2 l= 60 cons: SET + 3067:d=8 hl=2 l= 58 cons: SEQUENCE + 3069:d=9 hl=2 l= 3 prim: OBJECT :commonName + 3074:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co + 3127:d=6 hl=2 l= 30 cons: SEQUENCE + 3129:d=7 hl=2 l= 13 prim: UTCTIME :200225213145Z + 3144:d=7 hl=2 l= 13 prim: UTCTIME :220224213145Z + 3159:d=6 hl=2 l= 109 cons: SEQUENCE + 3161:d=7 hl=2 l= 18 cons: SET + 3163:d=8 hl=2 l= 16 cons: SEQUENCE + 3165:d=9 hl=2 l= 10 prim: OBJECT :domainComponent + 3177:d=9 hl=2 l= 2 prim: IA5STRING :ca + 3181:d=7 hl=2 l= 25 cons: SET + 3183:d=8 hl=2 l= 23 cons: SEQUENCE + 3185:d=9 hl=2 l= 10 prim: OBJECT :domainComponent + 3197:d=9 hl=2 l= 9 prim: IA5STRING :sandelman + 3208:d=7 hl=2 l= 60 cons: SET + 3210:d=8 hl=2 l= 58 cons: SEQUENCE + 3212:d=9 hl=2 l= 3 prim: OBJECT :commonName + 3217:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co + 3270:d=6 hl=2 l= 118 cons: SEQUENCE + 3272:d=7 hl=2 l= 16 cons: SEQUENCE + 3274:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey + 3283:d=8 hl=2 l= 5 prim: OBJECT :secp384r1 + 3290:d=7 hl=2 l= 98 prim: BIT STRING + 3390:d=6 hl=2 l= 99 cons: cont [ 3 ] + 3392:d=7 hl=2 l= 97 cons: SEQUENCE + 3394:d=8 hl=2 l= 15 cons: SEQUENCE + 3396:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints + 3401:d=9 hl=2 l= 1 prim: BOOLEAN :255 + 3404:d=9 hl=2 l= 5 prim: OCTET STRING [HEX DUMP]:30030101FF + 3411:d=8 hl=2 l= 14 cons: SEQUENCE + 3413:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage + 3418:d=9 hl=2 l= 1 prim: BOOLEAN :255 + 3421:d=9 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:03020106 + 3427:d=8 hl=2 l= 29 cons: SEQUENCE + 3429:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Ident + 3434:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:0414B9A5F6CB11 + 3458:d=8 hl=2 l= 31 cons: SEQUENCE + 3460:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Authority Key Ide + 3465:d=9 hl=2 l= 24 prim: OCTET STRING [HEX DUMP]:30168014B9A5F6 + 3491:d=5 hl=2 l= 10 cons: SEQUENCE + 3493:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 + 3503:d=5 hl=2 l= 103 prim: BIT STRING + 3608:d=3 hl=4 l= 331 cons: SET + 3612:d=4 hl=4 l= 327 cons: SEQUENCE + 3616:d=5 hl=2 l= 1 prim: INTEGER :01 + 3619:d=5 hl=2 l= 117 cons: SEQUENCE + 3621:d=6 hl=2 l= 109 cons: SEQUENCE + 3623:d=7 hl=2 l= 18 cons: SET + 3625:d=8 hl=2 l= 16 cons: SEQUENCE + 3627:d=9 hl=2 l= 10 prim: OBJECT :domainComponent + 3639:d=9 hl=2 l= 2 prim: IA5STRING :ca + 3643:d=7 hl=2 l= 25 cons: SET + 3645:d=8 hl=2 l= 23 cons: SEQUENCE + 3647:d=9 hl=2 l= 10 prim: OBJECT :domainComponent + 3659:d=9 hl=2 l= 9 prim: IA5STRING :sandelman + 3670:d=7 hl=2 l= 60 cons: SET + 3672:d=8 hl=2 l= 58 cons: SEQUENCE + 3674:d=9 hl=2 l= 3 prim: OBJECT :commonName + 3679:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co + 3732:d=6 hl=2 l= 4 prim: INTEGER :3F989B52 + 3738:d=5 hl=2 l= 11 cons: SEQUENCE + 3740:d=6 hl=2 l= 9 prim: OBJECT :sha256 + 3751:d=5 hl=2 l= 105 cons: cont [ 0 ] + 3753:d=6 hl=2 l= 24 cons: SEQUENCE + 3755:d=7 hl=2 l= 9 prim: OBJECT :contentType + 3766:d=7 hl=2 l= 11 cons: SET + 3768:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data + 3779:d=6 hl=2 l= 28 cons: SEQUENCE + 3781:d=7 hl=2 l= 9 prim: OBJECT :signingTime + 3792:d=7 hl=2 l= 15 cons: SET + 3794:d=8 hl=2 l= 13 prim: UTCTIME :210413214323Z + 3809:d=6 hl=2 l= 47 cons: SEQUENCE + 3811:d=7 hl=2 l= 9 prim: OBJECT :messageDigest + 3822:d=7 hl=2 l= 34 cons: SET + 3824:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:49CEADD5A3946E + 3858:d=5 hl=2 l= 10 cons: SEQUENCE + 3860:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 + 3870:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:3045022100C84E + + The JSON contained in the voucher-request. Note that the previous + voucher-request is in the prior-signed-voucher-request attribute. + + {"ietf-voucher-request:voucher":{"assertion":"proximity","cr + eated-on":"2021-04-13T21:43:23.787Z","serial-number":"00-D0- + E5-F2-00-02","nonce":"-_XE9zK9q8Ll1qylMtLKeg","prior-signed- + voucher-request":"MIIGcAYJKoZIhvcNAQcCoIIGYTCCBl0CAQExDTALBg + lghkgBZQMEAgEwggOJBgkqhkiG9w0BBwGgggN6BIIDdnsiaWV0Zi12b3VjaG + VyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJwcm94aW1pdHkiLC + JjcmVhdGVkLW9uIjoiMjAyMS0wNC0xM1QxNzo0MzoyMy43NDctMDQ6MDAiLC + JzZXJpYWwtbnVtYmVyIjoiMDAtRDAtRTUtRjItMDAtMDIiLCJub25jZSI6Ii + 1fWEU5eks5cThMbDFxeWxNdExLZWciLCJwcm94aW1pdHktcmVnaXN0cmFyLW + NlcnQiOiJNSUlCL0RDQ0FZS2dBd0lCQWdJRVA1aWJVakFLQmdncWhrak9QUV + FEQWpCdE1SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdvSmtpYU + prL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhQREE2QmdOVkJBTU1NMlp2ZFc1MF + lXbHVMWFJsYzNRdVpYaGhiWEJzWlM1amIyMGdWVzV6ZEhKMWJtY2dSbTkxYm + 5SaGFXNGdVbTl2ZENCRFFUQWVGdzB5TURBeU1qVXlNVE14TlRSYUZ3MHlNak + F5TWpReU1UTXhOVFJhTUZNeEVqQVFCZ29Ka2lhSmsvSXNaQUVaRmdKallURV + pNQmNHQ2dtU0pvbVQ4aXhrQVJrV0NYTmhibVJsYkcxaGJqRWlNQ0FHQTFVRU + F3d1pabTkxYm5SaGFXNHRkR1Z6ZEM1bGVHRnRjR3hsTG1OdmJUQlpNQk1HQn + lxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJKWmxVSEkwdXAvbDNlWmY5dk + NCYitsSW5vRU1FZ2M3Um8rWFpDdGpBSTBDRDFmSmZKUi9oSXl5RG1IV3lZaU + 5GYlJDSDlmeWFyZmt6Z1g0cDB6VGl6cWpLakFvTUJZR0ExVWRKUUVCL3dRTU + 1Bb0dDQ3NHQVFVRkJ3TWNNQTRHQTFVZER3RUIvd1FFQXdJSGdEQUtCZ2dxaG + tqT1BRUURBZ05vQURCbEFqQm1UMkJNVlVnZWxnZjQzUis1eUJLTlJUYUhteV + BBdkx2eHl6MG1GVlp2WHgrLzFSd09hZ212RzNhWG1Sa2ovWDRDTVFDOHJNTk + JzTG9OcjFMNW5HNTZmd0FkSThoaUFXRzhTOFhBUjVrMUNneDNZVVFCU2dkU2 + NGY0FkZisrQnc2WXkrVT0ifX2gggGyMIIBrjCCATWgAwIBAgIEDYOv2TAKBg + gqhkjOPQQDAjAmMSQwIgYDVQQDDBtoaWdod2F5LXRlc3QuZXhhbXBsZS5jb2 + 0gQ0EwIBcNMjEwNDEzMjAzNzM5WhgPMjk5OTEyMzEwMDAwMDBaMBwxGjAYBg + NVBAUMETAwLUQwLUU1LUYyLTAwLTAyMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQ + cDQgAEA6N1Q4ezfMAKmoecrfb0OBMc1AyEH+BATkF58FsTSyBxs0SbSWLxFj + DOuwB9gLGn2TsTUJumJ6VPw5Z/TP4hJ6NZMFcwHQYDVR0OBBYEFEWIzJaWAG + Q3sLojZWRkVAgGbFatMAkGA1UdEwQCMAAwKwYIKwYBBQUHASAEHxYdaGlnaH + dheS10ZXN0LmV4YW1wbGUuY29tOjk0NDMwCgYIKoZIzj0EAwIDZwAwZAIwTm + lG8sXkKGNbwbKQcYMapFbmSbnHHURFUoFuRqvbgYX7FlXpBczfwF2kllNuuj + igAjAow1kc4r55EmiH+OMEXjBNlWlBSZC5QuJjEf0Jsmxssc+pucjOJ4Shqn + exMEy7bjAxggEEMIIBAAIBATAuMCYxJDAiBgNVBAMMG2hpZ2h3YXktdGVzdC + 5leGFtcGxlLmNvbSBDQQIEDYOv2TALBglghkgBZQMEAgGgaTAYBgkqhkiG9w + 0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA0MTMyMTQzMj + NaMC8GCSqGSIb3DQEJBDEiBCBJwhyYibIjeqeR3bOaLURzMlGrc3F2X+kvJ1 + errtoCtTAKBggqhkjOPQQDAgRHMEUCIQCmYuCE61HFQXH/E16GDOCsVquDtg + r+Q/6/Du/9QkzA7gIgf7MFhAIPW2PNwRa2vZFQAKXUbimkiHKzXBA8md0VHb + U="}} + +C.2.3. MASA to Registrar + + The MASA will return a voucher to the registrar, which is to be + relayed to the pledge. + + <CODE BEGINS> file "voucher_00-D0-E5-F2-00-02.b64" + MIIGIgYJKoZIhvcNAQcCoIIGEzCCBg8CAQExDTALBglghkgBZQMEAgEwggN4BgkqhkiG + 9w0BBwGgggNpBIIDZXsiaWV0Zi12b3VjaGVyOnZvdWNoZXIiOnsiYXNzZXJ0aW9uIjoi + bG9nZ2VkIiwiY3JlYXRlZC1vbiI6IjIwMjEtMDQtMTNUMTc6NDM6MjQuNTg5LTA0OjAw + Iiwic2VyaWFsLW51bWJlciI6IjAwLUQwLUU1LUYyLTAwLTAyIiwibm9uY2UiOiItX1hF + OXpLOXE4TGwxcXlsTXRMS2VnIiwicGlubmVkLWRvbWFpbi1jZXJ0IjoiTUlJQi9EQ0NB + WUtnQXdJQkFnSUVQNWliVWpBS0JnZ3Foa2pPUFFRREFqQnRNUkl3RUFZS0NaSW1pWlB5 + TEdRQkdSWUNZMkV4R1RBWEJnb0praWFKay9Jc1pBRVpGZ2x6WVc1a1pXeHRZVzR4UERB + NkJnTlZCQU1NTTJadmRXNTBZV2x1TFhSbGMzUXVaWGhoYlhCc1pTNWpiMjBnVlc1emRI + SjFibWNnUm05MWJuUmhhVzRnVW05dmRDQkRRVEFlRncweU1EQXlNalV5TVRNeE5UUmFG + dzB5TWpBeU1qUXlNVE14TlRSYU1GTXhFakFRQmdvSmtpYUprL0lzWkFFWkZnSmpZVEVa + TUJjR0NnbVNKb21UOGl4a0FSa1dDWE5oYm1SbGJHMWhiakVpTUNBR0ExVUVBd3daWm05 + MWJuUmhhVzR0ZEdWemRDNWxlR0Z0Y0d4bExtTnZiVEJaTUJNR0J5cUdTTTQ5QWdFR0ND + cUdTTTQ5QXdFSEEwSUFCSlpsVUhJMHVwL2wzZVpmOXZDQmIrbElub0VNRWdjN1JvK1ha + Q3RqQUkwQ0QxZkpmSlIvaEl5eURtSFd5WWlORmJSQ0g5ZnlhcmZremdYNHAwelRpenFq + S2pBb01CWUdBMVVkSlFFQi93UU1NQW9HQ0NzR0FRVUZCd01jTUE0R0ExVWREd0VCL3dR + RUF3SUhnREFLQmdncWhrak9QUVFEQWdOb0FEQmxBakJtVDJCTVZVZ2VsZ2Y0M1IrNXlC + S05SVGFIbXlQQXZMdnh5ejBtRlZadlh4Ky8xUndPYWdtdkczYVhtUmtqL1g0Q01RQzhy + TU5Cc0xvTnIxTDVuRzU2ZndBZEk4aGlBV0c4UzhYQVI1azFDZ3gzWVVRQlNnZFNjRmNB + ZGYrK0J3Nll5K1U9In19oIIBdDCCAXAwgfagAwIBAgIEC4cKMTAKBggqhkjOPQQDAjAm + MSQwIgYDVQQDDBtoaWdod2F5LXRlc3QuZXhhbXBsZS5jb20gQ0EwHhcNMjEwNDEzMjE0 + MDE2WhcNMjMwNDEzMjE0MDE2WjAoMSYwJAYDVQQDDB1oaWdod2F5LXRlc3QuZXhhbXBs + ZS5jb20gTUFTQTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABKoEFaNEueJE+Mn5Gwcb + pnRznB66bKmzqTCpojJZ96AdRwFtuTCVfoKouLTBX0idIhMLfJLM31lyuKy4CUtpp6Wj + EDAOMAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDaQAwZgIxAK7LYS3UXI1uhqoLBh3G + 02C6MnM2JdMjhUmHHM6UI3kankFVJB0VIqFIuwrAqzwTcwIxAIY8Z7OVouLl+a35HZzB + NDJ49c/q1UcDnwC/0FnLUcKYBIEkilETULF1si+dqLT0uTGCAQUwggEBAgEBMC4wJjEk + MCIGA1UEAwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBAgQLhwoxMAsGCWCGSAFl + AwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIx + MDQxMzIxNDMyNFowLwYJKoZIhvcNAQkEMSIEIFUUjg4WYVO+MpX122Qfk/7zm/G6/B59 + HD/xrVR0lGIjMAoGCCqGSM49BAMCBEgwRgIhAOhUfxbH2dwpB2BrTDcsYSjRkCCk/WE6 + Mdt+y4z5KD9IAiEAphwdIUb40A0noNIUpH7N2lTyAFZgyn1lNHTteY9DmYI= + <CODE ENDS> + + The ASN1 decoding of the artifact: + + file: examples/voucher_00-D0-E5-F2-00-02.b64 + + 0:d=0 hl=4 l=1570 cons: SEQUENCE + 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData + 15:d=1 hl=4 l=1555 cons: cont [ 0 ] + 19:d=2 hl=4 l=1551 cons: SEQUENCE + 23:d=3 hl=2 l= 1 prim: INTEGER :01 + 26:d=3 hl=2 l= 13 cons: SET + 28:d=4 hl=2 l= 11 cons: SEQUENCE + 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 + 41:d=3 hl=4 l= 888 cons: SEQUENCE + 45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data + 56:d=4 hl=4 l= 873 cons: cont [ 0 ] + 60:d=5 hl=4 l= 869 prim: OCTET STRING :{"ietf-voucher:voucher": + 933:d=3 hl=4 l= 372 cons: cont [ 0 ] + 937:d=4 hl=4 l= 368 cons: SEQUENCE + 941:d=5 hl=3 l= 246 cons: SEQUENCE + 944:d=6 hl=2 l= 3 cons: cont [ 0 ] + 946:d=7 hl=2 l= 1 prim: INTEGER :02 + 949:d=6 hl=2 l= 4 prim: INTEGER :0B870A31 + 955:d=6 hl=2 l= 10 cons: SEQUENCE + 957:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 + 967:d=6 hl=2 l= 38 cons: SEQUENCE + 969:d=7 hl=2 l= 36 cons: SET + 971:d=8 hl=2 l= 34 cons: SEQUENCE + 973:d=9 hl=2 l= 3 prim: OBJECT :commonName + 978:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com + 1007:d=6 hl=2 l= 30 cons: SEQUENCE + 1009:d=7 hl=2 l= 13 prim: UTCTIME :210413214016Z + 1024:d=7 hl=2 l= 13 prim: UTCTIME :230413214016Z + 1039:d=6 hl=2 l= 40 cons: SEQUENCE + 1041:d=7 hl=2 l= 38 cons: SET + 1043:d=8 hl=2 l= 36 cons: SEQUENCE + 1045:d=9 hl=2 l= 3 prim: OBJECT :commonName + 1050:d=9 hl=2 l= 29 prim: UTF8STRING :highway-test.example.com + 1081:d=6 hl=2 l= 89 cons: SEQUENCE + 1083:d=7 hl=2 l= 19 cons: SEQUENCE + 1085:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey + 1094:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 + 1104:d=7 hl=2 l= 66 prim: BIT STRING + 1172:d=6 hl=2 l= 16 cons: cont [ 3 ] + 1174:d=7 hl=2 l= 14 cons: SEQUENCE + 1176:d=8 hl=2 l= 12 cons: SEQUENCE + 1178:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints + 1183:d=9 hl=2 l= 1 prim: BOOLEAN :255 + 1186:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000 + 1190:d=5 hl=2 l= 10 cons: SEQUENCE + 1192:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 + 1202:d=5 hl=2 l= 105 prim: BIT STRING + 1309:d=3 hl=4 l= 261 cons: SET + 1313:d=4 hl=4 l= 257 cons: SEQUENCE + 1317:d=5 hl=2 l= 1 prim: INTEGER :01 + 1320:d=5 hl=2 l= 46 cons: SEQUENCE + 1322:d=6 hl=2 l= 38 cons: SEQUENCE + 1324:d=7 hl=2 l= 36 cons: SET + 1326:d=8 hl=2 l= 34 cons: SEQUENCE + 1328:d=9 hl=2 l= 3 prim: OBJECT :commonName + 1333:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com + 1362:d=6 hl=2 l= 4 prim: INTEGER :0B870A31 + 1368:d=5 hl=2 l= 11 cons: SEQUENCE + 1370:d=6 hl=2 l= 9 prim: OBJECT :sha256 + 1381:d=5 hl=2 l= 105 cons: cont [ 0 ] + 1383:d=6 hl=2 l= 24 cons: SEQUENCE + 1385:d=7 hl=2 l= 9 prim: OBJECT :contentType + 1396:d=7 hl=2 l= 11 cons: SET + 1398:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data + 1409:d=6 hl=2 l= 28 cons: SEQUENCE + 1411:d=7 hl=2 l= 9 prim: OBJECT :signingTime + 1422:d=7 hl=2 l= 15 cons: SET + 1424:d=8 hl=2 l= 13 prim: UTCTIME :210413214324Z + 1439:d=6 hl=2 l= 47 cons: SEQUENCE + 1441:d=7 hl=2 l= 9 prim: OBJECT :messageDigest + 1452:d=7 hl=2 l= 34 cons: SET + 1454:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:55148E0E166153 + 1488:d=5 hl=2 l= 10 cons: SEQUENCE + 1490:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 + 1500:d=5 hl=2 l= 72 prim: OCTET STRING [HEX DUMP]:3046022100E854 + + +Acknowledgements + + We would like to thank the various reviewers for their input, in + particular William Atwood, Brian Carpenter, Fuyu Eleven, Eliot Lear, + Sergey Kasatkin, Anoop Kumar, Tom Petch, Markus Stenberg, Peter van + der Stok, and Thomas Werner. + + Significant reviews were done by Jari Arkko, Christian Huitema, and + Russ Housley. + + Henk Birkholz contributed the CDDL for the audit-log response. + + This document started its life as a two-page idea from Steinthor + Bjarnason. + + In addition, significant review comments were provided by many IESG + members, including Adam Roach, Alexey Melnikov, Alissa Cooper, + Benjamin Kaduk, Éric Vyncke, Roman Danyliw, and Magnus Westerlund. + +Authors' Addresses + + Max Pritikin + Cisco + + Email: pritikin@cisco.com + + + Michael C. Richardson + Sandelman Software Works + + Email: mcr+ietf@sandelman.ca + URI: http://www.sandelman.ca/ + + + Toerless Eckert + Futurewei Technologies Inc. USA + 2330 Central Expy + Santa Clara, CA 95050 + United States of America + + Email: tte+ietf@cs.fau.de + + + Michael H. Behringer + + Email: Michael.H.Behringer@gmail.com + + + Kent Watsen + Watsen Networks + + Email: kent+ietf@watsen.net |