draft-ietf-anima-bootstrapping-keyinfra-30.txt   draft-ietf-anima-bootstrapping-keyinfra-31.txt 
ANIMA WG M. Pritikin ANIMA WG M. Pritikin
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track M. Richardson Intended status: Standards Track M. Richardson
Expires: May 20, 2020 Sandelman Expires: June 18, 2020 Sandelman
T. Eckert T. Eckert
Futurewei USA Futurewei USA
M. Behringer M. Behringer
K. Watsen K. Watsen
Watsen Networks Watsen Networks
November 17, 2019 December 16, 2019
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-30 draft-ietf-anima-bootstrapping-keyinfra-31
Abstract Abstract
This document specifies automated bootstrapping of an Autonomic This document specifies automated bootstrapping of an Autonomic
Control Plane. To do this a Secure Key Infrastructure is Control Plane. To do this a Secure Key Infrastructure is
bootstrapped. This is done using manufacturer-installed X.509 bootstrapped. This is done using manufacturer-installed X.509
certificates, in combination with a manufacturer's authorizing certificates, in combination with a manufacturer's authorizing
service, both online and offline. We call this process the service, both online and offline. We call this process the
Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol.
Bootstrapping a new device can occur using a routable address and a Bootstrapping a new device can occur using a routable address and a
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 20, 2020. This Internet-Draft will expire on June 18, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Prior Bootstrapping Approaches . . . . . . . . . . . . . 6 1.1. Prior Bootstrapping Approaches . . . . . . . . . . . . . 6
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 10 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 10
1.3.1. Support environment . . . . . . . . . . . . . . . . . 11 1.3.1. Support environment . . . . . . . . . . . . . . . . . 10
1.3.2. Constrained environments . . . . . . . . . . . . . . 11 1.3.2. Constrained environments . . . . . . . . . . . . . . 11
1.3.3. Network Access Controls . . . . . . . . . . . . . . . 12 1.3.3. Network Access Controls . . . . . . . . . . . . . . . 12
1.3.4. Bootstrapping is not Booting . . . . . . . . . . . . 12 1.3.4. Bootstrapping is not Booting . . . . . . . . . . . . 12
1.4. Leveraging the new key infrastructure / next steps . . . 12 1.4. Leveraging the new key infrastructure / next steps . . . 12
1.5. Requirements for Autonomic Network Infrastructure (ANI) 1.5. Requirements for Autonomic Network Infrastructure (ANI)
devices . . . . . . . . . . . . . . . . . . . . . . . . . 13 devices . . . . . . . . . . . . . . . . . . . . . . . . . 13
2. Architectural Overview . . . . . . . . . . . . . . . . . . . 13 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 13
2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 15 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 15
2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 16 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 16
2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 17 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 17
skipping to change at page 4, line 13 skipping to change at page 4, line 13
7.4. MASA security reductions . . . . . . . . . . . . . . . . 66 7.4. MASA security reductions . . . . . . . . . . . . . . . . 66
7.4.1. Issuing Nonceless vouchers . . . . . . . . . . . . . 67 7.4.1. Issuing Nonceless vouchers . . . . . . . . . . . . . 67
7.4.2. Trusting Owners on First Use . . . . . . . . . . . . 67 7.4.2. Trusting Owners on First Use . . . . . . . . . . . . 67
7.4.3. Updating or extending voucher trust anchors . . . . . 68 7.4.3. Updating or extending voucher trust anchors . . . . . 68
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69
8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 69 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 69
8.2. Well-known EST registration . . . . . . . . . . . . . . . 69 8.2. Well-known EST registration . . . . . . . . . . . . . . . 69
8.3. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 69 8.3. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 69
8.4. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 70 8.4. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 70
8.5. DNS Service Names . . . . . . . . . . . . . . . . . . . . 70 8.5. DNS Service Names . . . . . . . . . . . . . . . . . . . . 70
8.6. MUD File Extension for the MASA . . . . . . . . . . . . . 70
9. Applicability to the Autonomic Control Plane (ACP) . . . . . 70 9. Applicability to the Autonomic Control Plane (ACP) . . . . . 70
9.1. Operational Requirements . . . . . . . . . . . . . . . . 72 9.1. Operational Requirements . . . . . . . . . . . . . . . . 72
9.1.1. MASA Operational Requirements . . . . . . . . . . . . 72 9.1.1. MASA Operational Requirements . . . . . . . . . . . . 72
9.1.2. Domain Owner Operational Requirements . . . . . . . . 73 9.1.2. Domain Owner Operational Requirements . . . . . . . . 73
9.1.3. Device Operational Requirements . . . . . . . . . . . 73 9.1.3. Device Operational Requirements . . . . . . . . . . . 73
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 74 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 74
10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 74 10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 74
10.2. What BRSKI-EST reveals . . . . . . . . . . . . . . . . . 74 10.2. What BRSKI-EST reveals . . . . . . . . . . . . . . . . . 74
10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 75 10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 75
10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 77 10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 77
10.5. Manufacturers and Grey market equipment . . . . . . . . 78 10.5. Manufacturers and Grey market equipment . . . . . . . . 78
10.6. Some mitigations for meddling by manufacturers . . . . . 79 10.6. Some mitigations for meddling by manufacturers . . . . . 79
10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 80 10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 80
11. Security Considerations . . . . . . . . . . . . . . . . . . . 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 80
11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 81 11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 81
11.2. DomainID must be resistant to second-preimage attacks . 82 11.2. DomainID must be resistant to second-preimage attacks . 82
11.3. Availability of good random numbers . . . . . . . . . . 82 11.3. Availability of good random numbers . . . . . . . . . . 82
11.4. Freshness in Voucher-Requests . . . . . . . . . . . . . 83 11.4. Freshness in Voucher-Requests . . . . . . . . . . . . . 82
11.5. Trusting manufacturers . . . . . . . . . . . . . . . . . 84 11.5. Trusting manufacturers . . . . . . . . . . . . . . . . . 84
11.6. Manufacturer Maintenance of trust anchors . . . . . . . 85 11.6. Manufacturer Maintenance of trust anchors . . . . . . . 85
11.6.1. Compromise of Manufacturer IDevID signing keys . . . 86 11.6.1. Compromise of Manufacturer IDevID signing keys . . . 86
11.6.2. Compromise of MASA signing keys . . . . . . . . . . 87 11.6.2. Compromise of MASA signing keys . . . . . . . . . . 87
11.6.3. Compromise of MASA web service . . . . . . . . . . . 89 11.6.3. Compromise of MASA web service . . . . . . . . . . . 89
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 89 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 89
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 90
13.1. Normative References . . . . . . . . . . . . . . . . . . 90 13.1. Normative References . . . . . . . . . . . . . . . . . . 90
13.2. Informative References . . . . . . . . . . . . . . . . . 93 13.2. Informative References . . . . . . . . . . . . . . . . . 93
Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 97 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 97
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 97 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 97
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 97 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 97
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 97 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 97
Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 98 Appendix C. Example Vouchers . . . . . . . . . . . . . . . . . . 98
Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 100 C.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 98
D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 100 C.1.1. MASA key pair for voucher signatures . . . . . . . . 98
D.1.1. MASA key pair for voucher signatures . . . . . . . . 100 C.1.2. Manufacturer key pair for IDevID signatures . . . . . 99
D.1.2. Manufacturer key pair for IDevID signatures . . . . . 100 C.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 99
D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 101 C.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 101
D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 103 C.2. Example process . . . . . . . . . . . . . . . . . . . . . 103
C.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 104
D.2. Example process . . . . . . . . . . . . . . . . . . . . . 104 C.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 107
D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 105 C.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 112
D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 116
D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 113
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 117
1. Introduction 1. Introduction
The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol
provides a solution for secure zero-touch (automated) bootstrap of provides a solution for secure zero-touch (automated) bootstrap of
new (unconfigured) devices that are called pledges in this document. new (unconfigured) devices that are called pledges in this document.
Pledges have an IDevID installed in them at the factory. Pledges have an IDevID installed in them at the factory.
"BRSKI" is pronounced like "brewski", a colloquial term for beer in "BRSKI" is pronounced like "brewski", a colloquial term for beer in
Canada and parts of the US-midwest. [brewski] Canada and parts of the US-midwest. [brewski]
skipping to change at page 25, line 51 skipping to change at page 25, line 51
2.8. Determining the MASA to contact 2.8. Determining the MASA to contact
The registrar needs to be able to contact a MASA that is trusted by The registrar needs to be able to contact a MASA that is trusted by
the pledge in order to obtain vouchers. There are three mechanisms the pledge in order to obtain vouchers. There are three mechanisms
described: described:
The device's Initial Device Identifier (IDevID) will normally contain The device's Initial Device Identifier (IDevID) will normally contain
the MASA URL as detailed in Section 2.3. This is the RECOMMENDED the MASA URL as detailed in Section 2.3. This is the RECOMMENDED
mechanism. mechanism.
If the registrar is integrated with [RFC8520] and the pledge IDevID
contains the id-pe-mud-url then the registrar MAY attempt to obtain
the MASA URL from the MUD file. The MUD file extension for the MASA
URL is defined in Appendix C.
It can be operationally difficult to ensure the necessary X.509 It can be operationally difficult to ensure the necessary X.509
extensions are in the pledge's IDevID due to the difficulty of extensions are in the pledge's IDevID due to the difficulty of
aligning current pledge manufacturing with software releases and aligning current pledge manufacturing with software releases and
development. As a final fallback the registrar MAY be manually development. As a final fallback the registrar MAY be manually
configured or distributed with a MASA URL for each manufacturer. configured or distributed with a MASA URL for each manufacturer.
Note that the registrar can only select the configured MASA URL based Note that the registrar can only select the configured MASA URL based
on the trust anchor -- so manufacturers can only leverage this on the trust anchor -- so manufacturers can only leverage this
approach if they ensure a single MASA URL works for all pledges approach if they ensure a single MASA URL works for all pledges
associated with each trust anchor. associated with each trust anchor.
skipping to change at page 28, line 4 skipping to change at page 27, line 49
+---- proximity-registrar-cert? binary +---- proximity-registrar-cert? binary
Figure 5: YANG Tree diagram for Voucher-Request Figure 5: YANG Tree diagram for Voucher-Request
3.3. Examples 3.3. Examples
This section provides voucher-request examples for illustration This section provides voucher-request examples for illustration
purposes. These examples show the JSON prior to CMS wrapping. JSON purposes. These examples show the JSON prior to CMS wrapping. JSON
encoding rules specify that any binary content by base64 encoded encoding rules specify that any binary content by base64 encoded
([RFC4648]). The contents of the certificate have been elided to ([RFC4648]). The contents of the certificate have been elided to
save space. For detailed examples, see Appendix D.2. These examples save space. For detailed examples, see Appendix C.2. These examples
conform to the encoding rules defined in [RFC7951]. conform to the encoding rules defined in [RFC7951].
Example (1) The following example illustrates a pledge voucher- Example (1) The following example illustrates a pledge voucher-
request. The assertion leaf is indicated as 'proximity' request. The assertion leaf is indicated as 'proximity'
and the registrar's TLS server certificate is included and the registrar's TLS server certificate is included
in the 'proximity-registrar-cert' leaf. See in the 'proximity-registrar-cert' leaf. See
Section 5.2. Section 5.2.
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
skipping to change at page 50, line 39 skipping to change at page 50, line 39
Figure 14: An example voucher Figure 14: An example voucher
The MASA populates the voucher fields as follows: The MASA populates the voucher fields as follows:
nonce: The nonce from the pledge if available. See Section 5.5.6. nonce: The nonce from the pledge if available. See Section 5.5.6.
assertion: The method used to verify the relationship between pledge assertion: The method used to verify the relationship between pledge
and registrar. See Section 5.5.5. and registrar. See Section 5.5.5.
pinned-domain-cert: The domain CA cert. See Section 5.5.2. This pinned-domain-cert: The domain CA cert. See Section 5.5.2. This
figure is illustrative, for an example, see Appendix D.2 figure is illustrative, for an example, see Appendix C.2
serial-number: The serial-number as provided in the voucher-request. serial-number: The serial-number as provided in the voucher-request.
Also see Section 5.5.5. Also see Section 5.5.5.
domain-cert-revocation-checks: Set as appropriate for the pledge's domain-cert-revocation-checks: Set as appropriate for the pledge's
capabilities and as documented in [RFC8366]. The MASA MAY set capabilities and as documented in [RFC8366]. The MASA MAY set
this field to 'false' since setting it to 'true' would require this field to 'false' since setting it to 'true' would require
that revocation information be available to the pledge and this that revocation information be available to the pledge and this
document does not make normative requirements for [RFC6961] or document does not make normative requirements for [RFC6961] or
equivalent integrations. equivalent integrations.
skipping to change at page 70, line 42 skipping to change at page 70, line 42
Reference: [This document] Reference: [This document]
Service Name: brski-registrar Service Name: brski-registrar
Transport Protocol(s): tcp Transport Protocol(s): tcp
Assignee: IESG <iesg@ietf.org>. Assignee: IESG <iesg@ietf.org>.
Contact: IESG <iesg@ietf.org> Contact: IESG <iesg@ietf.org>
Description: The Bootstrapping Remote Secure Key Description: The Bootstrapping Remote Secure Key
Infrastructures Registrar Infrastructures Registrar
Reference: [This document] Reference: [This document]
8.6. MUD File Extension for the MASA
The IANA is requested to list the name "masa" in the MUD extensions
registry defined in [RFC8520]. Its use is documented in Appendix C.
9. Applicability to the Autonomic Control Plane (ACP) 9. Applicability to the Autonomic Control Plane (ACP)
This document provides a solution to the requirements for secure This document provides a solution to the requirements for secure
bootstrap set out in Using an Autonomic Control Plane for Stable bootstrap set out in Using an Autonomic Control Plane for Stable
Connectivity of Network Operations, Administration, and Maintenance Connectivity of Network Operations, Administration, and Maintenance
[RFC8368], A Reference Model for Autonomic Networking [RFC8368], A Reference Model for Autonomic Networking
[I-D.ietf-anima-reference-model] and specifically the An Autonomic [I-D.ietf-anima-reference-model] and specifically the An Autonomic
Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane], section Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane], section
3.2 (Secure Bootstrap), and section 6.1 (ACP Domain, Certificate and 3.2 (Secure Bootstrap), and section 6.1 (ACP Domain, Certificate and
Network). Network).
The protocol described in this document has appeal in a number of The protocol described in this document has appeal in a number of
other non-ANIMA use cases. Such uses of the protocol will be other non-ANIMA use cases. Such uses of the protocol will be
deploying into other environments with different tradeoffs of deploying into other environments with different tradeoffs of
privacy, security, reliability and autonomy from manufacturers. As privacy, security, reliability and autonomy from manufacturers. As
such those use cases will need to provide their own applicability such those use cases will need to provide their own applicability
skipping to change at page 75, line 37 skipping to change at page 75, line 33
Research into a mechanism to do multi-step, multi-party authenticated Research into a mechanism to do multi-step, multi-party authenticated
key agreement, incorporating some kind of zero-knowledge proof would key agreement, incorporating some kind of zero-knowledge proof would
be valuable. Such a mechanism would ideally avoid disclosing be valuable. Such a mechanism would ideally avoid disclosing
identities until pledge, registrar and MASA agree to the transaction. identities until pledge, registrar and MASA agree to the transaction.
Such a mechanism would need to discover the location of the MASA Such a mechanism would need to discover the location of the MASA
without knowing the identity of the pledge, or the identity of the without knowing the identity of the pledge, or the identity of the
MASA. This part of the problem may be unsolveable. MASA. This part of the problem may be unsolveable.
10.3. What BRSKI-MASA reveals to the manufacturer 10.3. What BRSKI-MASA reveals to the manufacturer
With consumer-oriented devices, the "call-home" mechanism in IoT The so-called "call-home" mechanism that occurs as part of the BRSKI-
devices raises significant privacy concerns. See [livingwithIoT] and MASA connection standardizes what has been deemed by some as a
[IoTstrangeThings] for exemplars. The Autonomic Control Plane (ACP) sinister mechanism for corporate oversight of individuals.
usage of BRSKI is not targeted at individual usage of IoT devices, ([livingwithIoT] and [IoTstrangeThings] for a small sample).
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 lifecycle management concerns.
As the Autonomic Control Plane (ACP) usage of BRSKI is not targeted As the Autonomic Control Plane (ACP) usage of BRSKI is not targeted
at individual usage of IoT devices, but rather at the Enterprise and at individual usage of IoT devices, but rather at the Enterprise and
ISP creation of networks in a zero-touch fashion, the "call-home" ISP creation of networks in a zero-touch fashion, the "call-home"
represents a different kind of concern. represents a different kind of concern.
It needs to be re-iterated that the BRSKI-MASA mechanism only occurs It needs to be re-iterated that the BRSKI-MASA mechanism only occurs
once during the commissioning of the device. It is well defined, and once during the commissioning of the device. It is well defined, and
although encrypted with TLS, it could in theory be made auditable as although encrypted with TLS, it could in theory be made auditable as
the contents are well defined. This connection does not occur when the contents are well defined. This connection does not occur when
skipping to change at page 90, line 16 skipping to change at page 90, line 12
members, including Adam Roach, Alexey Melnikov, Alissa Cooper, members, including Adam Roach, Alexey Melnikov, Alissa Cooper,
Benjamin Kaduk, Eric Vyncke, Roman Danyliw, and Magnus Westerlund. Benjamin Kaduk, Eric Vyncke, Roman Danyliw, and Magnus Westerlund.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-anima-autonomic-control-plane] [I-D.ietf-anima-autonomic-control-plane]
Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
Control Plane (ACP)", draft-ietf-anima-autonomic-control- Control Plane (ACP)", draft-ietf-anima-autonomic-control-
plane-20 (work in progress), July 2019. plane-21 (work in progress), November 2019.
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009, [IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009,
<http://standards.ieee.org/findstds/standard/802.1AR- <http://standards.ieee.org/findstds/standard/802.1AR-
2009.html>. 2009.html>.
skipping to change at page 94, line 24 skipping to change at page 94, line 19
operator-v2.0.pdf>. operator-v2.0.pdf>.
[docsisroot] [docsisroot]
"CableLabs Digital Certificate Issuance Service", February "CableLabs Digital Certificate Issuance Service", February
2018, <https://www.cablelabs.com/resources/digital- 2018, <https://www.cablelabs.com/resources/digital-
certificate-issuance-service/>. certificate-issuance-service/>.
[I-D.ietf-ace-coap-est] [I-D.ietf-ace-coap-est]
Stok, P., Kampanakis, P., Richardson, M., and S. Raza, Stok, P., Kampanakis, P., Richardson, M., and S. Raza,
"EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap-
est-16 (work in progress), October 2019. est-17 (work in progress), December 2019.
[I-D.ietf-anima-constrained-voucher] [I-D.ietf-anima-constrained-voucher]
Richardson, M., Stok, P., and P. Kampanakis, "Constrained Richardson, M., Stok, P., and P. Kampanakis, "Constrained
Voucher Artifacts for Bootstrapping Protocols", draft- Voucher Artifacts for Bootstrapping Protocols", draft-
ietf-anima-constrained-voucher-05 (work in progress), July ietf-anima-constrained-voucher-05 (work in progress), July
2019. 2019.
[I-D.ietf-anima-reference-model] [I-D.ietf-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
and J. Nobre, "A Reference Model for Autonomic and J. Nobre, "A Reference Model for Autonomic
skipping to change at page 94, line 46 skipping to change at page 94, line 41
progress), November 2018. progress), November 2018.
[I-D.ietf-anima-stable-connectivity] [I-D.ietf-anima-stable-connectivity]
Eckert, T. and M. Behringer, "Using Autonomic Control Eckert, T. and M. Behringer, "Using Autonomic Control
Plane for Stable Connectivity of Network OAM", draft-ietf- Plane for Stable Connectivity of Network OAM", draft-ietf-
anima-stable-connectivity-10 (work in progress), February anima-stable-connectivity-10 (work in progress), February
2018. 2018.
[I-D.ietf-netconf-keystore] [I-D.ietf-netconf-keystore]
Watsen, K., "A YANG Data Model for a Keystore", draft- Watsen, K., "A YANG Data Model for a Keystore", draft-
ietf-netconf-keystore-14 (work in progress), November ietf-netconf-keystore-15 (work in progress), November
2019. 2019.
[I-D.richardson-anima-state-for-joinrouter] [I-D.richardson-anima-state-for-joinrouter]
Richardson, M., "Considerations for stateful vs stateless Richardson, M., "Considerations for stateful vs stateless
join router in ANIMA bootstrap", draft-richardson-anima- join router in ANIMA bootstrap", draft-richardson-anima-
state-for-joinrouter-02 (work in progress), January 2018. state-for-joinrouter-02 (work in progress), January 2018.
[imprinting] [imprinting]
"Wikipedia article: Imprinting", July 2015, "Wikipedia article: Imprinting", July 2015,
<https://en.wikipedia.org/wiki/Imprinting_(psychology)>. <https://en.wikipedia.org/wiki/Imprinting_(psychology)>.
skipping to change at page 98, line 30 skipping to change at page 98, line 28
service. Also see Section 2.7. service. Also see Section 2.7.
The current DNS services returned during each query are maintained The current DNS services returned during each query are maintained
until bootstrapping is completed. If bootstrapping fails and the until bootstrapping is completed. If bootstrapping fails and the
pledge returns to the Discovery state, it picks up where it left off pledge returns to the Discovery state, it picks up where it left off
and continues attempting bootstrapping. For example, if the first and continues attempting bootstrapping. For example, if the first
Multicast DNS _bootstrapks._tcp.local response doesn't work then the Multicast DNS _bootstrapks._tcp.local response doesn't work then the
second and third responses are tried. If these fail the pledge moves second and third responses are tried. If these fail the pledge moves
on to normal DNS-based Service Discovery. on to normal DNS-based Service Discovery.
Appendix C. MUD Extension Appendix C. Example Vouchers
The following extension augments the MUD model to include a single
node, as described in [RFC8520] section 3.6, using the following
sample module that has the following tree structure:
module: ietf-mud-brski-masa
augment /ietf-mud:mud:
+--rw masa-server? inet:uri
The model is defined as follows:
<CODE BEGINS> file "ietf-mud-brski-masaurl-extension@2018-02-14.yang"
module ietf-mud-brski-masa {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa";
prefix ietf-mud-brski-masa;
import ietf-mud {
prefix ietf-mud;
}
import ietf-inet-types {
prefix inet;
}
organization
"IETF ANIMA (Autonomic Networking Integrated Model and
Approach) Working Group";
contact
"WG Web: http://tools.ietf.org/wg/anima/
WG List: anima@ietf.org
";
description
"BRSKI extension to a MUD file to indicate the
MASA URL.";
revision 2018-02-14 {
description
"Initial revision.";
reference
"RFC XXXX: Manufacturer Usage Description
Specification";
}
augment "/ietf-mud:mud" {
description
"BRSKI extension to a MUD file to indicate the
MASA URL.";
leaf masa-server {
type inet:uri;
description
"This value is the URI of the MASA server";
}
}
}
<CODE ENDS>
The MUD extensions string "masa" is defined, and MUST be included in
the extensions array of the mud container of a MUD file when this
extension is used.
Appendix D. Example Vouchers
Three entities are involved in a voucher: the MASA issues (signs) it, Three entities are involved in a voucher: the MASA issues (signs) it,
the registrar's public key is mentioned in the voucher, and the the registrar's public key is mentioned in the voucher, and the
pledge validates it. In order to provide reproduceable examples the pledge validates it. In order to provide reproduceable examples the
public and private keys for an example MASA and registrar are first public and private keys for an example MASA and registrar are first
listed. listed.
D.1. Keys involved C.1. Keys involved
The Manufacturer has a Certificate Authority that signs the pledge's The Manufacturer has a Certificate Authority that signs the pledge's
IDevID. In addition the Manufacturer's signing authority (the MASA) IDevID. In addition the Manufacturer's signing authority (the MASA)
signs the vouchers, and that certificate must distributed to the signs the vouchers, and that certificate must distributed to the
devices at manufacturing time so that vouchers can be validated. devices at manufacturing time so that vouchers can be validated.
D.1.1. MASA key pair for voucher signatures C.1.1. MASA key pair for voucher signatures
This private key signs vouchers: This private key signs vouchers:
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho
r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA
zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz
Tvv+5PV++elkP9HQ83vqTAws2WwWTxI= Tvv+5PV++elkP9HQ83vqTAws2WwWTxI=
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
This public key validates vouchers: This public key validates vouchers:
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIBzzCCAVagAwIBAgIBATAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC MIIBzzCCAVagAwIBAgIBATAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC
Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n
IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw
EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU
BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R
b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf
w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO
skipping to change at page 100, line 46 skipping to change at page 99, line 19
IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw
EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU
BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R
b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf
w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO
MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O
DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd
MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw= MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw=
-----END CERTIFICATE----- -----END CERTIFICATE-----
D.1.2. Manufacturer key pair for IDevID signatures C.1.2. Manufacturer key pair for IDevID signatures
This private key signs IDevID certificates: This private key signs IDevID certificates:
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho
r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA
zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz
Tvv+5PV++elkP9HQ83vqTAws2WwWTxI= Tvv+5PV++elkP9HQ83vqTAws2WwWTxI=
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
skipping to change at page 101, line 27 skipping to change at page 99, line 45
IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw
EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU
BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R
b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf
w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO
MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O
DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd
MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw= MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw=
-----END CERTIFICATE----- -----END CERTIFICATE-----
D.1.3. Registrar key pair C.1.3. Registrar key pair
The registrar key (or chain) is the representative of the domain The registrar key (or chain) is the representative of the domain
owner. This key signs registrar voucher-requests: owner. This key signs registrar voucher-requests:
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MHcCAQEEIF+obiToYYYeMifPsZvrjWJ0yFsCJwIFhpokmT/TULmXoAoGCCqGSM49 MHcCAQEEIF+obiToYYYeMifPsZvrjWJ0yFsCJwIFhpokmT/TULmXoAoGCCqGSM49
AwEHoUQDQgAENWQOzcNMUjP0NrtfeBc0DJLWfeMGgCFdIv6FUz4DifM1ujMBec/g AwEHoUQDQgAENWQOzcNMUjP0NrtfeBc0DJLWfeMGgCFdIv6FUz4DifM1ujMBec/g
6W/P6boTmyTGdFOh/8HwKUerL5bpneK8sg== 6W/P6boTmyTGdFOh/8HwKUerL5bpneK8sg==
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
skipping to change at page 102, line 4 skipping to change at page 100, line 26
Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVuc3RydW5n Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVuc3RydW5n
IEZvdW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAxMTI0NVowQzES IEZvdW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAxMTI0NVowQzES
MBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRIw MBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRIw
EAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQ1ZA7N EAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQ1ZA7N
w0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6MwF5z+Dpb8/puhObJMZ0U6H/ w0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6MwF5z+Dpb8/puhObJMZ0U6H/
wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAAMAoGCCqGSM49BAMDA2kAMGYCMQC3 wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAAMAoGCCqGSM49BAMDA2kAMGYCMQC3
/iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY2jkDx062nuNifVKtyaara3F30AIkKSEC /iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY2jkDx062nuNifVKtyaara3F30AIkKSEC
MQDi29efbTLbdtDk3tecY/rD7V77XaJ6nYCmdDCR54TrSFNLgxvt1lyFM+0fYpYR MQDi29efbTLbdtDk3tecY/rD7V77XaJ6nYCmdDCR54TrSFNLgxvt1lyFM+0fYpYR
c3o= c3o=
-----END CERTIFICATE----- -----END CERTIFICATE-----
The registrar public certificate as decoded by openssl's x509 The registrar public certificate as decoded by openssl's x509
utility. Note that the registrar certificate is marked with the utility. Note that the registrar certificate is marked with the
cmcRA extension. cmcRA extension.
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 3 (0x3) Serial Number: 3 (0x3)
Signature Algorithm: ecdsa-with-SHA384 Signature Algorithm: ecdsa-with-SHA384
Issuer: DC = ca, DC = sandelman, CN = Unstrung Fount Issuer: DC=ca, DC=sandelman, CN=Unstrung Fountain CA
ain CA
Validity Validity
Not Before: Sep 5 01:12:45 2017 GMT Not Before: Sep 5 01:12:45 2017 GMT
Not After : Sep 5 01:12:45 2019 GMT Not After : Sep 5 01:12:45 2019 GMT
Subject: DC = ca, DC = sandelman, CN = localhost Subject: DC=ca, DC=sandelman, CN=localhost
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04:35:64:0e:cd:c3:4c:52:33:f4:36:bb:5f:7 04:35:64:0e:cd:c3:4c:52:33:f4:36:bb:5f:7
8:17: 8:17:
34:0c:92:d6:7d:e3:06:80:21:5d:22:fe:85:5 34:0c:92:d6:7d:e3:06:80:21:5d:22:fe:85:5
3:3e: 3:3e:
03:89:f3:35:ba:33:01:79:cf:e0:e9:6f:cf:e 03:89:f3:35:ba:33:01:79:cf:e0:e9:6f:cf:e
9:ba: 9:ba:
13:9b:24:c6:74:53:a1:ff:c1:f0:29:47:ab:2 13:9b:24:c6:74:53:a1:ff:c1:f0:29:47:ab:2
f:96: f:96:
e9:9d:e2:bc:b2 e9:9d:e2:bc:b2
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions: X509v3 extensions:
X509v3 Basic Constraints: X509v3 Basic Constraints:
CA:FALSE CA:FALSE
Signature Algorithm: ecdsa-with-SHA384 Signature Algorithm: ecdsa-with-SHA384
30:66:02:31:00:b7:fe:24:d0:27:77:af:61:87:20:6d:78: 30:66:02:31:00:b7:fe:24:d0:27:77:af:61:87:20:6d:78:
5b: 5b:
9b:3a:e9:eb:8b:77:40:2e:aa:8c:87:98:da:39:03:c7:4e: 9b:3a:e9:eb:8b:77:40:2e:aa:8c:87:98:da:39:03:c7:4e:
b6: b6:
9e:e3:62:7d:52:ad:c9:a6:ab:6b:71:77:d0:02:24:29:21: 9e:e3:62:7d:52:ad:c9:a6:ab:6b:71:77:d0:02:24:29:21:
02: 02:
31:00:e2:db:d7:9f:6d:32:db:76:d0:e4:de:d7:9c:63:fa: 31:00:e2:db:d7:9f:6d:32:db:76:d0:e4:de:d7:9c:63:fa:
c3: c3:
ed:5e:fb:5d:a2:7a:9d:80:a6:74:30:91:e7:84:eb:48:53: ed:5e:fb:5d:a2:7a:9d:80:a6:74:30:91:e7:84:eb:48:53:
4b: 4b:
83:1b:ed:d6:5c:85:33:ed:1f:62:96:11:73:7a 83:1b:ed:d6:5c:85:33:ed:1f:62:96:11:73:7a
D.1.4. Pledge key pair C.1.4. Pledge key pair
The pledge has an IDevID key pair built in at manufacturing time: The pledge has an IDevID key pair built in at manufacturing time:
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MHcCAQEEIBgR6SV+uEvWfl5zCQWZxWjYbMhXPyNqdHJ3KPh11mm4oAoGCCqGSM49 MHcCAQEEIBgR6SV+uEvWfl5zCQWZxWjYbMhXPyNqdHJ3KPh11mm4oAoGCCqGSM49
AwEHoUQDQgAEWi/jqPpRJ0JgWghZRgeZlLKutbXVjmnHb+1AYaEF/YQjE2g5FZV8 AwEHoUQDQgAEWi/jqPpRJ0JgWghZRgeZlLKutbXVjmnHb+1AYaEF/YQjE2g5FZV8
KjiR/bkEl+l8M4onIC7KHaXKKkuag9S6Tw== KjiR/bkEl+l8M4onIC7KHaXKKkuag9S6Tw==
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
The public key is used by the registrar to find the MASA. The MASA The public key is used by the registrar to find the MASA. The MASA
skipping to change at page 104, line 43 skipping to change at page 103, line 43
1.3.6.1.4.1.46930.2: 1.3.6.1.4.1.46930.2:
..masa.honeydukes.sandelman.ca ..masa.honeydukes.sandelman.ca
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
30:64:02:30:26:bc:c8:e6:36:08:f2:a4:38:5c:7f:29:cc:57: 30:64:02:30:26:bc:c8:e6:36:08:f2:a4:38:5c:7f:29:cc:57:
79:0c:b8:8a:52:2a:b6:33:45:6a:f8:83:73:ed:4f:05:c3:b0: 79:0c:b8:8a:52:2a:b6:33:45:6a:f8:83:73:ed:4f:05:c3:b0:
07:b4:a2:2b:53:4e:3e:10:b5:4d:5b:6a:38:4e:7d:39:02:30: 07:b4:a2:2b:53:4e:3e:10:b5:4d:5b:6a:38:4e:7d:39:02:30:
63:0d:6e:c5:b6:43:8d:45:cf:db:7a:3c:35:5d:b4:e2:9a:6c: 63:0d:6e:c5:b6:43:8d:45:cf:db:7a:3c:35:5d:b4:e2:9a:6c:
16:c0:3f:54:55:a0:54:e5:0d:0b:8e:f6:79:8b:cd:be:64:53: 16:c0:3f:54:55:a0:54:e5:0d:0b:8e:f6:79:8b:cd:be:64:53:
e7:14:a8:2b:4f:44:56:41:51:73:f7:92 e7:14:a8:2b:4f:44:56:41:51:73:f7:92
D.2. Example process C.2. Example process
The JSON examples below are wrapped at 60 columns. This results in The JSON examples below are wrapped at 60 columns. This results in
strings that have newlines in them, which makes them invalid JSON as 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 is. The strings would otherwise be too long, so they need to be
unwrapped before processing. unwrapped before processing.
D.2.1. Pledge to Registrar C.2.1. Pledge to Registrar
As described in Section 5.2, the pledge will sign a pledge voucher- As described in Section 5.2, the pledge will sign a pledge voucher-
request containing the registrar's public key in the proximity- request containing the registrar's public key in the proximity-
registrar-cert field. The base64 has been wrapped at 60 characters registrar-cert field. The base64 has been wrapped at 60 characters
for presentation reasons. for presentation reasons.
-----BEGIN CMS----- -----BEGIN CMS-----
MIIGtQYJKoZIhvcNAQcCoIIGpjCCBqICAQExDTALBglghkgBZQMEAgEwggNRBgkq MIIGtQYJKoZIhvcNAQcCoIIGpjCCBqICAQExDTALBglghkgBZQMEAgEwggNRBgkq
hkiG9w0BBwGgggNCBIIDPnsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6 hkiG9w0BBwGgggNCBIIDPnsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6
eyJhc3NlcnRpb24iOiJwcm94aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAxOS0wNS0x eyJhc3NlcnRpb24iOiJwcm94aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAxOS0wNS0x
skipping to change at page 108, line 27 skipping to change at page 107, line 27
W4xQDA+BgNVBAMMNyM8U3lzdGVtVmFyaWFibGU6MHgwMDAwMDAwNGY5MTFhM W4xQDA+BgNVBAMMNyM8U3lzdGVtVmFyaWFibGU6MHgwMDAwMDAwNGY5MTFhM
D4gVW5zdHJ1bmcgRm91bnRhaW4gQ0EwHhcNMTcxMTA3MjM0NTI4WhcNMTkxM D4gVW5zdHJ1bmcgRm91bnRhaW4gQ0EwHhcNMTcxMTA3MjM0NTI4WhcNMTkxM
TA3MjM0NTI4WjBDMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZ TA3MjM0NTI4WjBDMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZ
AEZFglzYW5kZWxtYW4xEjAQBgNVBAMMCWxvY2FsaG9zdDBZMBMGByqGSM49A AEZFglzYW5kZWxtYW4xEjAQBgNVBAMMCWxvY2FsaG9zdDBZMBMGByqGSM49A
gEGCCqGSM49AwEHA0IABJZlUHI0up/l3eZf9vCBb+lInoEMEgc7Ro+XZCtjA gEGCCqGSM49AwEHA0IABJZlUHI0up/l3eZf9vCBb+lInoEMEgc7Ro+XZCtjA
I0CD1fJfJR/hIyyDmHWyYiNFbRCH9fyarfkzgX4p0zTizqjDTALMAkGA1UdE I0CD1fJfJR/hIyyDmHWyYiNFbRCH9fyarfkzgX4p0zTizqjDTALMAkGA1UdE
wQCMAAwCgYIKoZIzj0EAwMDaQAwZgIxALQMNurf8tv50lROD5DQXHEOJJNW3 wQCMAAwCgYIKoZIzj0EAwMDaQAwZgIxALQMNurf8tv50lROD5DQXHEOJJNW3
QV2g9QEdDSk2MY+AoSrBSmGSNjh4olEOhEuLgIxAJ4nWfNw+BjbZmKiIiUEc QV2g9QEdDSk2MY+AoSrBSmGSNjh4olEOhEuLgIxAJ4nWfNw+BjbZmKiIiUEc
TwHMhGVXaMHY/F7n39wwKcBBSOndNPqCpOELl6bq3CZqQ=="}} TwHMhGVXaMHY/F7n39wwKcBBSOndNPqCpOELl6bq3CZqQ=="}}
D.2.2. Registrar to MASA C.2.2. Registrar to MASA
As described in Section 5.5 the registrar will sign a registrar As described in Section 5.5 the registrar will sign a registrar
voucher-request, and will include pledge's voucher request in the voucher-request, and will include pledge's voucher request in the
prior-signed-voucher-request. prior-signed-voucher-request.
-----BEGIN CMS----- -----BEGIN CMS-----
MIIPkwYJKoZIhvcNAQcCoIIPhDCCD4ACAQExDTALBglghkgBZQMEAgEwggnUBgkq MIIPkwYJKoZIhvcNAQcCoIIPhDCCD4ACAQExDTALBglghkgBZQMEAgEwggnUBgkq
hkiG9w0BBwGgggnFBIIJwXsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6 hkiG9w0BBwGgggnFBIIJwXsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6
eyJhc3NlcnRpb24iOiJwcm94aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAxOS0wNS0x eyJhc3NlcnRpb24iOiJwcm94aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAxOS0wNS0x
NVQyMToyNTo1NS43NThaIiwic2VyaWFsLW51bWJlciI6IjAwLWQwLWU1LTAyLTAw NVQyMToyNTo1NS43NThaIiwic2VyaWFsLW51bWJlciI6IjAwLWQwLWU1LTAyLTAw
skipping to change at page 113, line 43 skipping to change at page 112, line 43
3840:d=7 hl=2 l= 15 cons: SET 3840:d=7 hl=2 l= 15 cons: SET
3842:d=8 hl=2 l= 13 prim: UTCTIME :190515212555Z 3842:d=8 hl=2 l= 13 prim: UTCTIME :190515212555Z
3857:d=6 hl=2 l= 47 cons: SEQUENCE 3857:d=6 hl=2 l= 47 cons: SEQUENCE
3859:d=7 hl=2 l= 9 prim: OBJECT :messageDigest 3859:d=7 hl=2 l= 9 prim: OBJECT :messageDigest
3870:d=7 hl=2 l= 34 cons: SET 3870:d=7 hl=2 l= 34 cons: SET
3872:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:50508CC996CD93 3872:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:50508CC996CD93
3906:d=5 hl=2 l= 10 cons: SEQUENCE 3906:d=5 hl=2 l= 10 cons: SEQUENCE
3908:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 3908:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
3918:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:3045022006D85B 3918:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:3045022006D85B
D.2.3. MASA to Registrar C.2.3. MASA to Registrar
The MASA will return a voucher to the registrar, to be relayed to the The MASA will return a voucher to the registrar, to be relayed to the
pledge. pledge.
-----BEGIN CMS----- -----BEGIN CMS-----
MIIGsgYJKoZIhvcNAQcCoIIGozCCBp8CAQExDTALBglghkgBZQMEAgEwggNABgkq MIIGsgYJKoZIhvcNAQcCoIIGozCCBp8CAQExDTALBglghkgBZQMEAgEwggNABgkq
hkiG9w0BBwGgggMxBIIDLXsiaWV0Zi12b3VjaGVyOnZvdWNoZXIiOnsiYXNzZXJ0 hkiG9w0BBwGgggMxBIIDLXsiaWV0Zi12b3VjaGVyOnZvdWNoZXIiOnsiYXNzZXJ0
aW9uIjoibG9nZ2VkIiwiY3JlYXRlZC1vbiI6IjIwMTktMDUtMTZUMDI6NTE6NDIu aW9uIjoibG9nZ2VkIiwiY3JlYXRlZC1vbiI6IjIwMTktMDUtMTZUMDI6NTE6NDIu
Njk3KzAwOjAwIiwic2VyaWFsLW51bWJlciI6IjAwLWQwLWU1LTAyLTAwLTJkIiwi Njk3KzAwOjAwIiwic2VyaWFsLW51bWJlciI6IjAwLWQwLWU1LTAyLTAwLTJkIiwi
bm9uY2UiOiJHWmUtT2pvZXJwS0VNNFNNN1N6UzlnIiwicGlubmVkLWRvbWFpbi1j bm9uY2UiOiJHWmUtT2pvZXJwS0VNNFNNN1N6UzlnIiwicGlubmVkLWRvbWFpbi1j
 End of changes. 33 change blocks. 
120 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/