draft-ietf-anima-bootstrapping-keyinfra-31.txt   draft-ietf-anima-bootstrapping-keyinfra-32.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: June 18, 2020 Sandelman Expires: 3 July 2020 Sandelman
T. Eckert T.T.E. Eckert
Futurewei USA Futurewei USA
M. Behringer M.H. Behringer
K. Watsen K.W. Watsen
Watsen Networks Watsen Networks
December 16, 2019 31 December 2019
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-31 draft-ietf-anima-bootstrapping-keyinfra-32
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 June 18, 2020. This Internet-Draft will expire on 3 July 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as 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 . . . . . . . . . . . . . . . . . 10 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
skipping to change at page 3, line 4 skipping to change at page 2, line 51
2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.2. Join Proxy . . . . . . . . . . . . . . . . . . . . . 23 2.5.2. Join Proxy . . . . . . . . . . . . . . . . . . . . . 23
2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 23 2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 23
2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 23 2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 23
2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 24 2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 24
2.6. Certificate Time Validation . . . . . . . . . . . . . . . 24 2.6. Certificate Time Validation . . . . . . . . . . . . . . . 24
2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 24 2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 24
2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 24 2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 24
2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 25 2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 25
2.8. Determining the MASA to contact . . . . . . . . . . . . . 25 2.8. Determining the MASA to contact . . . . . . . . . . . . . 25
3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 26 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 26
3.1. Nonceless Voucher Requests . . . . . . . . . . . . . . . 27 3.1. Nonceless Voucher Requests . . . . . . . . . . . . . . . 27
3.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 27 3.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 27
3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 29 3.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 29
4. Proxying details (Pledge - Proxy - 4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 32
Registrar) . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 33 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 33
4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 35 4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 35
4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 36 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 36
4.3. Proxy discovery and communication of Registrar . . . . . 36 4.3. Proxy discovery and communication of Registrar . . . . . 36
5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 38 5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 38
5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 39 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 39
5.2. Pledge Requests Voucher from the Registrar . . . . . . . 40 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 40
5.3. Registrar Authorization of 5.3. Registrar Authorization of Pledge . . . . . . . . . . . . 42
Pledge . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 43 5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 43
5.4.1. MASA authentication of 5.4.1. MASA authentication of customer Registrar . . . . . . 43
customer Registrar . . . . . . . . . . . . . . . . . 43
5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 44 5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 44
5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 46 5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 46
5.5.2. MASA pinning of registrar . . . . . . . . . . . . . . 46 5.5.2. MASA pinning of registrar . . . . . . . . . . . . . . 46
5.5.3. MASA checking of voucher request signature . . . . . 46 5.5.3. MASA checking of voucher request signature . . . . . 46
5.5.4. MASA verification of domain registrar . . . . . . . . 47 5.5.4. MASA verification of domain registrar . . . . . . . . 47
5.5.5. MASA verification of pledge prior-signed-voucher- 5.5.5. MASA verification of pledge
request . . . . . . . . . . . . . . . . . . . . . . . 48 prior-signed-voucher-request . . . . . . . . . . . . 48
5.5.6. MASA nonce handling . . . . . . . . . . . . . . . . . 48 5.5.6. MASA nonce handling . . . . . . . . . . . . . . . . . 48
5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 48 5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 48
5.6.1. Pledge voucher verification . . . . . . . . . . . . . 51 5.6.1. Pledge voucher verification . . . . . . . . . . . . . 51
5.6.2. Pledge authentication of provisional TLS connection . 52 5.6.2. Pledge authentication of provisional TLS
connection . . . . . . . . . . . . . . . . . . . . . 52
5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 53 5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 53
5.8. Registrar audit-log request . . . . . . . . . . . . . . . 54 5.8. Registrar audit-log request . . . . . . . . . . . . . . . 54
5.8.1. MASA audit log response . . . . . . . . . . . . . . . 55 5.8.1. MASA audit log response . . . . . . . . . . . . . . . 55
5.8.2. Calculation of domainID . . . . . . . . . . . . . . . 58 5.8.2. Calculation of domainID . . . . . . . . . . . . . . . 58
5.8.3. Registrar audit log verification . . . . . . . . . . 58 5.8.3. Registrar audit log verification . . . . . . . . . . 58
5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 60 5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 60
5.9.1. EST Distribution of CA Certificates . . . . . . . . . 60 5.9.1. EST Distribution of CA Certificates . . . . . . . . . 60
5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 60 5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 60
5.9.3. EST Client Certificate Request . . . . . . . . . . . 61 5.9.3. EST Client Certificate Request . . . . . . . . . . . 61
5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 61 5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 61
5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 62 5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 63
5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 63 5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 63
6. Clarification of transfer-encoding . . . . . . . . . . . . . 63 6. Clarification of transfer-encoding . . . . . . . . . . . . . 63
7. Reduced security operational modes . . . . . . . . . . . . . 63 7. Reduced security operational modes . . . . . . . . . . . . . 63
7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 64 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 64
7.2. Pledge security reductions . . . . . . . . . . . . . . . 64 7.2. Pledge security reductions . . . . . . . . . . . . . . . 64
7.3. Registrar security reductions . . . . . . . . . . . . . . 65 7.3. Registrar security reductions . . . . . . . . . . . . . . 65
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
skipping to change at page 4, line 7 skipping to change at page 4, line 4
5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 63 5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 63
6. Clarification of transfer-encoding . . . . . . . . . . . . . 63 6. Clarification of transfer-encoding . . . . . . . . . . . . . 63
7. Reduced security operational modes . . . . . . . . . . . . . 63 7. Reduced security operational modes . . . . . . . . . . . . . 63
7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 64 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 64
7.2. Pledge security reductions . . . . . . . . . . . . . . . 64 7.2. Pledge security reductions . . . . . . . . . . . . . . . 64
7.3. Registrar security reductions . . . . . . . . . . . . . . 65 7.3. Registrar security reductions . . . . . . . . . . . . . . 65
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. The IETF XML Registry . . . . . . . . . . . . . . . . . . 69
8.3. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 69 8.3. Well-known EST registration . . . . . . . . . . . . . . . 69
8.4. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 70 8.4. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 70
8.5. DNS Service Names . . . . . . . . . . . . . . . . . . . . 70 8.5. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 70
9. Applicability to the Autonomic Control Plane (ACP) . . . . . 70 8.6. DNS Service Names . . . . . . . . . . . . . . . . . . . . 70
9. Applicability to the Autonomic Control Plane (ACP) . . . . . 71
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 . . . . . . . . . . . 74
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 . . . . . . . . . . . . . . . . . 75
10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 75 10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 76
10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 77 10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 78
10.5. Manufacturers and Grey market equipment . . . . . . . . 78 10.5. Manufacturers and Grey market equipment . . . . . . . . 79
10.6. Some mitigations for meddling by manufacturers . . . . . 79 10.6. Some mitigations for meddling by manufacturers . . . . . 80
10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 80 10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 81
11. Security Considerations . . . . . . . . . . . . . . . . . . . 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 81
11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 81 11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 82
11.2. DomainID must be resistant to second-preimage attacks . 82 11.2. DomainID must be resistant to second-preimage attacks . 83
11.3. Availability of good random numbers . . . . . . . . . . 82 11.3. Availability of good random numbers . . . . . . . . . . 83
11.4. Freshness in Voucher-Requests . . . . . . . . . . . . . 82 11.4. Freshness in Voucher-Requests . . . . . . . . . . . . . 83
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 . . . 87
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 11.7. YANG Module Security Considerations . . . . . . . . . . 90
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90
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 . . . . . . . . . . . . . . . . . 94
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 . . . . . . . . . . . . . . . . . . . . . . 98
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 97 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 98
Appendix C. Example Vouchers . . . . . . . . . . . . . . . . . . 98 Appendix C. Example Vouchers . . . . . . . . . . . . . . . . . . 99
C.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 98 C.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 99
C.1.1. MASA key pair for voucher signatures . . . . . . . . 98 C.1.1. MASA key pair for voucher signatures . . . . . . . . 99
C.1.2. Manufacturer key pair for IDevID signatures . . . . . 99 C.1.2. Manufacturer key pair for IDevID signatures . . . . . 100
C.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 99 C.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 100
C.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 101 C.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 102
C.2. Example process . . . . . . . . . . . . . . . . . . . . . 103 C.2. Example process . . . . . . . . . . . . . . . . . . . . . 104
C.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 104 C.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 105
C.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 107 C.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 108
C.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 112 C.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 113
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 116 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 7, line 8 skipping to change at page 7, line 7
manner. Existing automated mechanisms are known as non-secured manner. Existing automated mechanisms are known as non-secured
'Trust on First Use' (TOFU) [RFC7435], 'resurrecting duckling' 'Trust on First Use' (TOFU) [RFC7435], 'resurrecting duckling'
[Stajano99theresurrecting] or 'pre-staging'. [Stajano99theresurrecting] or 'pre-staging'.
Another prior approach has been to try and minimize user actions Another prior approach has been to try and minimize user actions
during bootstrapping, but not eliminate all user-actions. The during bootstrapping, but not eliminate all user-actions. The
original EST protocol [RFC7030] does reduce user actions during original EST protocol [RFC7030] does reduce user actions during
bootstrap but does not provide solutions for how the following bootstrap but does not provide solutions for how the following
protocol steps can be made autonomic (not involving user actions): protocol steps can be made autonomic (not involving user actions):
o using the Implicit Trust Anchor [RFC7030] database to authenticate * using the Implicit Trust Anchor [RFC7030] database to authenticate
an owner specific service (not an autonomic solution because the an owner specific service (not an autonomic solution because the
URL must be securely distributed), URL must be securely distributed),
o engaging a human user to authorize the CA certificate using out- * engaging a human user to authorize the CA certificate using out-
of-band data (not an autonomic solution because the human user is of-band data (not an autonomic solution because the human user is
involved), involved),
o using a configured Explicit TA database (not an autonomic solution * using a configured Explicit TA database (not an autonomic solution
because the distribution of an explicit TA database is not because the distribution of an explicit TA database is not
autonomic), autonomic),
o and using a Certificate-Less TLS mutual authentication method (not * and using a Certificate-Less TLS mutual authentication method (not
an autonomic solution because the distribution of symmetric key an autonomic solution because the distribution of symmetric key
material is not autonomic). material is not autonomic).
These "touch" methods do not meet the requirements for zero-touch. These "touch" methods do not meet the requirements for zero-touch.
There are "call home" technologies where the pledge first establishes There are "call home" technologies where the pledge first establishes
a connection to a well known manufacturer service using a common a connection to a well known manufacturer service using a common
client-server authentication model. After mutual authentication, client-server authentication model. After mutual authentication,
appropriate credentials to authenticate the target domain are appropriate credentials to authenticate the target domain are
transferred to the pledge. This creates several problems and transferred to the pledge. This creates several problems and
limitations: limitations:
o the pledge requires realtime connectivity to the manufacturer * the pledge requires realtime connectivity to the manufacturer
service, service,
o the domain identity is exposed to the manufacturer service (this * the domain identity is exposed to the manufacturer service (this
is a privacy concern), is a privacy concern),
o the manufacturer is responsible for making the authorization * the manufacturer is responsible for making the authorization
decisions (this is a liability concern), decisions (this is a liability concern),
BRSKI addresses these issues by defining extensions to the EST BRSKI addresses these issues by defining extensions to the EST
protocol for the automated distribution of vouchers. protocol for the automated distribution of vouchers.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
skipping to change at page 12, line 42 skipping to change at page 12, line 42
default settings. default settings.
1.4. Leveraging the new key infrastructure / next steps 1.4. Leveraging the new key infrastructure / next steps
As a result of the protocol described herein, the bootstrapped As a result of the protocol described herein, the bootstrapped
devices have the Domain CA trust anchor in common. An end entity devices have the Domain CA trust anchor in common. An end entity
certificate has optionally been issued from the Domain CA. This certificate has optionally been issued from the Domain CA. This
makes it possible to securely deploy functionalities across the makes it possible to securely deploy functionalities across the
domain, e.g: domain, e.g:
o Device management. * Device management.
o Routing authentication. * Routing authentication.
o Service discovery. * Service discovery.
The major intended benefit is that it possible to use the credentials The major intended benefit is that it possible to use the credentials
deployed by this protocol to secure the Autonomic Control Plane (ACP) deployed by this protocol to secure the Autonomic Control Plane (ACP)
([I-D.ietf-anima-autonomic-control-plane]). ([I-D.ietf-anima-autonomic-control-plane]).
1.5. Requirements for Autonomic Network Infrastructure (ANI) devices 1.5. Requirements for Autonomic Network Infrastructure (ANI) devices
The BRSKI protocol can be used in a number of environments. Some of 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 the options in this document are the result of requirements that are
out of the ANI scope. This section defines the base requirements for out of the ANI scope. This section defines the base requirements for
skipping to change at page 15, line 46 skipping to change at page 15, line 46
| | (5) Enroll |<---+ (non-error HTTP codes ) | | (5) Enroll |<---+ (non-error HTTP codes )
^------------+ |\___/ (e.g. 202 'Retry-After') ^------------+ |\___/ (e.g. 202 'Retry-After')
| Enroll +------+-------+ | Enroll +------+-------+
| Failure | | Failure |
| -----v------ | -----v------
| / Enrolled \ | / Enrolled \
^------------+ | ^------------+ |
Factory \------------/ Factory \------------/
reset reset
Figure 2: Pledge State Diagram Figure 2: Pledge State Diagram
State descriptions for the pledge are as follows: State descriptions for the pledge are as follows:
1. Discover a communication channel to a registrar. 1. Discover a communication channel to a registrar.
2. Identify itself. This is done by presenting an X.509 IDevID 2. Identify itself. This is done by presenting an X.509 IDevID
credential to the discovered registrar (via the proxy) in a TLS credential to the discovered registrar (via the proxy) in a TLS
handshake. (The registrar credentials are only provisionally handshake. (The registrar credentials are only provisionally
accepted at this time). accepted at this time).
skipping to change at page 19, line 47 skipping to change at page 19, line 46
MASACertExtensions EXTENSION ::= { ext-MASAURL, ... } MASACertExtensions EXTENSION ::= { ext-MASAURL, ... }
ext-MASAURL EXTENSION ::= { SYNTAX MASAURLSyntax ext-MASAURL EXTENSION ::= { SYNTAX MASAURLSyntax
IDENTIFIED BY id-pe-masa-url } IDENTIFIED BY id-pe-masa-url }
id-pe-masa-url OBJECT IDENTIFIER ::= { id-pe TBD } id-pe-masa-url OBJECT IDENTIFIER ::= { id-pe TBD }
MASAURLSyntax ::= IA5String MASAURLSyntax ::= IA5String
END END
<CODE ENDS> <CODE ENDS>
Figure 3: MASAURL ASN.1 Module Figure 3: MASAURL ASN.1 Module
The choice of id-pe is based on guidance found in Section 4.2.2 of 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 [RFC5280], "These extensions may be used to direct applications to
on-line information about the issuer or the subject". The MASA URL on-line information about the issuer or the subject". The MASA URL
is precisely that: online information about the particular subject. is precisely that: online information about the particular subject.
2.4. Protocol Flow 2.4. Protocol Flow
A representative flow is shown in Figure 4 A representative flow is shown in Figure 4
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
skipping to change at page 21, line 50 skipping to change at page 21, line 50
|-------voucher status telemetry--------->| | |-------voucher status telemetry--------->| |
| |<-device audit log--| | |<-device audit log--|
| [verify audit log and voucher] | | [verify audit log and voucher] |
|<--------------------------------------->| | |<--------------------------------------->| |
[enroll] | | [enroll] | |
| Continue with RFC7030 enrollment | | | Continue with RFC7030 enrollment | |
| using now bidirectionally authenticated | | | using now bidirectionally authenticated | |
| TLS session. | | | TLS session. | |
[enrolled] | | [enrolled] | |
Figure 4: Protocol Time Sequence Diagram Figure 4: Protocol Time Sequence Diagram
On initial bootstrap, a new device (the pledge) uses a local service On initial bootstrap, a new device (the pledge) uses a local service
autodiscovery (GRASP or mDNS) to locate a join proxy. The join proxy autodiscovery (GRASP or mDNS) to locate a join proxy. The join proxy
connects the pledge to a local registrar (the JRC). connects the pledge to a local registrar (the JRC).
Having found a candidate registrar, the fledgling pledge sends some Having found a candidate registrar, the fledgling pledge sends some
information about itself to the registrar, including its serial information about itself to the registrar, including its serial
number in the form of a voucher request and its device identity number in the form of a voucher request and its device identity
certificate (IDevID) as part of the TLS session. certificate (IDevID) as part of the TLS session.
skipping to change at page 24, line 39 skipping to change at page 24, line 39
until bootstrapping is complete. Therefore bootstrapping is defined until bootstrapping is complete. Therefore bootstrapping is defined
with a framework that does not require knowledge of the current time. 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 A pledge MAY ignore all time stamps in the voucher and in the
certificate validity periods if it does not know the current time. certificate validity periods if it does not know the current time.
The pledge is exposed to dates in the following five places: The pledge is exposed to dates in the following five places:
registrar certificate notBefore, registrar certificate notAfter, registrar certificate notBefore, registrar certificate notAfter,
voucher created-on, and voucher expires-on. Additionally, CMS voucher created-on, and voucher expires-on. Additionally, CMS
signatures contain a signingTime. signatures contain a signingTime.
A pledge with a real time clock in which it has confidence in, MUST A pledge with a real time clock in which it has confidence, MUST
check the above time fields in all certificates and signatures that check the above time fields in all certificates and signatures that
it processes. it processes.
If the voucher contains a nonce then the pledge MUST confirm the If the voucher contains a nonce then the pledge MUST confirm the
nonce matches the original pledge voucher-request. This ensures the nonce matches the original pledge voucher-request. This ensures the
voucher is fresh. See Section 5.2. voucher is fresh. See Section 5.2.
2.6.2. Infinite Lifetime of IDevID 2.6.2. Infinite Lifetime of IDevID
[RFC5280] explains that long lived pledge certificates "SHOULD be [RFC5280] explains that long lived pledge certificates "SHOULD be
skipping to change at page 27, line 48 skipping to change at page 27, line 48
+---- prior-signed-voucher-request? binary +---- prior-signed-voucher-request? binary
+---- 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] section 4). The contents of the certificate have been
save space. For detailed examples, see Appendix C.2. These examples elided to save space. For detailed examples, see Appendix C.2.
conform to the encoding rules defined in [RFC7951]. These examples 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": {
"assertion": "proximity", "assertion": "proximity",
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"serial-number" : "JADA123456789", "serial-number" : "JADA123456789",
"created-on": "2017-01-01T00:00:00.000Z", "created-on": "2017-01-01T00:00:00.000Z",
"proximity-registrar-cert": "base64encodedvalue==" "proximity-registrar-cert": "base64encodedvalue=="
} }
} }
Figure 6: JSON representation of example Voucher-Request Figure 6: JSON representation of example Voucher-Request
Example (2) The following example illustrates a registrar voucher- Example (2) The following example illustrates a registrar voucher-
request. The 'prior-signed-voucher-request' leaf is request. The 'prior-signed-voucher-request' leaf is
populated with the pledge's voucher-request (such as the populated with the pledge's voucher-request (such as the
prior example). The pledge's voucher-request is a prior example). The pledge's voucher-request is a
binary CMS signed object. In the JSON encoding used binary CMS signed object. In the JSON encoding used
here it must be base64 encoded. The nonce and assertion here it must be base64 encoded. The nonce and assertion
have been carried forward from the pledge request to the have been carried forward from the pledge request to the
registrar request. The serial-number is extracted from registrar request. The serial-number is extracted from
the pledge's Client Certificate from the TLS connection. the pledge's Client Certificate from the TLS connection.
skipping to change at page 29, line 17 skipping to change at page 29, line 17
during deployment. See Section 5.5. during deployment. See Section 5.5.
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
"created-on": "2017-01-01T00:00:02.000Z", "created-on": "2017-01-01T00:00:02.000Z",
"idevid-issuer": "base64encodedvalue==", "idevid-issuer": "base64encodedvalue==",
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
} }
} }
Figure 8: JSON representation of Offline Voucher-Request Figure 8: JSON representation of Offline Voucher-Request
3.4. YANG Module 3.4. YANG Module
Following is a YANG [RFC7950] module formally extending the [RFC8366] Following is a YANG [RFC7950] module formally extending the [RFC8366]
voucher into a voucher-request. voucher into a voucher-request.
<CODE BEGINS> file "ietf-voucher-request@2018-02-14.yang" <CODE BEGINS> file "ietf-voucher-request@2018-02-14.yang"
module ietf-voucher-request { module ietf-voucher-request {
yang-version 1.1; yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-voucher-request";
prefix "vcr";
import ietf-restconf { namespace
prefix rc; "urn:ietf:params:xml:ns:yang:ietf-voucher-request";
description "This import statement is only present to access prefix "vcr";
the yang-data extension defined in RFC 8040.";
reference "RFC 8040: RESTCONF Protocol";
}
import ietf-voucher { import ietf-restconf {
prefix vch; prefix rc;
description "This module defines the format for a voucher, description "This import statement is only present to access
which is produced by a pledge's manufacturer or the yang-data extension defined in RFC 8040.";
delegate (MASA) to securely assign a pledge to reference "RFC 8040: RESTCONF Protocol";
an 'owner', so that the pledge may establish a secure }
connection to the owner's network infrastructure";
reference "RFC 8366: Voucher Profile for Bootstrapping Protocols"; 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";
organization reference "RFC 8366: Voucher Profile for Bootstrapping Protocols";
"IETF ANIMA Working Group"; }
contact organization
"WG Web: <https://datatracker.ietf.org/wg/anima/> "IETF ANIMA Working Group";
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 contact
"This module defines the format for a voucher request. "WG Web: <https://datatracker.ietf.org/wg/anima/>
It is a superset of the voucher itself. WG List: <mailto:anima@ietf.org>
It provides content to the MASA for consideration Author: Kent Watsen
during a voucher request. <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>";
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', description
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', "This module defines the format for a voucher request.
'MAY', and 'OPTIONAL' in this document are to be interpreted as It is a superset of the voucher itself.
described in BCP 14 RFC2119 RFC8174 when, and only when, they It provides content to the MASA for consideration
appear in all capitals, as shown here. during a voucher request.
Copyright (c) 2019 IETF Trust and the persons identified as The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
authors of the code. All rights reserved. '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.
Redistribution and use in source and binary forms, with or without Copyright (c) 2019 IETF Trust and the persons identified as
modification, is permitted pursuant to, and subject to the license authors of the code. All rights reserved.
terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the RFC Redistribution and use in source and binary forms, with or without
itself for full legal notices."; 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
(http://trustee.ietf.org/license-info).
revision "2018-02-14" { This version of this YANG module is part of RFC XXXX; see the RFC
description itself for full legal notices.";
"Initial version";
reference
"RFC XXXX: Voucher Profile for Bootstrapping Protocols";
}
// Top-level statement revision "2018-02-14" {
rc:yang-data voucher-request-artifact { description
uses voucher-request-grouping; "Initial version";
reference
"RFC XXXX: Voucher Profile for Bootstrapping Protocols";
}
} // 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 { // Grouping defined for future usage
refine "voucher/created-on" { grouping voucher-request-grouping {
mandatory false; description
} "Grouping to allow reuse/extensions in future work.";
refine "voucher/pinned-domain-cert" { uses vch:voucher-artifact-grouping {
mandatory false; refine "voucher/created-on" {
} mandatory false;
}
refine "voucher/domain-cert-revocation-checks" { refine "voucher/pinned-domain-cert" {
description "The domain-cert-revocation-checks field mandatory false;
is not valid in a voucher request, and }
any occurence MUST be ignored";
}
refine "voucher/assertion" { refine "voucher/domain-cert-revocation-checks" {
mandatory false; description "The domain-cert-revocation-checks field
description "Any assertion included in registrar voucher is not valid in a voucher request, and
requests SHOULD be ignored by the MASA."; any occurence MUST be ignored";
} }
augment "voucher" { refine "voucher/assertion" {
description mandatory false;
"Adds leaf nodes appropriate for requesting vouchers."; description "Any assertion included in registrar voucher
requests SHOULD be ignored by the MASA.";
}
leaf prior-signed-voucher-request { augment "voucher" {
type binary; description
description "Adds leaf nodes appropriate for requesting vouchers.";
"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 leaf prior-signed-voucher-request {
with a proximity-registrar-cert, and the registrar type binary;
then includes it as the prior-signed-voucher-request field. description
This is a simple mechanism for a chain of trusted "If it is necessary to change a voucher, or re-sign and
parties to change a voucher request, while forward a voucher that was previously provided along a
maintaining the prior signature information. protocol path, then the previously signed voucher SHOULD be
included in this field.
The Registrar and MASA MAY examine the prior signed For example, a pledge might sign a voucher request
voucher information for the with a proximity-registrar-cert, and the registrar
purposes of policy decisions. For example this information then includes it as the prior-signed-voucher-request field.
could be useful to a MASA to determine that both pledge and This is a simple mechanism for a chain of trusted
registrar agree on proximity assertions. The MASA SHOULD parties to change a voucher request, while
remove all prior-signed-voucher-request information when maintaining the prior signature information.
signing a voucher for imprinting so as to minimize the
final voucher size.";
}
leaf proximity-registrar-cert { The Registrar and MASA MAY examine the prior signed
type binary; voucher information for the
description purposes of policy decisions. For example this information
"An X.509 v3 certificate structure as specified by RFC 5280, could be useful to a MASA to determine that both pledge and
Section 4 encoded using the ASN.1 distinguished encoding registrar agree on proximity assertions. The MASA SHOULD
rules (DER), as specified in ITU-T X.690. remove all prior-signed-voucher-request information when
signing a voucher for imprinting so as to minimize the
final voucher size.";
}
The first certificate in the Registrar TLS server leaf proximity-registrar-cert {
certificate_list sequence (the end-entity TLS certificate, type binary;
see [RFC8446]) presented by the Registrar to the Pledge. description
This MUST be populated in a Pledge's voucher request when a "An X.509 v3 certificate structure as specified by RFC 5280,
proximity assertion is requested."; Section 4 encoded using the ASN.1 distinguished encoding
} rules (DER), as specified in ITU-T X.690.
}
}
}
} The first certificate in the Registrar TLS server
certificate_list sequence (the end-entity TLS certificate,
see [RFC8446]) presented by the Registrar to the Pledge.
This MUST be populated in a Pledge's voucher request when a
proximity assertion is requested.";
}
}
}
}
<CODE ENDS> }
<CODE ENDS>
Figure 9: YANG module for Voucher-Request Figure 9: YANG module for Voucher-Request
4. Proxying details (Pledge - Proxy - Registrar) 4. Proxying details (Pledge - Proxy - Registrar)
This section is normative for uses with an ANIMA ACP. The use of 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 GRASP mechanism is part of the ACP. Other users of BRSKI will need
to define an equivalent proxy mechanism, and an equivalent mechanism to define an equivalent proxy mechanism, and an equivalent mechanism
to configure the proxy. to configure the proxy.
The role of the proxy is to facilitate communications. The proxy The role of the proxy is to facilitate communications. The proxy
forwards packets between the pledge and a registrar that has been forwards packets between the pledge and a registrar that has been
provisioned to the proxy via full GRASP ACP discovery. provisioned to the proxy via full GRASP ACP discovery.
This section defines a stateful proxy mechanism which is referred to This section defines a stateful proxy mechanism which is referred to
as a "circuit" proxy. This is a form of Application Level Gateway as a "circuit" proxy. This is a form of Application Level Gateway
skipping to change at page 35, line 24 skipping to change at page 35, line 20
4.1.1. Proxy GRASP announcements 4.1.1. Proxy GRASP announcements
A proxy uses the DULL GRASP M_FLOOD mechanism to announce itself. A proxy uses the DULL GRASP M_FLOOD mechanism to announce itself.
This announcement can be within the same message as the ACP This announcement can be within the same message as the ACP
announcement detailed in [I-D.ietf-anima-autonomic-control-plane]. announcement detailed in [I-D.ietf-anima-autonomic-control-plane].
The formal Concise Data Definition Language (CDDL) [RFC8610] The formal Concise Data Definition Language (CDDL) [RFC8610]
definition is: definition is:
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
objective = ["AN_Proxy", objective-flags, loop-count, objective = ["AN_Proxy", objective-flags, loop-count,
objective-value] objective-value]
ttl = 180000 ; 180,000 ms (3 minutes) ttl = 180000 ; 180,000 ms (3 minutes)
initiator = ACP address to contact Registrar initiator = ACP address to contact Registrar
objective-flags = sync-only ; as in GRASP spec objective-flags = sync-only ; as in GRASP spec
sync-only = 4 ; M_FLOOD only requires synchronization sync-only = 4 ; M_FLOOD only requires synchronization
loop-count = 1 ; one hop only loop-count = 1 ; one hop only
objective-value = any ; none objective-value = any ; none
locator-option = [ O_IPv6_LOCATOR, ipv6-address, locator-option = [ O_IPv6_LOCATOR, ipv6-address,
transport-proto, port-number ] transport-proto, port-number ]
ipv6-address = the v6 LL of the Proxy ipv6-address = the v6 LL of the Proxy
$transport-proto /= IPPROTO_TCP ; note this can be any value from the $transport-proto /= IPPROTO_TCP ; note this can be any value from the
; IANA protocol registry, as per ; IANA protocol registry, as per
; [GRASP] section 2.9.5.1, note 3. ; [GRASP] section 2.9.5.1, note 3.
port-number = selected by Proxy port-number = selected by Proxy
Figure 10: CDDL definition of Proxy Discovery message Figure 10: CDDL definition of Proxy Discovery message
Here is an example M_FLOOD announcing a proxy at fe80::1, on TCP port Here is an example M_FLOOD announcing a proxy at fe80::1, on TCP port
4443. 4443.
[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000, [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
["AN_Proxy", 4, 1, ""], ["AN_Proxy", 4, 1, ""],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]] h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]]
Figure 11: Example of Proxy Discovery message Figure 11: Example of Proxy Discovery message
On a small network the Registrar MAY include the GRASP M_FLOOD On a small network the Registrar MAY include the GRASP M_FLOOD
announcements to locally connected networks. announcements to locally connected networks.
The $transport-proto above indicates the method that the pledge- The $transport-proto above indicates the method that the pledge-
proxy-registrar will use. The TCP method described here is proxy-registrar will use. The TCP method described here is
mandatory, and other proxy methods, such as CoAP methods not defined mandatory, and other proxy methods, such as CoAP methods not defined
in this document are optional. Other methods MUST NOT be enabled in this document are optional. Other methods MUST NOT be enabled
skipping to change at page 36, line 40 skipping to change at page 36, line 33
The registrar SHOULD announce itself so that proxies can find it and The registrar SHOULD announce itself so that proxies can find it and
determine what kind of connections can be terminated. determine what kind of connections can be terminated.
The registrar announces itself using ACP instance of GRASP using The registrar announces itself using ACP instance of GRASP using
M_FLOOD messages. A registrar may announce any convenient port M_FLOOD messages. A registrar may announce any convenient port
number, including using a stock port 443. ANI proxies MUST support number, including using a stock port 443. ANI proxies MUST support
GRASP discovery of registrars. GRASP discovery of registrars.
The M_FLOOD is formatted as follows: The M_FLOOD is formatted as follows:
[M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000, [M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000,
["AN_join_registrar", 4, 255, "EST-TLS"], ["AN_join_registrar", 4, 255, "EST-TLS"],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443]] h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443]]
Figure 12: An example of a Registrar announcement message Figure 12: An example of a Registrar announcement message
The formal CDDL definition is: The formal CDDL definition is:
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
objective = ["AN_join_registrar", objective-flags, loop-count, objective = ["AN_join_registrar", objective-flags, loop-count,
objective-value] objective-value]
skipping to change at page 38, line 48 skipping to change at page 38, line 48
If non-persistent connections are used, then both the pledge and the If non-persistent connections are used, then both the pledge and the
registrar MUST remember the certificates seen, and also sent for the registrar MUST remember the certificates seen, and also sent for the
first connection. They MUST check each subsequent connections for first connection. They MUST check each subsequent connections for
the same certificates, and each end MUST use the same certificates as the same certificates, and each end MUST use the same certificates as
well. This places a difficult restriction on rolling certificates on well. This places a difficult restriction on rolling certificates on
the Registrar. the Registrar.
Summarized automation extensions for the BRSKI-EST flow are: Summarized automation extensions for the BRSKI-EST flow are:
o The pledge either attempts concurrent connections via each * The pledge either attempts concurrent connections via each
discovered proxy, or it times out quickly and tries connections in discovered proxy, or it times out quickly and tries connections in
series, as explained at the end of Section 5.1. series, as explained at the end of Section 5.1.
o The pledge provisionally accepts the registrar certificate during * The pledge provisionally accepts the registrar certificate during
the TLS handshake as detailed in Section 5.1. the TLS handshake as detailed in Section 5.1.
o The pledge requests a voucher using the new REST calls described * The pledge requests a voucher using the new REST calls described
below. This voucher is then validated. below. This voucher is then validated.
o The pledge completes authentication of the server certificate as * The pledge completes authentication of the server certificate as
detailed in Section 5.6.1. This moves the BRSKI-EST TLS detailed in Section 5.6.1. This moves the BRSKI-EST TLS
connection out of the provisional state. connection out of the provisional state.
o Mandatory bootstrap steps conclude with voucher status telemetry * Mandatory bootstrap steps conclude with voucher status telemetry
(see Section 5.7). (see Section 5.7).
The BRSKI-EST TLS connection can now be used for EST enrollment. The BRSKI-EST TLS connection can now be used for EST enrollment.
The extensions for a registrar (equivalent to EST server) are: The extensions for a registrar (equivalent to EST server) are:
o Client authentication is automated using Initial Device Identity * Client authentication is automated using Initial Device Identity
(IDevID) as per the EST certificate based client authentication. (IDevID) as per the EST certificate based client authentication.
The subject field's DN encoding MUST include the "serialNumber" The subject field's DN encoding MUST include the "serialNumber"
attribute with the device's unique serial number as explained in attribute with the device's unique serial number as explained in
Section 2.3.1 Section 2.3.1
o The registrar requests and validates the voucher from the MASA. * The registrar requests and validates the voucher from the MASA.
o The registrar forwards the voucher to the pledge when requested. * The registrar forwards the voucher to the pledge when requested.
o The registrar performs log verifications (described in * The registrar performs log verifications (described in
Section 5.8.3) in addition to local authorization checks before Section 5.8.3) in addition to local authorization checks before
accepting optional pledge device enrollment requests. accepting optional pledge device enrollment requests.
5.1. BRSKI-EST TLS establishment details 5.1. BRSKI-EST TLS establishment details
The pledge establishes the TLS connection with the registrar through The pledge establishes the TLS connection with the registrar through
the circuit proxy (see Section 4) but the TLS handshake is with the 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. The BRSKI-EST pledge is the TLS client and the BRSKI-EST
registrar is the TLS server. All security associations established registrar is the TLS server. All security associations established
are between the pledge and the registrar regardless of proxy are between the pledge and the registrar regardless of proxy
skipping to change at page 41, line 37 skipping to change at page 41, line 37
created-on: Pledges that have a realtime clock are RECOMMENDED to created-on: Pledges that have a realtime clock are RECOMMENDED to
populate this field with the current date and time in yang:date- populate this field with the current date and time in yang:date-
and-time format. This provides additional information to the and-time format. This provides additional information to the
MASA. Pledges that have no real-time clocks MAY omit this field. MASA. Pledges that have no real-time clocks MAY omit this field.
nonce: The pledge voucher-request MUST contain a cryptographically nonce: The pledge voucher-request MUST contain a cryptographically
strong random or pseudo-random number nonce (see [RFC4086] section strong random or pseudo-random number nonce (see [RFC4086] section
6.2). As the nonce is usually generated very early in the boot 6.2). As the nonce is usually generated very early in the boot
sequence there is a concern that the same nonce might generated sequence there is a concern that the same nonce might generated
across multiple boots, or after a factory reset. Difference across multiple boots, or after a factory reset. Different nonces
nonces MUST NOT generated for each bootstrapping attempt, whether MUST be generated for each bootstrapping attempt, whether in
in series or concurrently. The freshness of this nonce mitigates series or concurrently. The freshness of this nonce mitigates
against the lack of real-time clock as explained in Section 2.6.1. against the lack of real-time clock as explained in Section 2.6.1.
assertion: The pledge indicates support for the mechanism described assertion: The pledge indicates support for the mechanism described
in this document, by putting the value "proximity" in the voucher- in this document, by putting the value "proximity" in the voucher-
request, and MUST include the "proximity-registrar-cert" field request, and MUST include the "proximity-registrar-cert" field
(below). (below).
proximity-registrar-cert: In a pledge voucher-request this is the proximity-registrar-cert: In a pledge voucher-request this is the
first certificate in the TLS server 'certificate_list' sequence first certificate in the TLS server 'certificate_list' sequence
(see [RFC5246]) presented by the registrar to the pledge. That (see [RFC5246]) presented by the registrar to the pledge. That
skipping to change at page 42, line 30 skipping to change at page 42, line 30
5.3. Registrar Authorization of Pledge 5.3. Registrar Authorization of Pledge
In a fully automated network all devices must be securely identified In a fully automated network all devices must be securely identified
and authorized to join the domain. and authorized to join the domain.
A Registrar accepts or declines a request to join the domain, based A Registrar accepts or declines a request to join the domain, based
on the authenticated identity presented. For different networks, on the authenticated identity presented. For different networks,
examples of automated acceptance may include: examples of automated acceptance may include:
o allow any device of a specific type (as determined by the X.509 * allow any device of a specific type (as determined by the X.509
IDevID), IDevID),
o allow any device from a specific vendor (as determined by the * allow any device from a specific vendor (as determined by the
X.509 IDevID), X.509 IDevID),
o allow a specific device from a vendor (as determined by the X.509 * allow a specific device from a vendor (as determined by the X.509
IDevID) against a domain white list. (The mechanism for checking IDevID) against a domain white list. (The mechanism for checking
a shared white list potentially used by multiple Registrars is out a shared white list potentially used by multiple Registrars is out
of scope). of scope).
If validation fails the registrar SHOULD respond with the HTTP 404 If validation fails the registrar SHOULD respond with the HTTP 404
error code. If the voucher-request is in an unknown format, then an 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 HTTP 406 error code is more appropriate. A situation that could be
resolved with administrative action (such as adding a vendor to a resolved with administrative action (such as adding a vendor to a
whitelist) MAY be responded with an 403 HTTP error code. whitelist) MAY be responded with an 403 HTTP error code.
skipping to change at page 54, line 19 skipping to change at page 54, line 19
"reason-context": { "additional" : "JSON" } "reason-context": { "additional" : "JSON" }
} }
Figure 15: Example Status Telemetry Figure 15: Example Status Telemetry
The server SHOULD respond with an HTTP 200 but MAY simply fail with The server SHOULD respond with an HTTP 200 but MAY simply fail with
an HTTP 404 error. The client ignores any response. Within the an HTTP 404 error. The client ignores any response. Within the
server logs the server SHOULD capture this telemetry information. server logs the server SHOULD capture this telemetry information.
Additional standard JSON fields in this POST MAY be added, see Additional standard JSON fields in this POST MAY be added, see
Section 8.4. A server that sees unknown fields should log them, but Section 8.5. A server that sees unknown fields should log them, but
otherwise ignore them. otherwise ignore them.
5.8. Registrar audit-log request 5.8. Registrar audit-log request
After receiving the pledge status telemetry Section 5.7, the After receiving the pledge status telemetry Section 5.7, the
registrar SHOULD request the MASA audit-log from the MASA service. registrar SHOULD request the MASA audit-log from the MASA service.
This is done with an HTTP POST using the operation path value of This is done with an HTTP POST using the operation path value of
"/.well-known/est/requestauditlog". "/.well-known/est/requestauditlog".
skipping to change at page 56, line 23 skipping to change at page 56, line 23
} }
event = { event = {
"date": text, "date": text,
"domainID": text, "domainID": text,
"nonce": text / null, "nonce": text / null,
"assertion": "verified" / "logged" / "proximity", "assertion": "verified" / "logged" / "proximity",
? "truncated": uint, ? "truncated": uint,
} }
Figure 16: CDDL for audit-log response Figure 16: CDDL for audit-log response
An example: An example:
{ {
"version":"1", "version":"1",
"events":[ "events":[
{ {
"date":"2019-05-15T17:25:55.644-04:00", "date":"2019-05-15T17:25:55.644-04:00",
"domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=", "domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=",
"nonce":"VOUFT-WwrEv0NuAQEHoV7Q", "nonce":"VOUFT-WwrEv0NuAQEHoV7Q",
skipping to change at page 56, line 51 skipping to change at page 56, line 51
"assertion":"proximity" "assertion":"proximity"
} }
], ],
"truncation": { "truncation": {
"nonced duplicates": "0", "nonced duplicates": "0",
"nonceless duplicates": "1", "nonceless duplicates": "1",
"arbitrary": "2" "arbitrary": "2"
} }
} }
Figure 17: Example of audit-log response Figure 17: Example of audit-log response
The domainID is a binary SubjectKeyIdentifier value calculated The domainID is a binary SubjectKeyIdentifier value calculated
according to Section 5.8.2. It is encoded once in base64 in order to according to Section 5.8.2. It is encoded once in base64 in order to
be transported in this JSON container. be transported in this JSON container.
The date is in [RFC3339] format, which is consistent with typical The date is in [RFC3339] format, which is consistent with typical
JavaScript usage of JSON. JavaScript usage of JSON.
The truncation structure MAY be omitted if all values are zero. Any The truncation structure MAY be omitted if all values are zero. Any
counter missing from the truncation structure is the be assumed to be counter missing from the truncation structure is the be assumed to be
skipping to change at page 62, line 7 skipping to change at page 62, line 7
In order to communicate this indicator, the client HTTP POSTs a JSON In order to communicate this indicator, the client HTTP POSTs a JSON
dictionary with a number of attributes described below to the new EST dictionary with a number of attributes described below to the new EST
endpoint at "/.well-known/est/enrollstatus". endpoint at "/.well-known/est/enrollstatus".
When indicating a successful enrollment the client SHOULD first re- When indicating a successful enrollment the client SHOULD first re-
establish the EST TLS session using the newly obtained credentials. establish the EST TLS session using the newly obtained credentials.
TLS 1.2 supports doing this in-band, but TLS 1.3 does not. The TLS 1.2 supports doing this in-band, but TLS 1.3 does not. The
client SHOULD therefore always close the existing TLS connection, and client SHOULD therefore always close the existing TLS connection, and
start a new one. start a new one.
In the case of a FAIL, the same TLS connection MUST be used. The In the case of a failed enrollment, the client MUST send the
Reason string indicates why the most recent enrollment failed. 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 reason-context attribute is an arbitrary JSON object (literal The reason-context attribute is an arbitrary JSON object (literal
value or hash of values) which provides additional information value or hash of values) which provides additional information
specific to the failure to unroll from this pledge. The contents of specific to the failure to unroll from this pledge. The contents of
this field are not subject to standardization. This is represented this field are not subject to standardization. This is represented
by the group-socket "$$arbitrary-map" in the CDDL. by the group-socket "$$arbitrary-map" in the CDDL.
In the case of a SUCCESS the Reason string is omitted. In the case of a SUCCESS the Reason string is omitted.
enrollstatus-post = { enrollstatus-post = {
"version": uint, "version": uint,
"status": bool, "status": bool,
"reason": text, "reason": text,
? "reason-context" : { $$arbitrary-map } ? "reason-context" : { $$arbitrary-map }
} }
} }
Figure 18: CDDL for enrollment status POST Figure 18: CDDL for enrollment status POST
An example status report can be seen below. It is sent with with the An example status report can be seen below. It is sent with with the
media type: application/json media type: application/json
{ {
"version":"1", "version":"1",
"status":true, "status":true,
"reason":"Informative human readable message", "reason":"Informative human readable message",
"reason-context": { "additional" : "JSON" } "reason-context": { "additional" : "JSON" }
} }
Figure 19: Example of enrollment status POST Figure 19: Example of enrollment status POST
The server SHOULD respond with an HTTP 200 but MAY simply fail with The server SHOULD respond with an HTTP 200 but MAY simply fail with
an HTTP 404 error. an HTTP 404 error.
Within the server logs the server MUST capture if this message was Within the server logs the server MUST capture if this message was
received over an TLS session with a matching client certificate. received over an TLS session with a matching client certificate.
5.9.5. Multiple certificates 5.9.5. Multiple certificates
Pledges that require multiple certificates could establish direct EST Pledges that require multiple certificates could establish direct EST
skipping to change at page 69, line 28 skipping to change at page 69, line 28
also a lot of responsibility: if access to the private part of the also a lot of responsibility: if access to the private part of the
new anchors are lost the manufacturer may be unable to help. new anchors are lost the manufacturer may be unable to help.
8. IANA Considerations 8. IANA Considerations
This document requires the following IANA actions: This document requires the following IANA actions:
8.1. The IETF XML Registry 8.1. The IETF XML Registry
This document registers a URI in the "IETF XML Registry" [RFC3688]. This document registers a URI in the "IETF XML Registry" [RFC3688].
IANA has registered the following: IANA is asked to register the following:
URI: urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa URI: urn:ietf:params:xml:ns:yang:ietf-voucher-request
Registrant Contact: The ANIMA WG of the IETF. Registrant Contact: The ANIMA WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
8.2. Well-known EST registration 8.2. The IETF XML Registry
This document registers a YANG module in the "YANG Module Names"
registry [RFC6020]. IANA is asked to register the following:
name: ietf-voucher-request
namespace: urn:ietf:params:xml:ns:yang:ietf-voucher-request
prefix: vch
reference: THIS DOCUMENT
8.3. Well-known EST registration
This document extends the definitions of "est" (so far defined via This document extends the definitions of "est" (so far defined via
RFC7030) in the "https://www.iana.org/assignments/well-known-uris/ RFC7030) in the "https://www.iana.org/assignments/well-known-uris/
well-known-uris.xhtml" registry. IANA is asked to change the well-known-uris.xhtml" registry. IANA is asked to change the
registration of "est" to include RFC7030 and this document. registration of "est" to include RFC7030 and this document.
8.3. PKIX Registry 8.4. PKIX Registry
IANA is requested to register the following: IANA is requested to register the following:
This document requests a number for id-mod-MASAURLExtn2016(TBD) from This document requests a number for id-mod-MASAURLExtn2016(TBD) from
the pkix(7) id-mod(0) Registry. the pkix(7) id-mod(0) Registry.
This document has received an early allocation from the id-pe This document has received an early allocation from the id-pe
registry (SMI Security for PKIX Certificate Extension) for id-pe- registry (SMI Security for PKIX Certificate Extension) for id-pe-
masa-url with the value 32, resulting in an OID of masa-url with the value 32, resulting in an OID of
1.3.6.1.5.5.7.1.32. 1.3.6.1.5.5.7.1.32.
8.4. Pledge BRSKI Status Telemetry 8.5. Pledge BRSKI Status Telemetry
IANA is requested to create a new Registry entitled: "BRSKI IANA is requested to create a new Registry entitled: "BRSKI
Parameters", and within that Registry to create a table called: Parameters", and within that Registry to create a table called:
"Pledge BRSKI Status Telemetry Attributes". New items can be added "Pledge BRSKI Status Telemetry Attributes". New items can be added
using the Specification Required. The following items are to be in using the Specification Required. The following items are to be in
the initial registration, with this document (Section 5.7) as the the initial registration, with this document (Section 5.7) as the
reference: reference:
o version * version
o Status * Status
o Reason * Reason
o reason-context * reason-context
8.5. DNS Service Names 8.6. DNS Service Names
IANA is requested to register the following Service Names: IANA is requested to register the following Service Names:
Service Name: brski-proxy Service Name: brski-proxy
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 Proxy Infrastructures Proxy
Reference: [This document] Reference: [This document]
skipping to change at page 72, line 22 skipping to change at page 72, line 33
roles involved in BRSKI: The Manufacturer Authorized Signing roles involved in BRSKI: The Manufacturer Authorized Signing
Authority (MASA), the (Domain) Owner and the Device. It should be Authority (MASA), the (Domain) Owner and the Device. It should be
recognized that the manufacturer may be involved in two roles, as it recognized that the manufacturer may be involved in two roles, as it
creates the software/firmware for the device, and also may be the creates the software/firmware for the device, and also may be the
operator of the MASA. operator of the MASA.
The requirements in this section are presented using BCP14 The requirements in this section are presented using BCP14
([RFC2119], [RFC8174]) language. These do not represent new ([RFC2119], [RFC8174]) language. These do not represent new
normative statements, just a review of a few such things in one place 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. by role. They also apply specifically to the ANIMA ACP use case.
Other use cases likely have similar, but MAY different requirements. Other use cases likely have similar, but MAY have different
requirements.
9.1.1. MASA Operational Requirements 9.1.1. MASA Operational Requirements
The manufacturer MUST arrange for an online service to be available The manufacturer MUST arrange for an online service to be available
called the MASA. It MUST be available at the URL which is encoded in called the MASA. It MUST be available at the URL which is encoded in
the IDevID certificate extensions described in Section 2.3.2. the IDevID certificate extensions described in Section 2.3.2.
The online service MUST have access to a private key with which to The online service MUST have access to a private key with which to
sign [RFC8366] format voucher artifacts. The public key, sign [RFC8366] format voucher artifacts. The public key,
certificate, or certificate chain MUST be built in to the device as certificate, or certificate chain MUST be built in to the device as
skipping to change at page 72, line 45 skipping to change at page 73, line 11
It is RECOMMENDED that the manufacturer arrange for this signing key It is RECOMMENDED that the manufacturer arrange for this signing key
(or keys) to be escrowed according to typical software source code (or keys) to be escrowed according to typical software source code
escrow practices [softwareescrow]. escrow practices [softwareescrow].
The MASA accepts voucher requests from Domain Owners according to an The MASA accepts voucher requests from Domain Owners according to an
operational practice appropriate for the device. This can range from operational practice appropriate for the device. This can range from
any domain owner (first-come first-served, on a TOFU-like basis), to any domain owner (first-come first-served, on a TOFU-like basis), to
full sales channel integration where Domain Owners need to be full sales channel integration where Domain Owners need to be
positively identified by TLS Client Certicate pinned, or HTTP positively identified by TLS Client Certicate pinned, or HTTP
Authentication process. The MASA creates signed voucher artifacts Authentication process. The MASA creates signed voucher artifacts
according to a it's internally defined policies. according to its internally defined policies.
The MASA MUST operate an audit log for devices that is accessible. 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 The audit log is designed to be easily cacheable and the MASA MAY
find it useful to put this content on a CDN. find it useful to put this content on a CDN.
9.1.2. Domain Owner Operational Requirements 9.1.2. Domain Owner Operational Requirements
The domain owner MUST operate an EST ([RFC7030]) server with the The domain owner MUST operate an EST ([RFC7030]) server with the
extensions described in this document. This is the JRC or Registrar. extensions described in this document. This is the JRC or Registrar.
This JRC/EST server MUST announce itself using GRASP within the ACP. This JRC/EST server MUST announce itself using GRASP within the ACP.
skipping to change at page 75, line 33 skipping to change at page 76, line 7
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
The so-called "call-home" mechanism that occurs as part of the BRSKI- With consumer-oriented devices, the "call-home" mechanism in IoT
MASA connection standardizes what has been deemed by some as a devices raises significant privacy concerns. See [livingwithIoT] and
sinister mechanism for corporate oversight of individuals. [IoTstrangeThings] for exemplars. The Autonomic Control Plane (ACP)
([livingwithIoT] and [IoTstrangeThings] for a small sample). 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 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 76, line 19 skipping to change at page 76, line 45
While the contents of the signed part of the pledge voucher request While the contents of the signed part of the pledge voucher request
can not be changed, they are not encrypted at the registrar. The can not be changed, they are not encrypted at the registrar. The
ability to audit the messages by the owner of the network is a ability to audit the messages by the owner of the network is a
mechanism to defend against exfiltration of data by a nefarious mechanism to defend against exfiltration of data by a nefarious
pledge. Both are, to re-iterate, encrypted by TLS while in transit. pledge. Both are, to re-iterate, encrypted by TLS while in transit.
The BRSKI-MASA exchange reveals the following information to the The BRSKI-MASA exchange reveals the following information to the
manufacturer: manufacturer:
o the identity of the device being enrolled. This is revealed by * the identity of the device being enrolled. This is revealed by
transmission of a signed voucher-request containing the serial- transmission of a signed voucher-request containing the serial-
number. The manufacturer can usually link the serial number to a number. The manufacturer can usually link the serial number to a
device model. device model.
o an identity of the domain owner in the form of the domain trust * an identity of the domain owner in the form of the domain trust
anchor. However, this is not a global PKI anchored name within anchor. However, this is not a global PKI anchored name within
the WebPKI, so this identity could be pseudonymous. If there is the WebPKI, so this identity could be pseudonymous. If there is
sales channel integration, then the MASA will have authenticated sales channel integration, then the MASA will have authenticated
the domain owner, either via pinned certificate, or perhaps the domain owner, either via pinned certificate, or perhaps
another HTTP authentication method, as per Section 5.5.4. another HTTP authentication method, as per Section 5.5.4.
o the time the device is activated, * the time the device is activated,
o the IP address of the domain Owner's Registrar. For ISPs and * the IP address of the domain Owner's Registrar. For ISPs and
Enterprises, the IP address provides very clear geolocation of the Enterprises, the IP address provides very clear geolocation of the
owner. No amount of IP address privacy extensions ([RFC4941]) can owner. No amount of IP address privacy extensions ([RFC4941]) can
do anything about this, as a simple whois lookup likely identifies do anything about this, as a simple whois lookup likely identifies
the ISP or Enterprise from the upper bits anyway. A passive the ISP or Enterprise from the upper bits anyway. A passive
attacker who observes the connection definitely may conclude that attacker who observes the connection definitely may conclude that
the given enterprise/ISP is a customer of the particular equipment the given enterprise/ISP is a customer of the particular equipment
vendor. The precise model that is being enrolled will remain vendor. The precise model that is being enrolled will remain
private. private.
Based upon the above information, the manufacturer is able to track a Based upon the above information, the manufacturer is able to track a
skipping to change at page 82, line 33 skipping to change at page 83, line 11
registrar in the prior-signed-voucher-request field of the registrar registrar in the prior-signed-voucher-request field of the registrar
voucher-request, significantly reduce this risk by ensuring the MASA voucher-request, significantly reduce this risk by ensuring the MASA
can confirm proximity between the pledge and the registrar making the can confirm proximity between the pledge and the registrar making the
request. Supply chain integration ("know your customer") is an request. Supply chain integration ("know your customer") is an
additional step that MASA providers and device vendors can explore. additional step that MASA providers and device vendors can explore.
11.2. DomainID must be resistant to second-preimage attacks 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 used as the reference in the audit log to the domain.
The domainID is expected to be calculated by a hash that is resistant The domainID is expected to be calculated by a hash that is resistant
to a second-preimage attack. The consequences of such an attack to a second-preimage attack. Such an attack would allow a second
would allow a second registrar to create audit log entries that are registrar to create audit log entries that are fake.
fake.
11.3. Availability of good random numbers 11.3. Availability of good random numbers
The nonce used by the Pledge in the voucher-request SHOULD be The nonce used by the Pledge in the voucher-request SHOULD be
generated by a Strong Cryptographic Sequence ([RFC4086] section 6.2). generated by a Strong Cryptographic Sequence ([RFC4086] section 6.2).
TLS has a similar requirement. TLS has a similar requirement.
In particular implementations should pay attention to the advance in In particular implementations should pay attention to the advance in
[RFC4086] section 3, particularly section 3.4. Devices which are [RFC4086] section 3, particularly section 3.4. The random seed used
reset to factory default in order to perform a second bootstrap with by a device at boot MUST be unique across all devices and all
a new owner MUST NOT use idential seeds. bootstraps. Resetting a device to factory default state does not
obviate this requirement.
11.4. Freshness in Voucher-Requests 11.4. Freshness in Voucher-Requests
A concern has been raised that the pledge voucher-request should A concern has been raised that the pledge voucher-request should
contain some content (a nonce) provided by the registrar and/or MASA contain some content (a nonce) provided by the registrar and/or MASA
in order for those actors to verify that the pledge voucher-request in order for those actors to verify that the pledge voucher-request
is fresh. is fresh.
There are a number of operational problems with getting a nonce from 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 the MASA to the pledge. It is somewhat easier to collect a random
skipping to change at page 84, line 8 skipping to change at page 84, line 34
generate a strong random or pseudo-random number nonce. generate a strong random or pseudo-random number nonce.
Additionally, in order to successfully use the resulting voucher the Additionally, in order to successfully use the resulting voucher the
Rm would have to attack the pledge and return it to a bootstrapping Rm would have to attack the pledge and return it to a bootstrapping
enabled state. This would require wiping the pledge of current enabled state. This would require wiping the pledge of current
configuration and triggering a re-bootstrapping of the pledge. This configuration and triggering a re-bootstrapping of the pledge. This
is no more likely than simply taking control of the pledge directly is no more likely than simply taking control of the pledge directly
but if this is a consideration the target network is RECOMMENDED to but if this is a consideration the target network is RECOMMENDED to
take the following steps: take the following steps:
o Ongoing network monitoring for unexpected bootstrapping attempts * Ongoing network monitoring for unexpected bootstrapping attempts
by pledges. by pledges.
o Retrieval and examination of MASA log information upon the * Retrieval and examination of MASA log information upon the
occurrence of any such unexpected events. Rm will be listed in occurrence of any such unexpected events. Rm will be listed in
the logs along with nonce information for analysis. the logs along with nonce information for analysis.
11.5. Trusting manufacturers 11.5. Trusting manufacturers
The BRSKI extensions to EST permit a new pledge to be completely The BRSKI extensions to EST permit a new pledge to be completely
configured with domain specific trust anchors. The link from built- configured with domain specific trust anchors. The link from built-
in manufacturer-provided trust anchors to domain-specific trust in manufacturer-provided trust anchors to domain-specific trust
anchors is mediated by the signed voucher artifact. anchors is mediated by the signed voucher artifact.
skipping to change at page 84, line 38 skipping to change at page 85, line 16
BRSKI does not, however, fundamentally change the trust model from BRSKI does not, however, fundamentally change the trust model from
domain owner to manufacturer. Assuming that the pledge used its domain owner to manufacturer. Assuming that the pledge used its
IDevID with RFC7030 EST and BRSKI, the domain (registrar) still needs IDevID with RFC7030 EST and BRSKI, the domain (registrar) still needs
to trust the manufacturer. to trust the manufacturer.
Establishing this trust between domain and manufacturer is outside Establishing this trust between domain and manufacturer is outside
the scope of BRSKI. There are a number of mechanisms that can the scope of BRSKI. There are a number of mechanisms that can
adopted including: adopted including:
o Manually configuring each manufacturer's trust anchor. * Manually configuring each manufacturer's trust anchor.
o A Trust-On-First-Use (TOFU) mechanism. A human would be queried * A Trust-On-First-Use (TOFU) mechanism. A human would be queried
upon seeing a manufacturer's trust anchor for the first time, and upon seeing a manufacturer's trust anchor for the first time, and
then the trust anchor would be installed to the trusted store. then the trust anchor would be installed to the trusted store.
There are risks with this; even if the key to name mapping is There are risks with this; even if the key to name mapping is
validated using something like the WebPKI, there remains the validated using something like the WebPKI, there remains the
possibility that the name is a look alike: e.g, dem0.example. vs possibility that the name is a look alike: e.g, dem0.example. vs
demO.example. demO.example.
o scanning the trust anchor from a QR code that came with the * scanning the trust anchor from a QR code that came with the
packaging (this is really a manual TOFU mechanism) packaging (this is really a manual TOFU mechanism)
o some sales integration process where trust anchors are provided as * some sales integration process where trust anchors are provided as
part of the sales process, probably included in a digital packing part of the sales process, probably included in a digital packing
"slip", or a sales invoice. "slip", or a sales invoice.
o consortium membership, where all manufacturers of a particular * consortium membership, where all manufacturers of a particular
device category (e.g, a light bulb, or a cable-modem) are signed device category (e.g, a light bulb, or a cable-modem) are signed
by an certificate authority specifically for this. This is done by an certificate authority specifically for this. This is done
by CableLabs today. It is used for authentication and by CableLabs today. It is used for authentication and
authorization as part of TR-79: [docsisroot] and [TR069]. authorization as part of TR-79: [docsisroot] and [TR069].
The existing WebPKI provides a reasonable anchor between manufacturer The existing WebPKI provides a reasonable anchor between manufacturer
name and public key. It authenticates the key. It does not provide name and public key. It authenticates the key. It does not provide
a reasonable authorization for the manufacturer, so it is not a reasonable authorization for the manufacturer, so it is not
directly useable on it's own. directly useable on it's own.
skipping to change at page 89, line 33 skipping to change at page 90, line 8
service. Said device still needs to be convinced to do through a service. Said device still needs to be convinced to do through a
factory reset process before an attack. factory reset process before an attack.
If the attacker has access to a key that is trusted for long-lived If the attacker has access to a key that is trusted for long-lived
nonceless vouchers, then they could issue vouchers for devices which nonceless vouchers, then they could issue vouchers for devices which
are not yet in service. This attack may be very hard to verify and are not yet in service. This attack may be very hard to verify and
as it would involve doing firmware updates on every device in as it would involve doing firmware updates on every device in
warehouses (a potentially ruinously expensive process), a warehouses (a potentially ruinously expensive process), a
manufacturer might be reluctant to admit this possibility. manufacturer might be reluctant to admit this possibility.
11.7. YANG Module Security Considerations
As described in the Security Considerations section of [RFC8366]
(section 7.4), 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 template described by Section 3.7 of
[RFC8407].
12. Acknowledgements 12. Acknowledgements
We would like to thank the various reviewers for their input, in We would like to thank the various reviewers for their input, in
particular William Atwood, Brian Carpenter, Fuyu Eleven, Eliot Lear, particular William Atwood, Brian Carpenter, Fuyu Eleven, Eliot Lear,
Sergey Kasatkin, Anoop Kumar, Markus Stenberg, Peter van der Stok, Sergey Kasatkin, Anoop Kumar, Tom Petch, Markus Stenberg, Peter van
and Thomas Werner der Stok, and Thomas Werner
Significant reviews were done by Jari Arko, Christian Huitema and Significant reviews were done by Jari Arko, Christian Huitema and
Russ Housley. Russ Housley.
Henk Birkholz contributed the CDDL for the audit log response. Henk Birkholz contributed the CDDL for the audit log response.
This document started it's life as a two-page idea from Steinthor This document started it's life as a two-page idea from Steinthor
Bjarnason. Bjarnason.
In addition, significant review comments were received by many IESG In addition, significant review comments were received by many IESG
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)", Work in Progress, Internet-Draft,
plane-21 (work in progress), November 2019. draft-ietf-anima-autonomic-control-plane-21, 3 November
2019, <http://www.ietf.org/internet-drafts/draft-ietf-
anima-autonomic-control-plane-21.txt>.
[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)", Work in Progress,
grasp-15 (work in progress), July 2017. Internet-Draft, draft-ietf-anima-grasp-15, 13 July 2017,
<http://www.ietf.org/internet-drafts/draft-ietf-anima-
grasp-15.txt>.
[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>.
[ITU.X690.1994] [REST] Fielding, R.F., "Architectural Styles and the Design of
International Telecommunications Union, "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, 1994.
[REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", 2000, Network-based Software Architectures", 2000,
<http://www.ics.uci.edu/~fielding/pubs/dissertation/ <http://www.ics.uci.edu/~fielding/pubs/dissertation/
top.htm>. top.htm>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
skipping to change at page 91, line 44 skipping to change at page 92, line 29
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
<https://www.rfc-editor.org/info/rfc5272>. <https://www.rfc-editor.org/info/rfc5272>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing
Security: An Unauthenticated Mode of IPsec", RFC 5386,
DOI 10.17487/RFC5386, November 2008,
<https://www.rfc-editor.org/info/rfc5386>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC5660] Williams, N., "IPsec Channels: Connection Latching", [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
RFC 5660, DOI 10.17487/RFC5660, October 2009, the Network Configuration Protocol (NETCONF)", RFC 6020,
<https://www.rfc-editor.org/info/rfc5660>. DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 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, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>. <https://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
skipping to change at page 93, line 9 skipping to change at page 93, line 36
2015, <https://www.rfc-editor.org/info/rfc7469>. 2015, <https://www.rfc-editor.org/info/rfc7469>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016, RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>. <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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols", "A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018, RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>. <https://www.rfc-editor.org/info/rfc8366>.
[RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic
Control Plane for Stable Connectivity of Network Control Plane for Stable Connectivity of Network
Operations, Administration, and Maintenance (OAM)", Operations, Administration, and Maintenance (OAM)",
RFC 8368, DOI 10.17487/RFC8368, May 2018, RFC 8368, DOI 10.17487/RFC8368, May 2018,
<https://www.rfc-editor.org/info/rfc8368>. <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 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
skipping to change at page 94, line 18 skipping to change at page 95, line 7
<https://www.iana.org/dnssec/dps/zsk-operator/dps-zsk- <https://www.iana.org/dnssec/dps/zsk-operator/dps-zsk-
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)", Work in Progress,
est-17 (work in progress), December 2019. Internet-Draft, draft-ietf-ace-coap-est-17, 5 December
2019, <http://www.ietf.org/internet-drafts/draft-ietf-ace-
coap-est-17.txt>.
[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", Work in
ietf-anima-constrained-voucher-05 (work in progress), July Progress, Internet-Draft, draft-ietf-anima-constrained-
2019. voucher-05, 8 July 2019, <http://www.ietf.org/internet-
drafts/draft-ietf-anima-constrained-voucher-05.txt>.
[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
Networking", draft-ietf-anima-reference-model-10 (work in Networking", Work in Progress, Internet-Draft, draft-ietf-
progress), November 2018. anima-reference-model-10, 22 November 2018,
<http://www.ietf.org/internet-drafts/draft-ietf-anima-
[I-D.ietf-anima-stable-connectivity] reference-model-10.txt>.
Eckert, T. and M. Behringer, "Using Autonomic Control
Plane for Stable Connectivity of Network OAM", draft-ietf-
anima-stable-connectivity-10 (work in progress), February
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", Work in
ietf-netconf-keystore-15 (work in progress), November Progress, Internet-Draft, draft-ietf-netconf-keystore-15,
2019. 20 November 2019, <http://www.ietf.org/internet-drafts/
draft-ietf-netconf-keystore-15.txt>.
[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", Work in Progress,
state-for-joinrouter-02 (work in progress), January 2018. Internet-Draft, draft-richardson-anima-state-for-
joinrouter-02, 25 January 2018, <http://www.ietf.org/
internet-drafts/draft-richardson-anima-state-for-
joinrouter-02.txt>.
[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)>.
[IoTstrangeThings] [IoTstrangeThings]
"IoT of toys stranger than fiction: Cybersecurity and data "IoT of toys stranger than fiction: Cybersecurity and data
privacy update (accessed 2018-12-02)", March 2017, privacy update (accessed 2018-12-02)", March 2017,
<https://www.welivesecurity.com/2017/03/03/internet-of- <https://www.welivesecurity.com/2017/03/03/internet-of-
things-security-privacy-iot-update/>. things-security-privacy-iot-update/>.
skipping to change at page 96, line 23 skipping to change at page 97, line 15
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575, Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015, DOI 10.17487/RFC7575, June 2015,
<https://www.rfc-editor.org/info/rfc7575>. <https://www.rfc-editor.org/info/rfc7575>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
Description Specification", RFC 8520,
DOI 10.17487/RFC8520, March 2019,
<https://www.rfc-editor.org/info/rfc8520>.
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>.
[slowloris] [slowloris]
"Slowloris (computer security)", February 2019, "Slowloris (computer security)", February 2019,
<https://en.wikipedia.org/wiki/ <https://en.wikipedia.org/wiki/
Slowloris_(computer_security)/>. Slowloris_(computer_security)/>.
[softwareescrow] [softwareescrow]
"Wikipedia article: Software Escrow", October 2019, "Wikipedia article: Software Escrow", October 2019,
<https://en.wikipedia.org/wiki/Source_code_escrow>. <https://en.wikipedia.org/wiki/Source_code_escrow>.
[Stajano99theresurrecting] [Stajano99theresurrecting]
skipping to change at page 97, line 7 skipping to change at page 97, line 36
security issues for ad-hoc wireless networks", 1999, security issues for ad-hoc wireless networks", 1999,
<https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd- <https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-
duckling.pdf>. duckling.pdf>.
[TR069] "TR-69: CPE WAN Management Protocol", February 2018, [TR069] "TR-69: CPE WAN Management Protocol", February 2018,
<https://www.broadband-forum.org/standards-and-software/ <https://www.broadband-forum.org/standards-and-software/
technical-specifications/tr-069-files-tools>. technical-specifications/tr-069-files-tools>.
[W3C.WD-capability-urls-20140218] [W3C.WD-capability-urls-20140218]
Tennison, J., "Good Practices for Capability URLs", World Tennison, J., "Good Practices for Capability URLs", World
Wide Web Consortium WD WD-capability-urls-20140218, Wide Web Consortium WD WD-capability-urls-20140218, 18
February 2014, February 2014,
<http://www.w3.org/TR/2014/WD-capability-urls-20140218>. <http://www.w3.org/TR/2014/WD-capability-urls-20140218>.
Appendix A. IPv4 and non-ANI operations Appendix A. IPv4 and non-ANI operations
The secification of BRSKI in Section 4 intentionally only covers the The specification of BRSKI in Section 4 intentionally only covers the
mechanisms for an IPv6 pledge using Link-Local addresses. This mechanisms for an IPv6 pledge using Link-Local addresses. This
section describes non-normative extensions that can be used in other section describes non-normative extensions that can be used in other
environments. environments.
A.1. IPv4 Link Local addresses A.1. IPv4 Link Local addresses
Instead of an IPv6 link-local address, an IPv4 address may be Instead of an IPv6 link-local address, an IPv4 address may be
generated using [RFC3927] Dynamic Configuration of IPv4 Link-Local generated using [RFC3927] Dynamic Configuration of IPv4 Link-Local
Addresses. Addresses.
In the case that an IPv4 Link-Local address is formed, then the In the case that an IPv4 Link-Local address is formed, then the
bootstrap process would continue as in the IPv6 case by looking for a bootstrap process would continue as in the IPv6 case by looking for a
(circuit) proxy. (circuit) proxy.
A.2. Use of DHCPv4 A.2. Use of DHCPv4
The Plege MAY obtain an IP address via DHCP [RFC2131]. The DHCP The Pledge MAY obtain an IP address via DHCP [RFC2131]. The DHCP
provided parameters for the Domain Name System can be used to perform provided parameters for the Domain Name System can be used to perform
DNS operations if all local discovery attempts fail. DNS operations if all local discovery attempts fail.
Appendix B. mDNS / DNSSD proxy discovery options Appendix B. mDNS / DNSSD proxy discovery options
Pledge discovery of the proxy (Section 4.1) MAY be performed with Pledge discovery of the proxy (Section 4.1) MAY be performed with
DNS-based Service Discovery [RFC6763] over Multicast DNS [RFC6762] to DNS-based Service Discovery [RFC6763] over Multicast DNS [RFC6762] to
discover the proxy at "_brski-proxy._tcp.local.". discover the proxy at "_brski-proxy._tcp.local.".
Proxy discovery of the registrar (Section 4.3) MAY be performed with Proxy discovery of the registrar (Section 4.3) MAY be performed with
skipping to change at page 101, line 9 skipping to change at page 102, line 9
-----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 Fountain CA Issuer: DC = ca, DC = sandelman, CN = Unstrung Fount
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:
skipping to change at page 103, line 5 skipping to change at page 104, line 5
fynMV3kMuIpSKrYzRWr4g3PtTwXDsAe0oitTTj4QtU1bajhOfTkCMGMNbsW2Q41F fynMV3kMuIpSKrYzRWr4g3PtTwXDsAe0oitTTj4QtU1bajhOfTkCMGMNbsW2Q41F
z9t6PDVdtOKabBbAP1RVoFTlDQuO9nmLzb5kU+cUqCtPRFZBUXP3kg== z9t6PDVdtOKabBbAP1RVoFTlDQuO9nmLzb5kU+cUqCtPRFZBUXP3kg==
-----END CERTIFICATE----- -----END CERTIFICATE-----
The pledge public certificate as decoded by openssl's x509 utility so The pledge public certificate as decoded by openssl's x509 utility so
that the extensions can be seen. This was version 1.1.1c of the that the extensions can be seen. This was version 1.1.1c of the
[openssl] library and utility. There is a second Custom Extension is [openssl] library and utility. There is a second Custom Extension is
included to provided to contain the EUI48/EUI64 that the pledge will included to provided to contain the EUI48/EUI64 that the pledge will
configure as it's layer-2 address (this is non-normative). configure as it's layer-2 address (this is non-normative).
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 166573225 (0x9edb4a9) Serial Number: 166573225 (0x9edb4a9)
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
Issuer: DC = ca, DC = sandelman, CN = Unstrung Highway CA Issuer: DC = ca, DC = sandelman, CN = Unstrung Highway CA
Validity Validity
Not Before: Apr 24 02:16:58 2019 GMT Not Before: Apr 24 02:16:58 2019 GMT
Not After : Dec 31 00:00:00 2999 GMT Not After : Dec 31 00:00:00 2999 GMT
Subject: serialNumber = 00-d0-e5-02-00-2d Subject: serialNumber = 00-d0-e5-02-00-2d
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:5a:2f:e3:a8:fa:51:27:42:60:5a:08:59:46:07: 04:5a:2f:e3:a8:fa:51:27:42:60:5a:08:59:46:07:
99:94:b2:ae:b5:b5:d5:8e:69:c7:6f:ed:40:61:a1: 99:94:b2:ae:b5:b5:d5:8e:69:c7:6f:ed:40:61:a1:
05:fd:84:23:13:68:39:15:95:7c:2a:38:91:fd:b9: 05:fd:84:23:13:68:39:15:95:7c:2a:38:91:fd:b9:
04:97:e9:7c:33:8a:27:20:2e:ca:1d:a5:ca:2a:4b: 04:97:e9:7c:33:8a:27:20:2e:ca:1d:a5:ca:2a:4b:
9a:83:d4:ba:4f 9a:83:d4:ba:4f
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256 NIST CURVE: P-256
X509v3 extensions: X509v3 extensions:
X509v3 Subject Key Identifier: X509v3 Subject Key Identifier:
8F:C2:98:75:4A:04:3A:F2:74:91:C3:88:6E:31:16:C2:05:9D:0D:89 8F:C2:98:75:4A:04:3A:F2:74:91:C3:88:6E:31:16:C2:05:9D:0D:89
X509v3 Basic Constraints: X509v3 Basic Constraints:
CA:FALSE CA:FALSE
X509v3 Subject Alternative Name: X509v3 Subject Alternative Name:
othername:<unsupported> othername:<unsupported>
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
C.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.
C.2.1. Pledge to Registrar C.2.1. Pledge to Registrar
skipping to change at page 104, line 51 skipping to change at page 105, line 51
+INz7U8Fw7AHtKIrU04+ELVNW2o4Tn05AjBjDW7FtkONRc/bejw1XbTimmwWwD9U +INz7U8Fw7AHtKIrU04+ELVNW2o4Tn05AjBjDW7FtkONRc/bejw1XbTimmwWwD9U
VaBU5Q0LjvZ5i82+ZFPnFKgrT0RWQVFz95IxggErMIIBJwIBATBVME0xEjAQBgoJ VaBU5Q0LjvZ5i82+ZFPnFKgrT0RWQVFz95IxggErMIIBJwIBATBVME0xEjAQBgoJ
kiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjEcMBoGA1UE kiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjEcMBoGA1UE
AwwTVW5zdHJ1bmcgSGlnaHdheSBDQQIECe20qTALBglghkgBZQMEAgGgaTAYBgkq AwwTVW5zdHJ1bmcgSGlnaHdheSBDQQIECe20qTALBglghkgBZQMEAgGgaTAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA1MTUyMTI1 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA1MTUyMTI1
NTVaMC8GCSqGSIb3DQEJBDEiBCAQN2lP7aqwyhmj9qUHt6Qk/SbOTOPXFOwn1wv2 NTVaMC8GCSqGSIb3DQEJBDEiBCAQN2lP7aqwyhmj9qUHt6Qk/SbOTOPXFOwn1wv2
5YGYgDAKBggqhkjOPQQDAgRHMEUCIEYQhHToU0rrhPyQv2fR0TwWePTx2Z1DEhR4 5YGYgDAKBggqhkjOPQQDAgRHMEUCIEYQhHToU0rrhPyQv2fR0TwWePTx2Z1DEhR4
tTl/Dr/ZAiEA47u9+bIz/p6nFJ+wctKHER+ycUzYQF56h9odMo+Ilkc= tTl/Dr/ZAiEA47u9+bIz/p6nFJ+wctKHER+ycUzYQF56h9odMo+Ilkc=
-----END CMS----- -----END CMS-----
file: examples/vr_00-D0-E5-02-00-2D.pkcs
The ASN1 decoding of the artifact: The ASN1 decoding of the artifact:
0:d=0 hl=4 l=1717 cons: SEQUENCE file: examples/vr_00-D0-E5-02-00-2D.pkcs
4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData
15:d=1 hl=4 l=1702 cons: cont [ 0 ] 0:d=0 hl=4 l=1717 cons: SEQUENCE
19:d=2 hl=4 l=1698 cons: SEQUENCE 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData
23:d=3 hl=2 l= 1 prim: INTEGER :01 15:d=1 hl=4 l=1702 cons: cont [ 0 ]
26:d=3 hl=2 l= 13 cons: SET 19:d=2 hl=4 l=1698 cons: SEQUENCE
28:d=4 hl=2 l= 11 cons: SEQUENCE 23:d=3 hl=2 l= 1 prim: INTEGER :01
30:d=5 hl=2 l= 9 prim: OBJECT :sha256 26:d=3 hl=2 l= 13 cons: SET
41:d=3 hl=4 l= 849 cons: SEQUENCE 28:d=4 hl=2 l= 11 cons: SEQUENCE
45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 30:d=5 hl=2 l= 9 prim: OBJECT :sha256
56:d=4 hl=4 l= 834 cons: cont [ 0 ] 41:d=3 hl=4 l= 849 cons: SEQUENCE
60:d=5 hl=4 l= 830 prim: OCTET STRING :{"ietf-voucher-request:v 45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data
894:d=3 hl=4 l= 520 cons: cont [ 0 ] 56:d=4 hl=4 l= 834 cons: cont [ 0 ]
898:d=4 hl=4 l= 516 cons: SEQUENCE 60:d=5 hl=4 l= 830 prim: OCTET STRING :{"ietf-voucher-request:v
902:d=5 hl=4 l= 395 cons: SEQUENCE 894:d=3 hl=4 l= 520 cons: cont [ 0 ]
906:d=6 hl=2 l= 3 cons: cont [ 0 ] 898:d=4 hl=4 l= 516 cons: SEQUENCE
908:d=7 hl=2 l= 1 prim: INTEGER :02 902:d=5 hl=4 l= 395 cons: SEQUENCE
911:d=6 hl=2 l= 4 prim: INTEGER :09EDB4A9 906:d=6 hl=2 l= 3 cons: cont [ 0 ]
917:d=6 hl=2 l= 10 cons: SEQUENCE 908:d=7 hl=2 l= 1 prim: INTEGER :02
919:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 911:d=6 hl=2 l= 4 prim: INTEGER :09EDB4A9
929:d=6 hl=2 l= 77 cons: SEQUENCE 917:d=6 hl=2 l= 10 cons: SEQUENCE
931:d=7 hl=2 l= 18 cons: SET 919:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
933:d=8 hl=2 l= 16 cons: SEQUENCE 929:d=6 hl=2 l= 77 cons: SEQUENCE
935:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 931:d=7 hl=2 l= 18 cons: SET
947:d=9 hl=2 l= 2 prim: IA5STRING :ca 933:d=8 hl=2 l= 16 cons: SEQUENCE
951:d=7 hl=2 l= 25 cons: SET 935:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
953:d=8 hl=2 l= 23 cons: SEQUENCE 947:d=9 hl=2 l= 2 prim: IA5STRING :ca
955:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 951:d=7 hl=2 l= 25 cons: SET
967:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 953:d=8 hl=2 l= 23 cons: SEQUENCE
978:d=7 hl=2 l= 28 cons: SET 955:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
980:d=8 hl=2 l= 26 cons: SEQUENCE 967:d=9 hl=2 l= 9 prim: IA5STRING :sandelman
982:d=9 hl=2 l= 3 prim: OBJECT :commonName 978:d=7 hl=2 l= 28 cons: SET
987:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Highway CA 980:d=8 hl=2 l= 26 cons: SEQUENCE
1008:d=6 hl=2 l= 32 cons: SEQUENCE 982:d=9 hl=2 l= 3 prim: OBJECT :commonName
1010:d=7 hl=2 l= 13 prim: UTCTIME :190424021658Z 987:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Highway CA
1025:d=7 hl=2 l= 15 prim: GENERALIZEDTIME :29991231000000Z 1008:d=6 hl=2 l= 32 cons: SEQUENCE
1042:d=6 hl=2 l= 28 cons: SEQUENCE 1010:d=7 hl=2 l= 13 prim: UTCTIME :190424021658Z
1044:d=7 hl=2 l= 26 cons: SET 1025:d=7 hl=2 l= 15 prim: GENERALIZEDTIME :29991231000000Z
1046:d=8 hl=2 l= 24 cons: SEQUENCE 1042:d=6 hl=2 l= 28 cons: SEQUENCE
1048:d=9 hl=2 l= 3 prim: OBJECT :serialNumber 1044:d=7 hl=2 l= 26 cons: SET
1053:d=9 hl=2 l= 17 prim: UTF8STRING :00-d0-e5-02-00-2d 1046:d=8 hl=2 l= 24 cons: SEQUENCE
1072:d=6 hl=2 l= 89 cons: SEQUENCE 1048:d=9 hl=2 l= 3 prim: OBJECT :serialNumber
1074:d=7 hl=2 l= 19 cons: SEQUENCE 1053:d=9 hl=2 l= 17 prim: UTF8STRING :00-d0-e5-02-00-2d
1076:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 1072:d=6 hl=2 l= 89 cons: SEQUENCE
1085:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 1074:d=7 hl=2 l= 19 cons: SEQUENCE
1095:d=7 hl=2 l= 66 prim: BIT STRING 1076:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey
1163:d=6 hl=3 l= 135 cons: cont [ 3 ] 1085:d=8 hl=2 l= 8 prim: OBJECT :prime256v1
1166:d=7 hl=3 l= 132 cons: SEQUENCE 1095:d=7 hl=2 l= 66 prim: BIT STRING
1169:d=8 hl=2 l= 29 cons: SEQUENCE 1163:d=6 hl=3 l= 135 cons: cont [ 3 ]
1171:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Ident 1166:d=7 hl=3 l= 132 cons: SEQUENCE
1176:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:04148FC298754A 1169:d=8 hl=2 l= 29 cons: SEQUENCE
1200:d=8 hl=2 l= 9 cons: SEQUENCE 1171:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Ident
1202:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 1176:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:04148FC298754A
1207:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000 1200:d=8 hl=2 l= 9 cons: SEQUENCE
1211:d=8 hl=2 l= 43 cons: SEQUENCE 1202:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints
1213:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Alternati 1207:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000
1218:d=9 hl=2 l= 36 prim: OCTET STRING [HEX DUMP]:3022A02006092B 1211:d=8 hl=2 l= 43 cons: SEQUENCE
1256:d=8 hl=2 l= 43 cons: SEQUENCE 1213:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Alternati
1258:d=9 hl=2 l= 9 prim: OBJECT :1.3.6.1.4.1.46930.2 1218:d=9 hl=2 l= 36 prim: OCTET STRING [HEX DUMP]:3022A02006092B
1269:d=9 hl=2 l= 30 prim: OCTET STRING [HEX DUMP]:0C1C6D6173612E 1256:d=8 hl=2 l= 43 cons: SEQUENCE
1301:d=5 hl=2 l= 10 cons: SEQUENCE 1258:d=9 hl=2 l= 9 prim: OBJECT :1.3.6.1.4.1.46930.2
1303:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 1269:d=9 hl=2 l= 30 prim: OCTET STRING [HEX DUMP]:0C1C6D6173612E
1313:d=5 hl=2 l= 103 prim: BIT STRING 1301:d=5 hl=2 l= 10 cons: SEQUENCE
1418:d=3 hl=4 l= 299 cons: SET 1303:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
1422:d=4 hl=4 l= 295 cons: SEQUENCE 1313:d=5 hl=2 l= 103 prim: BIT STRING
1426:d=5 hl=2 l= 1 prim: INTEGER :01 1418:d=3 hl=4 l= 299 cons: SET
1429:d=5 hl=2 l= 85 cons: SEQUENCE 1422:d=4 hl=4 l= 295 cons: SEQUENCE
1431:d=6 hl=2 l= 77 cons: SEQUENCE 1426:d=5 hl=2 l= 1 prim: INTEGER :01
1433:d=7 hl=2 l= 18 cons: SET 1429:d=5 hl=2 l= 85 cons: SEQUENCE
1435:d=8 hl=2 l= 16 cons: SEQUENCE 1431:d=6 hl=2 l= 77 cons: SEQUENCE
1437:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 1433:d=7 hl=2 l= 18 cons: SET
1449:d=9 hl=2 l= 2 prim: IA5STRING :ca 1435:d=8 hl=2 l= 16 cons: SEQUENCE
1453:d=7 hl=2 l= 25 cons: SET 1437:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
1455:d=8 hl=2 l= 23 cons: SEQUENCE 1449:d=9 hl=2 l= 2 prim: IA5STRING :ca
1457:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 1453:d=7 hl=2 l= 25 cons: SET
1469:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 1455:d=8 hl=2 l= 23 cons: SEQUENCE
1480:d=7 hl=2 l= 28 cons: SET 1457:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
1482:d=8 hl=2 l= 26 cons: SEQUENCE 1469:d=9 hl=2 l= 9 prim: IA5STRING :sandelman
1484:d=9 hl=2 l= 3 prim: OBJECT :commonName 1480:d=7 hl=2 l= 28 cons: SET
1489:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Highway CA 1482:d=8 hl=2 l= 26 cons: SEQUENCE
1510:d=6 hl=2 l= 4 prim: INTEGER :09EDB4A9 1484:d=9 hl=2 l= 3 prim: OBJECT :commonName
1516:d=5 hl=2 l= 11 cons: SEQUENCE 1489:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Highway CA
1518:d=6 hl=2 l= 9 prim: OBJECT :sha256 1510:d=6 hl=2 l= 4 prim: INTEGER :09EDB4A9
1529:d=5 hl=2 l= 105 cons: cont [ 0 ] 1516:d=5 hl=2 l= 11 cons: SEQUENCE
1531:d=6 hl=2 l= 24 cons: SEQUENCE 1518:d=6 hl=2 l= 9 prim: OBJECT :sha256
1533:d=7 hl=2 l= 9 prim: OBJECT :contentType 1529:d=5 hl=2 l= 105 cons: cont [ 0 ]
1544:d=7 hl=2 l= 11 cons: SET 1531:d=6 hl=2 l= 24 cons: SEQUENCE
1546:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 1533:d=7 hl=2 l= 9 prim: OBJECT :contentType
1557:d=6 hl=2 l= 28 cons: SEQUENCE 1544:d=7 hl=2 l= 11 cons: SET
1559:d=7 hl=2 l= 9 prim: OBJECT :signingTime 1546:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data
1570:d=7 hl=2 l= 15 cons: SET 1557:d=6 hl=2 l= 28 cons: SEQUENCE
1572:d=8 hl=2 l= 13 prim: UTCTIME :190515212555Z 1559:d=7 hl=2 l= 9 prim: OBJECT :signingTime
1587:d=6 hl=2 l= 47 cons: SEQUENCE 1570:d=7 hl=2 l= 15 cons: SET
1589:d=7 hl=2 l= 9 prim: OBJECT :messageDigest 1572:d=8 hl=2 l= 13 prim: UTCTIME :190515212555Z
1600:d=7 hl=2 l= 34 cons: SET 1587:d=6 hl=2 l= 47 cons: SEQUENCE
1602:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:1037694FEDAAB0 1589:d=7 hl=2 l= 9 prim: OBJECT :messageDigest
1636:d=5 hl=2 l= 10 cons: SEQUENCE 1600:d=7 hl=2 l= 34 cons: SET
1638:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 1602:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:1037694FEDAAB0
1648:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:30450220461084 1636:d=5 hl=2 l= 10 cons: SEQUENCE
1638:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
1648:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:30450220461084
The JSON contained in the voucher request: The JSON contained in the voucher request:
{"ietf-voucher-request:voucher":{"assertion":"proximity","cr {"ietf-voucher-request:voucher":{"assertion":"proximity","cr
eated-on":"2019-05-15T17:25:55.644-04:00","serial-number":"0 eated-on":"2019-05-15T17:25:55.644-04:00","serial-number":"0
0-d0-e5-02-00-2d","nonce":"VOUFT-WwrEv0NuAQEHoV7Q","proximit 0-d0-e5-02-00-2d","nonce":"VOUFT-WwrEv0NuAQEHoV7Q","proximit
y-registrar-cert":"MIIB0TCCAVagAwIBAgIBAjAKBggqhkjOPQQDAzBxM y-registrar-cert":"MIIB0TCCAVagAwIBAgIBAjAKBggqhkjOPQQDAzBxM
RIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtY RIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtY
W4xQDA+BgNVBAMMNyM8U3lzdGVtVmFyaWFibGU6MHgwMDAwMDAwNGY5MTFhM W4xQDA+BgNVBAMMNyM8U3lzdGVtVmFyaWFibGU6MHgwMDAwMDAwNGY5MTFhM
D4gVW5zdHJ1bmcgRm91bnRhaW4gQ0EwHhcNMTcxMTA3MjM0NTI4WhcNMTkxM D4gVW5zdHJ1bmcgRm91bnRhaW4gQ0EwHhcNMTcxMTA3MjM0NTI4WhcNMTkxM
skipping to change at page 109, line 24 skipping to change at page 110, line 24
cwu0u4JzpDGCAUwwggFIAgEBMHYwcTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYK cwu0u4JzpDGCAUwwggFIAgEBMHYwcTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYK
CZImiZPyLGQBGRYJc2FuZGVsbWFuMUAwPgYDVQQDDDcjPFN5c3RlbVZhcmlhYmxl CZImiZPyLGQBGRYJc2FuZGVsbWFuMUAwPgYDVQQDDDcjPFN5c3RlbVZhcmlhYmxl
OjB4MDAwMDAwMDRmOTExYTA+IFVuc3RydW5nIEZvdW50YWluIENBAgECMAsGCWCG OjB4MDAwMDAwMDRmOTExYTA+IFVuc3RydW5nIEZvdW50YWluIENBAgECMAsGCWCG
SAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF SAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTE5MDUxNTIxMjU1NVowLwYJKoZIhvcNAQkEMSIEIFBQjMmWzZOEkRHXrVAS MQ8XDTE5MDUxNTIxMjU1NVowLwYJKoZIhvcNAQkEMSIEIFBQjMmWzZOEkRHXrVAS
snJwgQ26goyvOAtUFYs3MstMMAoGCCqGSM49BAMCBEcwRQIgBthbhEmgbqZbYDkD snJwgQ26goyvOAtUFYs3MstMMAoGCCqGSM49BAMCBEcwRQIgBthbhEmgbqZbYDkD
zxHXLzJ5eusWplzHKqZyxNpzaR8CIQC3UtMu0QsXoUpYL016iTsbd7Eedi8IfnwQ zxHXLzJ5eusWplzHKqZyxNpzaR8CIQC3UtMu0QsXoUpYL016iTsbd7Eedi8IfnwQ
akExfhh0ew== akExfhh0ew==
-----END CMS----- -----END CMS-----
file: examples/parboiled_vr_00_D0-E5-02-00-2D.pkcs
The ASN1 decoding of the artifact: The ASN1 decoding of the artifact:
0:d=0 hl=4 l=3987 cons: SEQUENCE file: examples/parboiled_vr_00_D0-E5-02-00-2D.pkcs
4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData
15:d=1 hl=4 l=3972 cons: cont [ 0 ] 0:d=0 hl=4 l=3987 cons: SEQUENCE
19:d=2 hl=4 l=3968 cons: SEQUENCE 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData
23:d=3 hl=2 l= 1 prim: INTEGER :01 15:d=1 hl=4 l=3972 cons: cont [ 0 ]
26:d=3 hl=2 l= 13 cons: SET 19:d=2 hl=4 l=3968 cons: SEQUENCE
28:d=4 hl=2 l= 11 cons: SEQUENCE 23:d=3 hl=2 l= 1 prim: INTEGER :01
30:d=5 hl=2 l= 9 prim: OBJECT :sha256 26:d=3 hl=2 l= 13 cons: SET
41:d=3 hl=4 l=2516 cons: SEQUENCE 28:d=4 hl=2 l= 11 cons: SEQUENCE
45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 30:d=5 hl=2 l= 9 prim: OBJECT :sha256
56:d=4 hl=4 l=2501 cons: cont [ 0 ] 41:d=3 hl=4 l=2516 cons: SEQUENCE
60:d=5 hl=4 l=2497 prim: OCTET STRING :{"ietf-voucher-request:v 45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data
2561:d=3 hl=4 l=1090 cons: cont [ 0 ] 56:d=4 hl=4 l=2501 cons: cont [ 0 ]
2565:d=4 hl=4 l= 465 cons: SEQUENCE 60:d=5 hl=4 l=2497 prim: OCTET STRING :{"ietf-voucher-request:v
2569:d=5 hl=4 l= 342 cons: SEQUENCE 2561:d=3 hl=4 l=1090 cons: cont [ 0 ]
2573:d=6 hl=2 l= 3 cons: cont [ 0 ] 2565:d=4 hl=4 l= 465 cons: SEQUENCE
2575:d=7 hl=2 l= 1 prim: INTEGER :02 2569:d=5 hl=4 l= 342 cons: SEQUENCE
2578:d=6 hl=2 l= 1 prim: INTEGER :02 2573:d=6 hl=2 l= 3 cons: cont [ 0 ]
2581:d=6 hl=2 l= 10 cons: SEQUENCE 2575:d=7 hl=2 l= 1 prim: INTEGER :02
2583:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA384 2578:d=6 hl=2 l= 1 prim: INTEGER :02
2593:d=6 hl=2 l= 113 cons: SEQUENCE 2581:d=6 hl=2 l= 10 cons: SEQUENCE
2595:d=7 hl=2 l= 18 cons: SET 2583:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA384
2597:d=8 hl=2 l= 16 cons: SEQUENCE 2593:d=6 hl=2 l= 113 cons: SEQUENCE
2599:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 2595:d=7 hl=2 l= 18 cons: SET
2611:d=9 hl=2 l= 2 prim: IA5STRING :ca 2597:d=8 hl=2 l= 16 cons: SEQUENCE
2615:d=7 hl=2 l= 25 cons: SET 2599:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
2617:d=8 hl=2 l= 23 cons: SEQUENCE 2611:d=9 hl=2 l= 2 prim: IA5STRING :ca
2619:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 2615:d=7 hl=2 l= 25 cons: SET
2631:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 2617:d=8 hl=2 l= 23 cons: SEQUENCE
2642:d=7 hl=2 l= 64 cons: SET 2619:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
2644:d=8 hl=2 l= 62 cons: SEQUENCE 2631:d=9 hl=2 l= 9 prim: IA5STRING :sandelman
2646:d=9 hl=2 l= 3 prim: OBJECT :commonName 2642:d=7 hl=2 l= 64 cons: SET
2651:d=9 hl=2 l= 55 prim: UTF8STRING :#<SystemVariable:0x00000 2644:d=8 hl=2 l= 62 cons: SEQUENCE
2708:d=6 hl=2 l= 30 cons: SEQUENCE 2646:d=9 hl=2 l= 3 prim: OBJECT :commonName
2710:d=7 hl=2 l= 13 prim: UTCTIME :171107234528Z 2651:d=9 hl=2 l= 55 prim: UTF8STRING :#<SystemVariable:0x00000
2725:d=7 hl=2 l= 13 prim: UTCTIME :191107234528Z 2708:d=6 hl=2 l= 30 cons: SEQUENCE
2740:d=6 hl=2 l= 67 cons: SEQUENCE 2710:d=7 hl=2 l= 13 prim: UTCTIME :171107234528Z
2742:d=7 hl=2 l= 18 cons: SET 2725:d=7 hl=2 l= 13 prim: UTCTIME :191107234528Z
2744:d=8 hl=2 l= 16 cons: SEQUENCE 2740:d=6 hl=2 l= 67 cons: SEQUENCE
2746:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 2742:d=7 hl=2 l= 18 cons: SET
2758:d=9 hl=2 l= 2 prim: IA5STRING :ca 2744:d=8 hl=2 l= 16 cons: SEQUENCE
2762:d=7 hl=2 l= 25 cons: SET 2746:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
2764:d=8 hl=2 l= 23 cons: SEQUENCE 2758:d=9 hl=2 l= 2 prim: IA5STRING :ca
2766:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 2762:d=7 hl=2 l= 25 cons: SET
2778:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 2764:d=8 hl=2 l= 23 cons: SEQUENCE
2789:d=7 hl=2 l= 18 cons: SET 2766:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
2791:d=8 hl=2 l= 16 cons: SEQUENCE 2778:d=9 hl=2 l= 9 prim: IA5STRING :sandelman
2793:d=9 hl=2 l= 3 prim: OBJECT :commonName 2789:d=7 hl=2 l= 18 cons: SET
2798:d=9 hl=2 l= 9 prim: UTF8STRING :localhost 2791:d=8 hl=2 l= 16 cons: SEQUENCE
2809:d=6 hl=2 l= 89 cons: SEQUENCE 2793:d=9 hl=2 l= 3 prim: OBJECT :commonName
2811:d=7 hl=2 l= 19 cons: SEQUENCE 2798:d=9 hl=2 l= 9 prim: UTF8STRING :localhost
2813:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 2809:d=6 hl=2 l= 89 cons: SEQUENCE
2822:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 2811:d=7 hl=2 l= 19 cons: SEQUENCE
2832:d=7 hl=2 l= 66 prim: BIT STRING 2813:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey
2900:d=6 hl=2 l= 13 cons: cont [ 3 ] 2822:d=8 hl=2 l= 8 prim: OBJECT :prime256v1
2902:d=7 hl=2 l= 11 cons: SEQUENCE 2832:d=7 hl=2 l= 66 prim: BIT STRING
2904:d=8 hl=2 l= 9 cons: SEQUENCE 2900:d=6 hl=2 l= 13 cons: cont [ 3 ]
2906:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 2902:d=7 hl=2 l= 11 cons: SEQUENCE
2911:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000 2904:d=8 hl=2 l= 9 cons: SEQUENCE
2915:d=5 hl=2 l= 10 cons: SEQUENCE 2906:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints
2917:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA384 2911:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000
2927:d=5 hl=2 l= 105 prim: BIT STRING 2915:d=5 hl=2 l= 10 cons: SEQUENCE
3034:d=4 hl=4 l= 617 cons: SEQUENCE 2917:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA384
3038:d=5 hl=4 l= 495 cons: SEQUENCE 2927:d=5 hl=2 l= 105 prim: BIT STRING
3042:d=6 hl=2 l= 3 cons: cont [ 0 ] 3034:d=4 hl=4 l= 617 cons: SEQUENCE
3044:d=7 hl=2 l= 1 prim: INTEGER :02 3038:d=5 hl=4 l= 495 cons: SEQUENCE
3047:d=6 hl=2 l= 1 prim: INTEGER :03 3042:d=6 hl=2 l= 3 cons: cont [ 0 ]
3050:d=6 hl=2 l= 10 cons: SEQUENCE 3044:d=7 hl=2 l= 1 prim: INTEGER :02
3052:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 3047:d=6 hl=2 l= 1 prim: INTEGER :03
3062:d=6 hl=2 l= 109 cons: SEQUENCE 3050:d=6 hl=2 l= 10 cons: SEQUENCE
3064:d=7 hl=2 l= 18 cons: SET 3052:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
3066:d=8 hl=2 l= 16 cons: SEQUENCE 3062:d=6 hl=2 l= 109 cons: SEQUENCE
3068:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3064:d=7 hl=2 l= 18 cons: SET
3080:d=9 hl=2 l= 2 prim: IA5STRING :ca 3066:d=8 hl=2 l= 16 cons: SEQUENCE
3084:d=7 hl=2 l= 25 cons: SET 3068:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
3086:d=8 hl=2 l= 23 cons: SEQUENCE 3080:d=9 hl=2 l= 2 prim: IA5STRING :ca
3088:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3084:d=7 hl=2 l= 25 cons: SET
3100:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3086:d=8 hl=2 l= 23 cons: SEQUENCE
3111:d=7 hl=2 l= 60 cons: SET 3088:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
3113:d=8 hl=2 l= 58 cons: SEQUENCE 3100:d=9 hl=2 l= 9 prim: IA5STRING :sandelman
3115:d=9 hl=2 l= 3 prim: OBJECT :commonName 3111:d=7 hl=2 l= 60 cons: SET
3120:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co 3113:d=8 hl=2 l= 58 cons: SEQUENCE
3173:d=6 hl=2 l= 30 cons: SEQUENCE 3115:d=9 hl=2 l= 3 prim: OBJECT :commonName
3175:d=7 hl=2 l= 13 prim: UTCTIME :190113225444Z 3120:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co
3190:d=7 hl=2 l= 13 prim: UTCTIME :210112225444Z 3173:d=6 hl=2 l= 30 cons: SEQUENCE
3205:d=6 hl=2 l= 109 cons: SEQUENCE 3175:d=7 hl=2 l= 13 prim: UTCTIME :190113225444Z
3207:d=7 hl=2 l= 18 cons: SET 3190:d=7 hl=2 l= 13 prim: UTCTIME :210112225444Z
3209:d=8 hl=2 l= 16 cons: SEQUENCE 3205:d=6 hl=2 l= 109 cons: SEQUENCE
3211:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3207:d=7 hl=2 l= 18 cons: SET
3223:d=9 hl=2 l= 2 prim: IA5STRING :ca 3209:d=8 hl=2 l= 16 cons: SEQUENCE
3227:d=7 hl=2 l= 25 cons: SET 3211:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
3229:d=8 hl=2 l= 23 cons: SEQUENCE 3223:d=9 hl=2 l= 2 prim: IA5STRING :ca
3231:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3227:d=7 hl=2 l= 25 cons: SET
3243:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3229:d=8 hl=2 l= 23 cons: SEQUENCE
3254:d=7 hl=2 l= 60 cons: SET 3231:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
3256:d=8 hl=2 l= 58 cons: SEQUENCE 3243:d=9 hl=2 l= 9 prim: IA5STRING :sandelman
3258:d=9 hl=2 l= 3 prim: OBJECT :commonName 3254:d=7 hl=2 l= 60 cons: SET
3263:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co 3256:d=8 hl=2 l= 58 cons: SEQUENCE
3316:d=6 hl=2 l= 118 cons: SEQUENCE 3258:d=9 hl=2 l= 3 prim: OBJECT :commonName
3318:d=7 hl=2 l= 16 cons: SEQUENCE 3263:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co
3320:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 3316:d=6 hl=2 l= 118 cons: SEQUENCE
3329:d=8 hl=2 l= 5 prim: OBJECT :secp384r1 3318:d=7 hl=2 l= 16 cons: SEQUENCE
3336:d=7 hl=2 l= 98 prim: BIT STRING 3320:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey
3436:d=6 hl=2 l= 99 cons: cont [ 3 ] 3329:d=8 hl=2 l= 5 prim: OBJECT :secp384r1
3438:d=7 hl=2 l= 97 cons: SEQUENCE 3336:d=7 hl=2 l= 98 prim: BIT STRING
3440:d=8 hl=2 l= 15 cons: SEQUENCE 3436:d=6 hl=2 l= 99 cons: cont [ 3 ]
3442:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 3438:d=7 hl=2 l= 97 cons: SEQUENCE
3447:d=9 hl=2 l= 1 prim: BOOLEAN :255 3440:d=8 hl=2 l= 15 cons: SEQUENCE
3450:d=9 hl=2 l= 5 prim: OCTET STRING [HEX DUMP]:30030101FF 3442:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints
3457:d=8 hl=2 l= 14 cons: SEQUENCE 3447:d=9 hl=2 l= 1 prim: BOOLEAN :255
3459:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage 3450:d=9 hl=2 l= 5 prim: OCTET STRING [HEX DUMP]:30030101FF
3464:d=9 hl=2 l= 1 prim: BOOLEAN :255 3457:d=8 hl=2 l= 14 cons: SEQUENCE
3467:d=9 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:03020106 3459:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage
3473:d=8 hl=2 l= 29 cons: SEQUENCE 3464:d=9 hl=2 l= 1 prim: BOOLEAN :255
3475:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Ident 3467:d=9 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:03020106
3480:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:0414B9A5F6CB11 3473:d=8 hl=2 l= 29 cons: SEQUENCE
3504:d=8 hl=2 l= 31 cons: SEQUENCE 3475:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Ident
3506:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Authority Key Ide 3480:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:0414B9A5F6CB11
3511:d=9 hl=2 l= 24 prim: OCTET STRING [HEX DUMP]:30168014B9A5F6 3504:d=8 hl=2 l= 31 cons: SEQUENCE
3537:d=5 hl=2 l= 10 cons: SEQUENCE 3506:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Authority Key Ide
3539:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 3511:d=9 hl=2 l= 24 prim: OCTET STRING [HEX DUMP]:30168014B9A5F6
3549:d=5 hl=2 l= 104 prim: BIT STRING 3537:d=5 hl=2 l= 10 cons: SEQUENCE
3655:d=3 hl=4 l= 332 cons: SET 3539:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
3659:d=4 hl=4 l= 328 cons: SEQUENCE 3549:d=5 hl=2 l= 104 prim: BIT STRING
3663:d=5 hl=2 l= 1 prim: INTEGER :01 3655:d=3 hl=4 l= 332 cons: SET
3666:d=5 hl=2 l= 118 cons: SEQUENCE 3659:d=4 hl=4 l= 328 cons: SEQUENCE
3668:d=6 hl=2 l= 113 cons: SEQUENCE 3663:d=5 hl=2 l= 1 prim: INTEGER :01
3670:d=7 hl=2 l= 18 cons: SET 3666:d=5 hl=2 l= 118 cons: SEQUENCE
3672:d=8 hl=2 l= 16 cons: SEQUENCE 3668:d=6 hl=2 l= 113 cons: SEQUENCE
3674:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3670:d=7 hl=2 l= 18 cons: SET
3686:d=9 hl=2 l= 2 prim: IA5STRING :ca 3672:d=8 hl=2 l= 16 cons: SEQUENCE
3690:d=7 hl=2 l= 25 cons: SET 3674:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
3692:d=8 hl=2 l= 23 cons: SEQUENCE 3686:d=9 hl=2 l= 2 prim: IA5STRING :ca
3694:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3690:d=7 hl=2 l= 25 cons: SET
3706:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3692:d=8 hl=2 l= 23 cons: SEQUENCE
3717:d=7 hl=2 l= 64 cons: SET 3694:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
3719:d=8 hl=2 l= 62 cons: SEQUENCE 3706:d=9 hl=2 l= 9 prim: IA5STRING :sandelman
3721:d=9 hl=2 l= 3 prim: OBJECT :commonName 3717:d=7 hl=2 l= 64 cons: SET
3726:d=9 hl=2 l= 55 prim: UTF8STRING :#<SystemVariable:0x00000 3719:d=8 hl=2 l= 62 cons: SEQUENCE
3783:d=6 hl=2 l= 1 prim: INTEGER :02 3721:d=9 hl=2 l= 3 prim: OBJECT :commonName
3786:d=5 hl=2 l= 11 cons: SEQUENCE 3726:d=9 hl=2 l= 55 prim: UTF8STRING :#<SystemVariable:0x00000
3788:d=6 hl=2 l= 9 prim: OBJECT :sha256 3783:d=6 hl=2 l= 1 prim: INTEGER :02
3799:d=5 hl=2 l= 105 cons: cont [ 0 ] 3786:d=5 hl=2 l= 11 cons: SEQUENCE
3801:d=6 hl=2 l= 24 cons: SEQUENCE 3788:d=6 hl=2 l= 9 prim: OBJECT :sha256
3803:d=7 hl=2 l= 9 prim: OBJECT :contentType 3799:d=5 hl=2 l= 105 cons: cont [ 0 ]
3814:d=7 hl=2 l= 11 cons: SET 3801:d=6 hl=2 l= 24 cons: SEQUENCE
3816:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 3803:d=7 hl=2 l= 9 prim: OBJECT :contentType
3827:d=6 hl=2 l= 28 cons: SEQUENCE 3814:d=7 hl=2 l= 11 cons: SET
3829:d=7 hl=2 l= 9 prim: OBJECT :signingTime 3816:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data
3840:d=7 hl=2 l= 15 cons: SET 3827:d=6 hl=2 l= 28 cons: SEQUENCE
3842:d=8 hl=2 l= 13 prim: UTCTIME :190515212555Z 3829:d=7 hl=2 l= 9 prim: OBJECT :signingTime
3857:d=6 hl=2 l= 47 cons: SEQUENCE 3840:d=7 hl=2 l= 15 cons: SET
3859:d=7 hl=2 l= 9 prim: OBJECT :messageDigest 3842:d=8 hl=2 l= 13 prim: UTCTIME :190515212555Z
3870:d=7 hl=2 l= 34 cons: SET 3857:d=6 hl=2 l= 47 cons: SEQUENCE
3872:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:50508CC996CD93 3859:d=7 hl=2 l= 9 prim: OBJECT :messageDigest
3906:d=5 hl=2 l= 10 cons: SEQUENCE 3870:d=7 hl=2 l= 34 cons: SET
3908:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 3872:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:50508CC996CD93
3918:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:3045022006D85B 3906:d=5 hl=2 l= 10 cons: SEQUENCE
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
C.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
skipping to change at page 113, line 44 skipping to change at page 114, line 44
IWcspDPZGlOSDPm7nuRJSDkgWqevxLI4+9nmIhsfMBsDvz1DJhAxggFMMIIBSAIB IWcspDPZGlOSDPm7nuRJSDkgWqevxLI4+9nmIhsfMBsDvz1DJhAxggFMMIIBSAIB
ATBVME0xEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRl ATBVME0xEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRl
bG1hbjEcMBoGA1UEAwwTVW5zdHJ1bmcgSGlnaHdheSBDQQIEI8yJEzALBglghkgB bG1hbjEcMBoGA1UEAwwTVW5zdHJ1bmcgSGlnaHdheSBDQQIEI8yJEzALBglghkgB
ZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP ZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xOTA1MTYwMjUxNDJaMC8GCSqGSIb3DQEJBDEiBCCYRh4i21QjEjEk8leRLSVA Fw0xOTA1MTYwMjUxNDJaMC8GCSqGSIb3DQEJBDEiBCCYRh4i21QjEjEk8leRLSVA
x/EVY5g1bM40QM21oR4c2DAKBggqhkjOPQQDAgRoMGYCMQCYYOiSbIlED4nAN0iL x/EVY5g1bM40QM21oR4c2DAKBggqhkjOPQQDAgRoMGYCMQCYYOiSbIlED4nAN0iL
e4S8ixWAZ9SXpGv77bB/G4fTTVTN35mnAeYBfeNfhC6/kOECMQDqlkCmwQJQDdEL e4S8ixWAZ9SXpGv77bB/G4fTTVTN35mnAeYBfeNfhC6/kOECMQDqlkCmwQJQDdEL
asj1ISinJ/FnZjjgOMz9MXOmGNGIfw9v2VBb9mVyhsOSMcqlVig= asj1ISinJ/FnZjjgOMz9MXOmGNGIfw9v2VBb9mVyhsOSMcqlVig=
-----END CMS----- -----END CMS-----
file: examples/voucher_00-D0-E5-02-00-2D.pkcs
The ASN1 decoding of the artifact: The ASN1 decoding of the artifact:
0:d=0 hl=4 l=1714 cons: SEQUENCE file: examples/voucher_00-D0-E5-02-00-2D.pkcs
4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData
15:d=1 hl=4 l=1699 cons: cont [ 0 ] 0:d=0 hl=4 l=1714 cons: SEQUENCE
19:d=2 hl=4 l=1695 cons: SEQUENCE 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData
23:d=3 hl=2 l= 1 prim: INTEGER :01 15:d=1 hl=4 l=1699 cons: cont [ 0 ]
26:d=3 hl=2 l= 13 cons: SET 19:d=2 hl=4 l=1695 cons: SEQUENCE
28:d=4 hl=2 l= 11 cons: SEQUENCE 23:d=3 hl=2 l= 1 prim: INTEGER :01
30:d=5 hl=2 l= 9 prim: OBJECT :sha256 26:d=3 hl=2 l= 13 cons: SET
41:d=3 hl=4 l= 832 cons: SEQUENCE 28:d=4 hl=2 l= 11 cons: SEQUENCE
45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 30:d=5 hl=2 l= 9 prim: OBJECT :sha256
56:d=4 hl=4 l= 817 cons: cont [ 0 ] 41:d=3 hl=4 l= 832 cons: SEQUENCE
60:d=5 hl=4 l= 813 prim: OCTET STRING :{"ietf-voucher:voucher": 45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data
877:d=3 hl=4 l= 501 cons: cont [ 0 ] 56:d=4 hl=4 l= 817 cons: cont [ 0 ]
881:d=4 hl=4 l= 497 cons: SEQUENCE 60:d=5 hl=4 l= 813 prim: OCTET STRING :{"ietf-voucher:voucher":
885:d=5 hl=4 l= 376 cons: SEQUENCE 877:d=3 hl=4 l= 501 cons: cont [ 0 ]
889:d=6 hl=2 l= 3 cons: cont [ 0 ] 881:d=4 hl=4 l= 497 cons: SEQUENCE
891:d=7 hl=2 l= 1 prim: INTEGER :02 885:d=5 hl=4 l= 376 cons: SEQUENCE
894:d=6 hl=2 l= 4 prim: INTEGER :23CC8913 889:d=6 hl=2 l= 3 cons: cont [ 0 ]
900:d=6 hl=2 l= 10 cons: SEQUENCE 891:d=7 hl=2 l= 1 prim: INTEGER :02
902:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 894:d=6 hl=2 l= 4 prim: INTEGER :23CC8913
912:d=6 hl=2 l= 77 cons: SEQUENCE 900:d=6 hl=2 l= 10 cons: SEQUENCE
914:d=7 hl=2 l= 18 cons: SET 902:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
916:d=8 hl=2 l= 16 cons: SEQUENCE 912:d=6 hl=2 l= 77 cons: SEQUENCE
918:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 914:d=7 hl=2 l= 18 cons: SET
930:d=9 hl=2 l= 2 prim: IA5STRING :ca 916:d=8 hl=2 l= 16 cons: SEQUENCE
934:d=7 hl=2 l= 25 cons: SET 918:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
936:d=8 hl=2 l= 23 cons: SEQUENCE 930:d=9 hl=2 l= 2 prim: IA5STRING :ca
938:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 934:d=7 hl=2 l= 25 cons: SET
950:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 936:d=8 hl=2 l= 23 cons: SEQUENCE
961:d=7 hl=2 l= 28 cons: SET 938:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
963:d=8 hl=2 l= 26 cons: SEQUENCE 950:d=9 hl=2 l= 9 prim: IA5STRING :sandelman
965:d=9 hl=2 l= 3 prim: OBJECT :commonName 961:d=7 hl=2 l= 28 cons: SET
970:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Highway CA 963:d=8 hl=2 l= 26 cons: SEQUENCE
991:d=6 hl=2 l= 30 cons: SEQUENCE 965:d=9 hl=2 l= 3 prim: OBJECT :commonName
993:d=7 hl=2 l= 13 prim: UTCTIME :190423232107Z 970:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Highway CA
1008:d=7 hl=2 l= 13 prim: UTCTIME :190524092107Z 991:d=6 hl=2 l= 30 cons: SEQUENCE
1023:d=6 hl=2 l= 102 cons: SEQUENCE 993:d=7 hl=2 l= 13 prim: UTCTIME :190423232107Z
1025:d=7 hl=2 l= 15 cons: SET 1008:d=7 hl=2 l= 13 prim: UTCTIME :190524092107Z
1027:d=8 hl=2 l= 13 cons: SEQUENCE 1023:d=6 hl=2 l= 102 cons: SEQUENCE
1029:d=9 hl=2 l= 3 prim: OBJECT :countryName 1025:d=7 hl=2 l= 15 cons: SET
1034:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Canada 1027:d=8 hl=2 l= 13 cons: SEQUENCE
1042:d=7 hl=2 l= 18 cons: SET 1029:d=9 hl=2 l= 3 prim: OBJECT :countryName
1044:d=8 hl=2 l= 16 cons: SEQUENCE 1034:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Canada
1046:d=9 hl=2 l= 3 prim: OBJECT :organizationName 1042:d=7 hl=2 l= 18 cons: SET
1051:d=9 hl=2 l= 9 prim: UTF8STRING :Sandelman 1044:d=8 hl=2 l= 16 cons: SEQUENCE
1062:d=7 hl=2 l= 19 cons: SET 1046:d=9 hl=2 l= 3 prim: OBJECT :organizationName
1064:d=8 hl=2 l= 17 cons: SEQUENCE 1051:d=9 hl=2 l= 9 prim: UTF8STRING :Sandelman
1066:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName 1062:d=7 hl=2 l= 19 cons: SET
1071:d=9 hl=2 l= 10 prim: UTF8STRING :honeydukes 1064:d=8 hl=2 l= 17 cons: SEQUENCE
1083:d=7 hl=2 l= 42 cons: SET 1066:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName
1085:d=8 hl=2 l= 40 cons: SEQUENCE 1071:d=9 hl=2 l= 10 prim: UTF8STRING :honeydukes
1087:d=9 hl=2 l= 3 prim: OBJECT :commonName 1083:d=7 hl=2 l= 42 cons: SET
1092:d=9 hl=2 l= 33 prim: UTF8STRING :masa.honeydukes.sandelma 1085:d=8 hl=2 l= 40 cons: SEQUENCE
1127:d=6 hl=2 l= 118 cons: SEQUENCE 1087:d=9 hl=2 l= 3 prim: OBJECT :commonName
1129:d=7 hl=2 l= 16 cons: SEQUENCE 1092:d=9 hl=2 l= 33 prim: UTF8STRING :masa.honeydukes.sandelma
1131:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 1127:d=6 hl=2 l= 118 cons: SEQUENCE
1140:d=8 hl=2 l= 5 prim: OBJECT :secp384r1 1129:d=7 hl=2 l= 16 cons: SEQUENCE
1147:d=7 hl=2 l= 98 prim: BIT STRING 1131:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey
1247:d=6 hl=2 l= 16 cons: cont [ 3 ] 1140:d=8 hl=2 l= 5 prim: OBJECT :secp384r1
1249:d=7 hl=2 l= 14 cons: SEQUENCE 1147:d=7 hl=2 l= 98 prim: BIT STRING
1251:d=8 hl=2 l= 12 cons: SEQUENCE 1247:d=6 hl=2 l= 16 cons: cont [ 3 ]
1253:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 1249:d=7 hl=2 l= 14 cons: SEQUENCE
1258:d=9 hl=2 l= 1 prim: BOOLEAN :255 1251:d=8 hl=2 l= 12 cons: SEQUENCE
1261:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000 1253:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints
1265:d=5 hl=2 l= 10 cons: SEQUENCE 1258:d=9 hl=2 l= 1 prim: BOOLEAN :255
1267:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 1261:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000
1277:d=5 hl=2 l= 103 prim: BIT STRING 1265:d=5 hl=2 l= 10 cons: SEQUENCE
1382:d=3 hl=4 l= 332 cons: SET 1267:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
1386:d=4 hl=4 l= 328 cons: SEQUENCE 1277:d=5 hl=2 l= 103 prim: BIT STRING
1390:d=5 hl=2 l= 1 prim: INTEGER :01 1382:d=3 hl=4 l= 332 cons: SET
1393:d=5 hl=2 l= 85 cons: SEQUENCE 1386:d=4 hl=4 l= 328 cons: SEQUENCE
1395:d=6 hl=2 l= 77 cons: SEQUENCE 1390:d=5 hl=2 l= 1 prim: INTEGER :01
1397:d=7 hl=2 l= 18 cons: SET 1393:d=5 hl=2 l= 85 cons: SEQUENCE
1399:d=8 hl=2 l= 16 cons: SEQUENCE 1395:d=6 hl=2 l= 77 cons: SEQUENCE
1401:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 1397:d=7 hl=2 l= 18 cons: SET
1413:d=9 hl=2 l= 2 prim: IA5STRING :ca 1399:d=8 hl=2 l= 16 cons: SEQUENCE
1417:d=7 hl=2 l= 25 cons: SET 1401:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
1419:d=8 hl=2 l= 23 cons: SEQUENCE 1413:d=9 hl=2 l= 2 prim: IA5STRING :ca
1421:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 1417:d=7 hl=2 l= 25 cons: SET
1433:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 1419:d=8 hl=2 l= 23 cons: SEQUENCE
1444:d=7 hl=2 l= 28 cons: SET 1421:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
1446:d=8 hl=2 l= 26 cons: SEQUENCE 1433:d=9 hl=2 l= 9 prim: IA5STRING :sandelman
1448:d=9 hl=2 l= 3 prim: OBJECT :commonName 1444:d=7 hl=2 l= 28 cons: SET
1453:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Highway CA 1446:d=8 hl=2 l= 26 cons: SEQUENCE
1474:d=6 hl=2 l= 4 prim: INTEGER :23CC8913 1448:d=9 hl=2 l= 3 prim: OBJECT :commonName
1480:d=5 hl=2 l= 11 cons: SEQUENCE 1453:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Highway CA
1482:d=6 hl=2 l= 9 prim: OBJECT :sha256 1474:d=6 hl=2 l= 4 prim: INTEGER :23CC8913
1493:d=5 hl=2 l= 105 cons: cont [ 0 ] 1480:d=5 hl=2 l= 11 cons: SEQUENCE
1495:d=6 hl=2 l= 24 cons: SEQUENCE 1482:d=6 hl=2 l= 9 prim: OBJECT :sha256
1497:d=7 hl=2 l= 9 prim: OBJECT :contentType 1493:d=5 hl=2 l= 105 cons: cont [ 0 ]
1508:d=7 hl=2 l= 11 cons: SET 1495:d=6 hl=2 l= 24 cons: SEQUENCE
1510:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 1497:d=7 hl=2 l= 9 prim: OBJECT :contentType
1521:d=6 hl=2 l= 28 cons: SEQUENCE 1508:d=7 hl=2 l= 11 cons: SET
1523:d=7 hl=2 l= 9 prim: OBJECT :signingTime 1510:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data
1534:d=7 hl=2 l= 15 cons: SET 1521:d=6 hl=2 l= 28 cons: SEQUENCE
1536:d=8 hl=2 l= 13 prim: UTCTIME :190516025142Z 1523:d=7 hl=2 l= 9 prim: OBJECT :signingTime
1551:d=6 hl=2 l= 47 cons: SEQUENCE 1534:d=7 hl=2 l= 15 cons: SET
1553:d=7 hl=2 l= 9 prim: OBJECT :messageDigest 1536:d=8 hl=2 l= 13 prim: UTCTIME :190516025142Z
1564:d=7 hl=2 l= 34 cons: SET 1551:d=6 hl=2 l= 47 cons: SEQUENCE
1566:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:98461E22DB5423 1553:d=7 hl=2 l= 9 prim: OBJECT :messageDigest
1600:d=5 hl=2 l= 10 cons: SEQUENCE 1564:d=7 hl=2 l= 34 cons: SET
1602:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 1566:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:98461E22DB5423
1612:d=5 hl=2 l= 104 prim: OCTET STRING [HEX DUMP]:30660231009860 1600:d=5 hl=2 l= 10 cons: SEQUENCE
1602:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
1612:d=5 hl=2 l= 104 prim: OCTET STRING [HEX DUMP]:30660231009860
Authors' Addresses Authors' Addresses
Max Pritikin Max Pritikin
Cisco Cisco
Email: pritikin@cisco.com Email: pritikin@cisco.com
Michael C. Richardson Michael C. Richardson
Sandelman Software Works Sandelman Software Works
Email: mcr+ietf@sandelman.ca Email: mcr+ietf@sandelman.ca
URI: http://www.sandelman.ca/ URI: http://www.sandelman.ca/
Toerless Eckert Toerless Eckert
Futurewei Technologies Inc. USA Futurewei Technologies Inc. USA
2330 Central Expy 2330 Central Expy
Santa Clara 95050 Santa Clara, 95050
USA United States of America
Email: tte+ietf@cs.fau.de Email: tte+ietf@cs.fau.de
Michael H. Behringer Michael H. Behringer
Email: Michael.H.Behringer@gmail.com Email: Michael.H.Behringer@gmail.com
Kent Watsen Kent Watsen
Watsen Networks Watsen Networks
 End of changes. 149 change blocks. 
756 lines changed or deleted 784 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/