idnits 2.17.1
draft-ietf-anima-voucher-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 452 has weird spacing: '...-reason enu...'
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords -- however, there's a paragraph with
a matching beginning. Boilerplate error?
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document date (January 4, 2017) is 2668 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
No issues found here.
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 ANIMA Working Group K. Watsen
3 Internet-Draft Juniper Networks
4 Intended status: Standards Track M. Richardson
5 Expires: July 8, 2017 SSW
6 M. Pritikin
7 Cisco Systems
8 T. Eckert
9 January 4, 2017
11 Voucher and Voucher Revocation Profiles for Bootstrapping Protocols
12 draft-ietf-anima-voucher-00
14 Abstract
16 This memo defines the two artifacts "voucher" and "voucher-
17 revocation", which are YANG-defined structures that have been signed
18 by a TBD algorithm.
20 The voucher artifact is generated by the device's manufacture or
21 delegate. The voucher's purpose is to securely assign one or more
22 devices to an owner. The voucher informs each device which entity it
23 should consider to be its owner.
25 The voucher revocation artifact is used by the manufacturer or
26 delegate (i.e. the issuer of the voucher) to revoke vouchers, if
27 ever necessary. The voucher revocation format defined herein
28 supports both issuer-wide and voucher-specific constructs, enabling
29 usage flexibility.
31 For both artifacts, this memo only defines the artifact, leaving it
32 to future work to describe specialized protocols for accessing them.
34 Status of This Memo
36 This Internet-Draft is submitted in full conformance with the
37 provisions of BCP 78 and BCP 79.
39 Internet-Drafts are working documents of the Internet Engineering
40 Task Force (IETF). Note that other groups may also distribute
41 working documents as Internet-Drafts. The list of current Internet-
42 Drafts is at http://datatracker.ietf.org/drafts/current/.
44 Internet-Drafts are draft documents valid for a maximum of six months
45 and may be updated, replaced, or obsoleted by other documents at any
46 time. It is inappropriate to use Internet-Drafts as reference
47 material or to cite them other than as "work in progress."
48 This Internet-Draft will expire on July 8, 2017.
50 Copyright Notice
52 Copyright (c) 2017 IETF Trust and the persons identified as the
53 document authors. All rights reserved.
55 This document is subject to BCP 78 and the IETF Trust's Legal
56 Provisions Relating to IETF Documents
57 (http://trustee.ietf.org/license-info) in effect on the date of
58 publication of this document. Please review these documents
59 carefully, as they describe your rights and restrictions with respect
60 to this document. Code Components extracted from this document must
61 include Simplified BSD License text as described in Section 4.e of
62 the Trust Legal Provisions and are provided without warranty as
63 described in the Simplified BSD License.
65 Table of Contents
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
68 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
69 3. Tree Diagram Notation . . . . . . . . . . . . . . . . . . . . 3
70 4. Voucher . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
71 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4
72 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4
73 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 5
74 5. Voucher Revocation . . . . . . . . . . . . . . . . . . . . . 9
75 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 9
76 5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
77 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 11
78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
79 6.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 16
80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
81 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 16
82 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 17
83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
85 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
86 9.2. Informative References . . . . . . . . . . . . . . . . . 18
87 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19
88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
90 1. Introduction
92 This document defines a strategy to securely assign devices to an
93 owner, using an artifact signed, directly or indirectly, by the
94 device's manufacturer. This artifact is known as the voucher.
96 A voucher may be useful in several contexts, but the driving
97 motivation herein is to support secure bootstrapping mechanisms, such
98 as are defined in [draft-ietf-netconf-zerotouch] and
99 [draft-ietf-anima-bootstrapping-keyinfra]. Assigning ownership is
100 important to bootstrapping mechanisms so that the booting device can
101 authenticate the network that's trying to take control of it.
103 The lifetimes of vouchers may vary. In some bootstrapping protocols
104 the vouchers may be ephemeral, whereas in others the vouchers may be
105 potentially long-lived. In order to support the second category of
106 vouchers, this document also defines a voucher revocation artifact,
107 enabling the manufacturer or delegate to communicate the validity of
108 its vouchers.
110 For both artifacts, this memo only defines the artifact, leaving it
111 to future work to describe specialized protocols for accessing them.
113 This document uses YANG [RFC7950] to define the voucher and voucher
114 revocation formats. YANG is a data modeling language with
115 established mappings to XML and JSON, with mappings to other
116 encodings in progress. Which encodings a particular solution uses is
117 outside the scope of this document.
119 2. Requirements Language
121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the
123 sections below are to be interpreted as described in RFC 2119
124 [RFC2119].
126 3. Tree Diagram Notation
128 The meaning of the symbols in the above diagram is as follows:
130 o Brackets "[" and "]" enclose list keys.
132 o Braces "{" and "}" enclose feature names, and indicate that the
133 named feature must be present for the subtree to be present.
135 o Abbreviations before data node names: "rw" (read-write) represents
136 configuration data and "ro" (read-only) represents state data.
138 o Symbols after data node names: "?" means an optional node, "!"
139 means a presence container, and "*" denotes a list and leaf-list.
141 o Parentheses enclose choice and case nodes, and case nodes are also
142 marked with a colon (":").
144 o Ellipsis ("...") stands for contents of subtrees that are not
145 shown.
147 4. Voucher
149 The voucher is generated by the device's manufacture or delegate.
150 The voucher's purpose is to securely assign one or more devices to an
151 owner. The voucher informs each device which entity it should
152 consider to be its owner.
154 The voucher is signed by the device's manufacturer or delegate.
155 NOTE: AT THIS TIME, THE SIGNING STRATEGY HAS NOT BEEN SELECTED.
157 4.1. Tree Diagram
159 Following is the tree diagram for the YANG module specified in
160 Section 4.3. Details regarding each node in the tree diagram are
161 provided in the YANG module. Please see Section 3 for information on
162 tree diagram notation.
164 module: ietf-voucher
165 +--ro voucher
166 +--ro assertion enumeration
167 +--ro trusted-ca-certificate? binary
168 +--ro certificate-id
169 | +--ro cn-id? string
170 | +--ro dns-id? string
171 +--ro unique-id* string
172 +--ro nonce? string
173 +--ro created-on? yang:date-and-time
174 +--ro expires-on? yang:date-and-time
175 +--ro revocation-location? inet:uri
176 +--ro additional-data?
178 4.2. Examples
180 The following illustrates an ephemeral voucher encoded in JSON:
182 {
183 "ietf-voucher:voucher": {
184 "assertion": "logged",
185 "trusted-ca-certificate": "base64-encoded X.509 DER",
186 "owner-id": "Registrar3245",
187 "unique-id": "JADA123456789",
188 "created-on": "2016-10-07T19:31:42Z",
189 "nonce": "987987623489567"
190 }
191 }
192 The following illustrates a long-lived voucher encoded in XML:
194
196 verified
197
198 base64-encoded X.509 DER
199
200
201 Example Inc.
202 example.com
203
204 AAA123456789
205 BBB123456789
206 CCC123456789
207 2016-10-07T19:31:42Z
208
210 4.3. YANG Module
212 file "ietf-voucher@2017-01-04.yang"
214 module ietf-voucher {
215 yang-version 1.1;
217 namespace
218 "urn:ietf:params:xml:ns:yang:ietf-voucher";
219 prefix "vch";
221 import ietf-yang-types { prefix yang; }
222 import ietf-inet-types { prefix inet; }
224 organization
225 "IETF ANIMA Working Group";
227 contact
228 "WG Web:
229 WG List:
230 Author: Kent Watsen
231
232 Author: Max Pritikin
233
234 Author: Michael Richardson
235 ";
237 description
238 "This module defines the format for a voucher, which is
239 produced by a device's manufacturer or delegate to securely
240 assign one or more devices to an 'owner', so that the
241 devices may establish a secure connection to the owner's
242 network infrastructure.";
244 revision "2017-01-04" {
245 description
246 "Initial version";
247 reference
248 "RFC XXXX: Voucher and Voucher Revocation Profiles
249 for Bootstrapping Protocols";
250 }
252 // top-level container
253 container voucher {
254 config false;
255 description
256 "A voucher that can be used to assign one or more devices to
257 an owner.";
259 leaf assertion {
260 type enumeration {
261 enum verified {
262 description
263 "Indicates that the ownership has been positively
264 verified by the device's manufacturer or delegate
265 (e.g., through sales channel integration).";
266 }
267 enum logged {
268 description
269 "Indicates that this ownership assignment has been
270 logged into a database maintained by the device's
271 manufacturer or delegate (voucher transparency).";
272 }
273 }
274 mandatory true;
275 description
276 "The assertion is a statement from the manufacturer or
277 delegate regarding the nature of this voucher. This
278 allows the device to know what assurance the manufacturer
279 provides, which supports more detailed policy checks
280 such as 'I only want to allow verified devices, not
281 just logged devices'.";
282 }
284 leaf trusted-ca-certificate {
285 type binary;
286 description
287 "An X.509 v3 certificate structure as specified by RFC 5280,
288 Section 4 encoded using the ASN.1 distinguished encoding
289 rules (DER), as specified in ITU-T X.690.
291 This certificate is used by a bootstrapping device to
292 trust another public key infrastructure, in order to
293 verify another certificate supplied to the device
294 separately by the bootstrapping protocol, the other
295 certificate must have this certificate somewhere in
296 its chain of certificates.";
298 reference
299 "RFC 5280:
300 Internet X.509 Public Key Infrastructure Certificate
301 and Certificate Revocation List (CRL) Profile.
302 ITU-T X.690:
303 Information technology - ASN.1 encoding rules:
304 Specification of Basic Encoding Rules (BER),
305 Canonical Encoding Rules (CER) and Distinguished
306 Encoding Rules (DER).";
307 }
309 container certificate-id {
310 description
311 "When provided, the device MUST also perform RFC 6125
312 style validation of another certificate supplied to
313 the device separately by the bootstrapping protocol
314 against all the provided ids.";
315 leaf cn-id {
316 type string;
317 description
318 "The common name field in the cetificate must match
319 this value.";
320 }
321 leaf dns-id {
322 type string;
323 description
324 "A subjectAltName entry of type dNSName in the
325 certificate must match this value.";
326 }
327 }
329 leaf-list unique-id {
330 type string;
331 min-elements 1;
332 description
333 "A regular expression identifying one more more device
334 unique identifiers (e.g., serial numbers). For instance,
335 the expression could match just a single serial number,
336 or it might match a range of serial numbers. Devices
337 use this value to determine if the voucher applies to
338 them.";
340 // Ed. both the zerotouch and brwski solutions are devid
341 // oriented, and so renaming this field to 'serial-number'
342 // wouldn't be crazy. But devid/serial-number (typically)
343 // assumes physical chassis, is it worth using this
344 // term which might extend to e.g. virtual appliances?
345 }
347 leaf nonce {
348 type string; // unit64?
349 description
350 "what can be said about this that's ANIMA-neutral?";
351 }
353 leaf created-on {
354 type yang:date-and-time;
355 description
356 "The date this voucher was created";
357 }
359 leaf expires-on {
360 type yang:date-and-time;
361 description
362 "An optional date value for when this voucher expires.";
363 }
365 leaf revocation-location {
366 type inet:uri;
367 description
368 "A URI indicating where revocation information may be
369 obtained.";
370 }
372 anydata additional-data {
373 description
374 "Additional data signed by the manufacturer. The manufacturer
375 might put additional data into its vouchers, for human or
376 device consumption.";
378 // Ed. is the additional data normative? - if so, should we
379 // remove this free-form field, and assume it will be formally
380 // extended later? Note: the zerotouch draft doesn't need this
381 // field...
382 }
383 }
385 }
387
389 5. Voucher Revocation
391 The vouchers revocation artifact is used to verify the revocation
392 status of vouchers. Voucher revocations are signed by the
393 manufacturer or delegate (i.e. the issuer of the voucher). Vouchers
394 revocation statements MAY be verified by devices during the
395 bootstrapping process, or at any time before or after by any entity
396 (e.g., registrar or equivalent) as needed. Registrars or equivalent
397 SHOULD verify voucher revocation statements and make policy decisions
398 in case devices are not doing so themselves.
400 Revocations are generally needed when it is critical for devices to
401 know that assurances implied at the time the voucher was signed are
402 still valid at the time the voucher is being processed.
404 As mentioned in Section 1, the lifetimes of vouchers may vary. In
405 some bootstrapping protocols the vouchers may be ephemeral, whereas
406 in others the vouchers may be potentially long-lived. For
407 bootstrapping protocols that support ephemeral vouchers, there is no
408 need to support revocations. For bootstrapping protocols that
409 support long-lived vouchers, the need to support revoking vouchers is
410 a decision for each manufacturer.
412 If revocations are not supported then voucher assignments are
413 essentially forever, which may be acceptable for various kinds of
414 devices. If revocations are supported, then it becomes possible to
415 support various scenarios such as handling a key compromise or change
416 in ownership.
418 The voucher revocation format defined herein supports both issuer-
419 wide (similar to a CRL) or voucher-specific (similar to an OCSP
420 response) constructs, enabling usage flexibility.
422 NOTE: AT THIS TIME, THE SIGNING STRATEGY HAS NOT BEEN SELECTED.
424 5.1. Tree Diagram
426 Following is the tree diagram for the YANG module specified in
427 Section 5.3. Details regarding each node in the tree diagram are
428 provided in the YANG module. Please see Section 3 for information on
429 tree diagram notation.
431 module: ietf-voucher-revocation
432 +--ro voucher-revocation
433 +--ro revocation-type enumeration
434 +--ro created-on yang:date-and-time
435 +--ro expires-on? yang:date-and-time
436 +--ro (voucher-revocation-type)?
437 | +--:(issuer-wide)
438 | | +--ro issuer-wide
439 | | +--ro (list-type)?
440 | | +--:(whitelist)
441 | | | +--ro whitelist
442 | | | +--ro voucher-identifier* string
443 | | +--:(blacklist)
444 | | +--ro blacklist
445 | | +--ro voucher-identifier* string
446 | +--:(voucher-specific)
447 | +--ro voucher-specific
448 | +--ro voucher-identifier string
449 | +--ro voucher-status enumeration
450 | +--ro revocation-information
451 | +--ro revoked-on yang:date-and-time
452 | +--ro revocation-reason enumeration
453 +--ro additional-data?
455 5.2. Examples
457 The following illustrates an issuer-wide voucher revocation in XML:
459
461 issuer-wide
462 2016-10-31T23:59:59Z
463 2016-12-31T23:59:59Z
464
465
466 some fingerprint
467 some fingerprint
468 some fingerprint
469
470
471
473 The following illustrates a voucher-specific revocation in JSON:
475 {
476 "ietf-voucher-revocation:voucher-revocation": {
477 "revocation-type": "voucher-specific",
478 "created-on": "2016-10-31T23:59:59Z"
479 "expires-on": "2016-12-31T23:59:59Z"
480 "voucher-specific": [
481 "voucher-identifier": "some fingerprint",
482 "voucher-status": "revoked",
483 "revocation-information": [
484 "revoked-on": "2016-11-31T23:59:59Z",
485 "revocation-reason": "key-compromise"
486 ]
487 ]
488 }
489 }
491 5.3. YANG Module
493 file "ietf-voucher-revocation@2017-01-04.yang"
495 module ietf-voucher-revocation {
496 yang-version 1.1;
498 namespace
499 "urn:ietf:params:xml:ns:yang:ietf-voucher-revocation";
500 prefix "vr";
502 import ietf-yang-types { prefix yang; }
504 organization
505 "IETF ANIMA Working Group";
507 contact
508 "WG Web:
509 WG List:
510 Author: Kent Watsen
511
512 Author: Max Pritikin
513
514 Author: Michael Richardson
515 ";
517 description
518 "This module defines the format for a voucher revocation,
519 which is produced by a manufacturer or delegate to indicate
520 the revocation status of vouchers.";
522 revision "2017-01-04" {
523 description
524 "Initial version";
525 reference
526 "RFC XXXX: Voucher and Voucher Revocation Profiles
527 for Bootstrapping Protocols";
528 }
530 // top-level container
531 container voucher-revocation {
532 config false;
533 description
534 "A voucher revocation that can provide revocation status
535 information for one or more devices.";
537 leaf revocation-type {
538 type enumeration {
539 enum issuer-wide {
540 description
541 "Indicates that this revocation spans all
542 the vouchers the issuer has issued to date";
543 }
544 enum voucher-specific {
545 description
546 "Indicated that this revocation only regards
547 a single voucher.";
548 }
549 }
550 mandatory true;
551 description
552 "The revocation-type indicates if the revocation
553 is issuer-wide or voucher-specific. Both variations
554 exist to enable implementations to choose between the
555 number of revocation artifacts generated versus
556 individual artifact size.";
557 }
559 leaf created-on {
560 type yang:date-and-time;
561 mandatory true;
562 description
563 "The date this voucher was created";
564 }
566 leaf expires-on {
567 type yang:date-and-time;
568 description
569 "An optional date value for when this voucher expires.";
570 }
571 choice voucher-revocation-type {
572 description
573 "Identifies the revocation type as being either issuer-wide
574 or voucher-specific.";
576 container issuer-wide {
577 description
578 "This revocation provides issuer-wide revocation status
579 (similar to a CRL).";
581 choice list-type {
582 description
583 "Indentifies if this issuer-wide revocation is provided
584 in the form of a whitelist or a blacklist";
586 container whitelist {
587 leaf-list voucher-identifier {
588 type string;
589 description
590 "A fingerprint over the voucher artifact.";
591 }
592 description
593 "Indicates that the listed of vouchers are known
594 to be good. If a voucher is not listed, then
595 it is considered revoked.";
596 }
598 container blacklist {
599 leaf-list voucher-identifier {
600 type string;
601 description
602 "A fingerprint over the voucher artifact.
603 Missing if list is empty.";
604 }
605 description
606 "Indicates that the list of vouchers have been
607 revoked. If a voucher is not listed, then it
608 is considered good.";
609 }
611 } // end list-type
613 } // end issuer-wide
615 container voucher-specific {
616 description
617 "This revocation provides voucher-specific revocation
618 status (similar to an OCSP response).";
620 leaf voucher-identifier {
621 type string;
622 mandatory true;
623 description
624 "A fingerprint over the voucher artifact.";
625 }
627 leaf voucher-status {
628 type enumeration {
629 enum good {
630 description
631 "Indicates that this voucher is valid";
632 }
633 enum revoked {
634 description
635 "Indicates that this voucher is invalid";
636 }
637 enum unknown {
638 description
639 "Indicates that the voucher's status is unknown";
640 }
641 }
642 mandatory true;
643 description
644 "Indicates if the revocation status for the specified
645 voucher.";
646 }
648 container revocation-information {
649 must "../voucher-status = 'revoked'";
651 leaf revoked-on {
652 type yang:date-and-time;
653 mandatory true;
654 description
655 "The date this voucher was revoked";
656 }
658 leaf revocation-reason {
659 type enumeration {
660 enum unspecified {
661 description
662 "Indicates that the reason the voucher
663 was revoked is unspecified.";
664 }
665 enum key-compromise {
666 description
667 "Indicates that the reason the voucher
668 was revoked is because its key was
669 compromised.";
670 }
671 enum issuer-compromise {
672 description
673 "Indicates that the reason the voucher
674 was revoked is because its issuer was
675 compromised.";
676 }
677 enum affiliation-changed {
678 description
679 "Indicates that the reason the voucher
680 was revoked is because its affiliation
681 changed (e.g., device assigned to a
682 new owner.";
683 }
684 enum superseded {
685 description
686 "Indicates that the reason the voucher
687 was revoked is because it has been
688 superseded (e.g., the previous voucher
689 expired.";
690 }
691 enum cessation-of-operation {
692 description
693 "Indicates that the reason the voucher
694 was revoked is because its issuer has
695 ceased operations.";
696 }
697 } // end enumeration
699 mandatory true;
700 description
701 "modeled after 'CRLReason' in RFC 5280.";
702 } // end revocation reason
704 description
705 "Provides details regarding why a voucher's revocation.
706 Modeled after 'ResponseData' in RFC6960.";
708 } // end revocation-information
710 } // end voucher-specific
711 }
713 anydata additional-data {
714 description
715 "Additional data signed by the manufacturer. The manufacturer
716 might put additional data into its voucher revocations, for
717 human or device consumption.";
719 // Ed. is the additional data normative? - if so, should we
720 // remove this free-form field, and assume it will be formally
721 // extended later? Note: the zerotouch draft doesn't need this
722 // field...
723 }
725 }
726 }
728
730 6. Security Considerations
732 6.1. Clock Sensitivity
734 This document defines artifacts containing time values for voucher
735 expirations and revocations, which require an accurate clock in order
736 to be processed correctly. Implementations MUST ensure devices have
737 an accurate clock when shipped from manufacturing facilities, and
738 take steps to prevent clock tampering.
740 If it is not possible to ensure clock accuracy, it is RECOMMENDED
741 that implementations disable the aspects of the solution having clock
742 sensitivity. In particular, such implementations should assume that
743 vouchers neither ever expire or are revokable.
745 It is important to note that implementations SHOULD NOT rely on NTP
746 for time, as it is not a secure protocol.
748 7. IANA Considerations
750 7.1. The IETF XML Registry
752 This document registers two URIs in the IETF XML registry [RFC3688].
753 Following the format in [RFC3688], the following registrations are
754 requested:
756 URI: urn:ietf:params:xml:ns:yang:ietf-voucher
757 Registrant Contact: The ANIMA WG of the IETF.
758 XML: N/A, the requested URI is an XML namespace.
760 URI: urn:ietf:params:xml:ns:yang:ietf-voucher-revocation
761 Registrant Contact: The ANIMA WG of the IETF.
762 XML: N/A, the requested URI is an XML namespace.
764 7.2. The YANG Module Names Registry
766 This document registers two YANG modules in the YANG Module Names
767 registry [RFC6020]. Following the format defined in [RFC6020], the
768 the following registrations are requested:
770 name: ietf-voucher
771 namespace: urn:ietf:params:xml:ns:yang:ietf-voucher
772 prefix: vch
773 reference: RFC XXXX
775 name: ietf-voucher-revocation
776 namespace: urn:ietf:params:xml:ns:yang:ietf-voucher-revocation
777 prefix: vchr
778 reference: RFC XXXX
780 8. Acknowledgements
782 The authors would like to thank for following for lively discussions
783 on list and in the halls (ordered by last name):
785 9. References
787 9.1. Normative References
789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
790 Requirement Levels", BCP 14, RFC 2119,
791 DOI 10.17487/RFC2119, March 1997,
792 .
794 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
795 the Network Configuration Protocol (NETCONF)", RFC 6020,
796 DOI 10.17487/RFC6020, October 2010,
797 .
799 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
800 RFC 7950, DOI 10.17487/RFC7950, August 2016,
801 .
803 9.2. Informative References
805 [draft-ietf-anima-bootstrapping-keyinfra]
806 Pritikin, M., Richardson, M., Behringer, M., and S.
807 Bjarnason, "Bootstrapping Key Infrastructures", draft-
808 ietf-anima-bootstrapping-keyinfra (work in progress),
809 2016, .
812 [draft-ietf-netconf-zerotouch]
813 Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning
814 for NETCONF or RESTCONF based Management", draft-ietf-
815 netconf-zerotouch (work in progress), 2016,
816 .
819 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
820 DOI 10.17487/RFC3688, January 2004,
821 .
823 Appendix A. Change Log
825 Authors' Addresses
827 Kent Watsen
828 Juniper Networks
830 EMail: kwatsen@juniper.net
832 Michael C. Richardson
833 Sandelman Software Works
835 EMail: mcr+ietf@sandelman.ca
836 URI: http://www.sandelman.ca/
838 Max Pritikin
839 Cisco Systems
841 EMail: pritikin@cisco.com
843 Toerless Eckert
845 EMail: tte+anima@cs.fau.de