idnits 2.17.1
draft-kwatsen-netconf-crypto-types-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 124 has weird spacing: '...on-date yan...'
== Line 136 has weird spacing: '...request bin...'
== Line 143 has weird spacing: '...gorithm ide...'
-- The document date (March 5, 2018) is 2206 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)
== Unused Reference: 'RFC7950' is defined on line 792, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.1994'
** Downref: Normative reference to an Informational RFC: RFC 2315
** Downref: Normative reference to an Informational RFC: RFC 2986
** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017)
** Downref: Normative reference to an Informational RFC: RFC 5915
** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341)
Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 NETCONF Working Group K. Watsen
3 Internet-Draft Juniper Networks
4 Intended status: Standards Track March 5, 2018
5 Expires: September 6, 2018
7 Common YANG Data Types for Cryptography
8 draft-kwatsen-netconf-crypto-types-00
10 Abstract
12 This document defines a YANG identities, typedefs, and groupings
13 useful for when working with ASN.1 structures, algorithms, and
14 private keys.
16 Editorial Note (To be removed by RFC Editor)
18 This draft contains many placeholder values that need to be replaced
19 with finalized values at the time of publication. This note
20 summarizes all of the substitutions that are needed. No other RFC
21 Editor instructions are specified elsewhere in this document.
23 Artwork in this document contains shorthand references to drafts in
24 progress. Please apply the following replacements:
26 o "XXXX" --> the assigned RFC value for this draft
28 Artwork in this document contains placeholder values for the date of
29 publication of this draft. Please apply the following replacement:
31 o "2018-03-05" --> the publication date of this draft
33 The following Appendix section is to be removed prior to publication:
35 o Appendix A. Change Log
37 Status of This Memo
39 This Internet-Draft is submitted in full conformance with the
40 provisions of BCP 78 and BCP 79.
42 Internet-Drafts are working documents of the Internet Engineering
43 Task Force (IETF). Note that other groups may also distribute
44 working documents as Internet-Drafts. The list of current Internet-
45 Drafts is at https://datatracker.ietf.org/drafts/current/.
47 Internet-Drafts are draft documents valid for a maximum of six months
48 and may be updated, replaced, or obsoleted by other documents at any
49 time. It is inappropriate to use Internet-Drafts as reference
50 material or to cite them other than as "work in progress."
52 This Internet-Draft will expire on September 6, 2018.
54 Copyright Notice
56 Copyright (c) 2018 IETF Trust and the persons identified as the
57 document authors. All rights reserved.
59 This document is subject to BCP 78 and the IETF Trust's Legal
60 Provisions Relating to IETF Documents
61 (https://trustee.ietf.org/license-info) in effect on the date of
62 publication of this document. Please review these documents
63 carefully, as they describe your rights and restrictions with respect
64 to this document. Code Components extracted from this document must
65 include Simplified BSD License text as described in Section 4.e of
66 the Trust Legal Provisions and are provided without warranty as
67 described in the Simplified BSD License.
69 Table of Contents
71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
72 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
73 1.2. Tree Diagram Notation . . . . . . . . . . . . . . . . . . 3
74 2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . . . 3
75 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4
76 3.1. Private Key and Associated Certificate Configuration . . 4
77 3.2. Certificate Signing Request Action . . . . . . . . . . . 5
78 3.3. Generate Private Key Action . . . . . . . . . . . . . . . 6
79 3.4. Certificate Expiration Notification . . . . . . . . . . . 6
80 4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 7
81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
83 6.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 17
84 6.2. The YANG Module Names Registry . . . . . . . . . . . . . 17
85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
87 8.1. Normative References . . . . . . . . . . . . . . . . . . 17
88 8.2. Informative References . . . . . . . . . . . . . . . . . 19
89 Appendix A. Example YANG Module . . . . . . . . . . . . . . . . 20
90 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 21
91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
93 1. Introduction
95 This document defines a YANG identities, typedefs, and groupings
96 useful for when working with ASN.1 structures, algorithms, and
97 private keys.
99 1.1. Requirements Language
101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
103 "OPTIONAL" in this document are to be interpreted as described in BCP
104 14 [RFC2119] [RFC8174] when, and only when, they appear in all
105 capitals, as shown here.
107 1.2. Tree Diagram Notation
109 Tree diagrams used in this document follow the notation defined in
110 [I-D.ietf-netmod-yang-tree-diagrams].
112 2. Tree Diagram
114 The following tree diagram provides an overview of the groupings,
115 actions, and notifications defined in the ietf-crypto-types YANG
116 module. The YANG module defines many identities and typedefs that
117 are not represented by this tree diagram.
119 module: ietf-crypto-types
121 notifications:
122 +---n certificate-expiration
123 +--ro certificate instance-identifier
124 +--ro expiration-date yang:date-and-time
126 grouping certificates-grouping
127 +---- certificates
128 | +---- certificate* [name]
129 | +---- name? string
130 | +---- value? binary
131 +---x generate-certificate-signing-request
132 +---w input
133 | +---w subject binary
134 | +---w attributes? binary
135 +--ro output
136 +--ro certificate-signing-request binary
137 grouping private-key-grouping
138 +---- algorithm? identityref
139 +---- private-key? union
140 +---- public-key? binary
141 +---x generate-private-key
142 +---w input
143 +---w algorithm identityref
145 3. Examples
147 These examples illustrate the use of the groupings, actions, and
148 notifications defined in the ietf-crypto-types YANG module. The YANG
149 module defines many identities and typedefs that are not represented
150 that are not represented by these examples.
152 3.1. Private Key and Associated Certificate Configuration
154 The following example illustrates a configured private key along with
155 an associated certificate. This example uses the "ex-crypto-types-
156 usage" module defined in Appendix A.
158 [ note: '\' line wrapping for formatting only]
160
161 ct:secp521r1
163 base64encodedvalue==
164 base64encodedvalue==
165
166
167 domain certificate
168 base64encodedvalue==
169
170
171
173 3.2. Certificate Signing Request Action
175 The following example illustrates the "generate-certificate-signing-
176 request" action in use with the NETCONF protocol. This example uses
177 the "ex-crypto-types-usage" module defined in Appendix A.
179 REQUEST
180 -------
181
182
183
184
185 base64encodedvalue==
186 base64encodedvalue==
187
188
189
190
192 RESPONSE
193 --------
194
196
198 base64encodedvalue==
199
200
202 3.3. Generate Private Key Action
204 The following example illustrates the "generate-private-key" action
205 in use with the NETCONF protocol. This example uses the "ex-crypto-
206 types-usage" module defined in Appendix A.
208 REQUEST
209 -------
210 [ note: '\' line wrapping for formatting only]
212
214
215
216
217 ct:secp521r1
219
220
221
222
224 RESPONSE
225 --------
226
228
229
231 3.4. Certificate Expiration Notification
233 The following example illustrates the "certificate-expiration"
234 notification in use with the NETCONF protocol. This example uses the
235 "ex-crypto-types-usage" module defined in Appendix A.
237 [ note: '\' line wrapping for formatting only]
239
241 2016-07-08T00:01:00Z
242
244
246 /ex:key/ex:certificates/ex:certificate[ex:name='domain certifi\
247 cate']
248
249 2016-08-08T14:18:53-05:00
250
251
253 4. YANG Module
255 This YANG module imports modules defined in [RFC6536] and [RFC6991].
256 This module uses data types defined in [RFC2315], [RFC2986],
257 [RFC3447], [RFC4253], [RFC5280], [RFC5915], and [ITU.X690.1994].
258 This module uses algorithms defined in [RFC3447] and [RFC5480].
260 file "ietf-crypto-types@2018-03-05.yang"
261 module ietf-crypto-types {
262 yang-version 1.1;
264 namespace "urn:ietf:params:xml:ns:yang:ietf-crypto-types";
265 prefix "ct";
267 import ietf-yang-types {
268 prefix yang;
269 reference
270 "RFC 6991: Common YANG Data Types";
271 }
273 import ietf-netconf-acm {
274 prefix nacm;
275 reference
276 "RFC 6536: Network Configuration Protocol (NETCONF) Access
277 Control Model";
278 }
280 organization
281 "IETF NETCONF (Network Configuration) Working Group";
283 contact
284 "WG Web:
285 WG List:
287 Author: Kent Watsen
288 ";
290 description
291 "This module defines common YANG types for cryptography applications.
293 Copyright (c) 2018 IETF Trust and the persons identified
294 as authors of the code. All rights reserved.
296 Redistribution and use in source and binary forms, with
297 or without modification, is permitted pursuant to, and
298 subject to the license terms contained in, the Simplified
299 BSD License set forth in Section 4.c of the IETF Trust's
300 Legal Provisions Relating to IETF Documents
301 (http://trustee.ietf.org/license-info).
303 This version of this YANG module is part of RFC XXXX; see
304 the RFC itself for full legal notices.";
306 revision "2018-03-05" {
307 description
308 "Initial version";
309 reference
310 "RFC XXXX: Common YANG Data Types for Cryptography";
311 }
313 /****************************************/
314 /* Identities for Hashing Algorithms */
315 /****************************************/
317 identity hash-algorithm {
318 description
319 "A base identity for hash algorithm verification.
321 This identity is used in the ietf-zerotouch-information
322 module (draft-ietf-netconf-zerotouch)";
323 }
325 identity sha-256 {
326 base "hash-algorithm";
327 description "The SHA-256 algorithm.";
328 reference "RFC 6234: US Secure Hash Algorithms.";
329 }
330 /************************************************************/
331 /* Identities for Key Algorithms (used by Certificates) */
332 /************************************************************/
334 identity key-algorithm {
335 description
336 "Base identity from which all key-algorithms are derived.
338 This identity is used in the 'private-key-grouping' grouping
339 and the 'generate-private-key' action below.";
340 }
342 identity rsa1024 {
343 base key-algorithm;
344 description
345 "The RSA algorithm using a 1024-bit key.";
346 reference
347 "RFC3447: Public-Key Cryptography Standards (PKCS) #1:
348 RSA Cryptography Specifications Version 2.1.";
349 }
351 identity rsa2048 {
352 base key-algorithm;
353 description
354 "The RSA algorithm using a 2048-bit key.";
355 reference
356 "RFC3447: Public-Key Cryptography Standards (PKCS) #1:
357 RSA Cryptography Specifications Version 2.1.";
358 }
360 identity rsa3072 {
361 base key-algorithm;
362 description
363 "The RSA algorithm using a 3072-bit key.";
364 reference
365 "RFC3447: Public-Key Cryptography Standards (PKCS) #1:
366 RSA Cryptography Specifications Version 2.1.";
367 }
369 identity rsa4096 {
370 base key-algorithm;
371 description
372 "The RSA algorithm using a 4096-bit key.";
373 reference
374 "RFC3447: Public-Key Cryptography Standards (PKCS) #1:
375 RSA Cryptography Specifications Version 2.1.";
376 }
377 identity rsa7680 {
378 base key-algorithm;
379 description
380 "The RSA algorithm using a 7680-bit key.";
381 reference
382 "RFC3447: Public-Key Cryptography Standards (PKCS) #1:
383 RSA Cryptography Specifications Version 2.1.";
384 }
386 identity rsa15360 {
387 base key-algorithm;
388 description
389 "The RSA algorithm using a 15360-bit key.";
390 reference
391 "RFC3447: Public-Key Cryptography Standards (PKCS) #1:
392 RSA Cryptography Specifications Version 2.1.";
393 }
395 identity secp192r1 {
396 base key-algorithm;
397 description
398 "The secp192r1 algorithm.";
399 reference
400 "RFC5480:
401 Elliptic Curve Cryptography Subject Public Key Information.";
402 }
404 identity secp256r1 {
405 base key-algorithm;
406 description
407 "The secp256r1 algorithm.";
408 reference
409 "RFC5480:
410 Elliptic Curve Cryptography Subject Public Key Information.";
411 }
413 identity secp384r1 {
414 base key-algorithm;
415 description
416 "The secp384r1 algorithm.";
417 reference
418 "RFC5480:
419 Elliptic Curve Cryptography Subject Public Key Information.";
420 }
422 identity secp521r1 {
423 base key-algorithm;
424 description
425 "The secp521r1 algorithm.";
426 reference
427 "RFC5480:
428 Elliptic Curve Cryptography Subject Public Key Information.";
429 }
431 /************************************/
432 /* Typedefs for ASN.1 structures */
433 /************************************/
435 typedef x509 {
436 type binary;
437 description
438 "A Certificate structure, as specified in RFC 5280, encoded using
439 ASN.1 distinguished encoding rules (DER), as specified in
440 ITU-T X.690.";
441 reference
442 "RFC 5652:
443 Cryptographic Message Syntax (CMS)
444 ITU-T X.690:
445 Information technology - ASN.1 encoding rules:
446 Specification of Basic Encoding Rules (BER),
447 Canonical Encoding Rules (CER) and Distinguished
448 Encoding Rules (DER).";
449 }
451 typedef cms {
452 type binary;
453 description
454 "A ContentInfo structure, as specified in RFC 5652, encoded
455 using ASN.1 distinguished encoding rules (DER), as specified
456 in ITU-T X.690.";
457 reference
458 "RFC 5652:
459 Cryptographic Message Syntax (CMS)
460 ITU-T X.690:
461 Information technology - ASN.1 encoding rules:
462 Specification of Basic Encoding Rules (BER),
463 Canonical Encoding Rules (CER) and Distinguished
464 Encoding Rules (DER).";
465 }
467 /******************************************************************/
468 /* Groupings for a Private Key and its Associated Certificates */
469 /******************************************************************/
471 grouping private-key-grouping {
472 description
473 "A private/public key pair, and an action to request the
474 system to generate a private key.
476 This grouping is currently used by the YANG modules
477 ietf-ssh-client, ietf-ssh-server, ietf-tls-client,
478 and ietf-tls-server, where it populates the SSH/TLS
479 peer object's private key parameters.";
480 leaf algorithm {
481 type identityref {
482 base "key-algorithm";
483 }
484 description
485 "Identifies the key's algorithm. More specifically, this
486 leaf specifies how the 'private-key' and 'public-key'
487 binary leafs are encoded.";
488 }
489 leaf private-key {
490 nacm:default-deny-all;
491 type union {
492 type binary;
493 type enumeration {
494 enum "hardware-protected" {
495 description
496 "The private key is inaccessible due to being
497 protected by a cryptographic hardware module
498 (e.g., a TPM).";
499 }
500 }
501 }
502 must "../algorithm";
503 description
504 "A binary that contains the value of the private key. The
505 interpretation of the content is defined by the key
506 algorithm. For example, a DSA key is an integer, an RSA
507 key is represented as RSAPrivateKey as defined in
508 [RFC3447], and an Elliptic Curve Cryptography (ECC) key
509 is represented as ECPrivateKey as defined in [RFC5915]";
510 reference
511 "RFC 3447: Public-Key Cryptography Standards (PKCS) #1:
512 RSA Cryptography Specifications Version 2.1.
513 RFC 5915: Elliptic Curve Private Key Structure.";
514 }
515 leaf public-key {
516 type binary;
517 must "../algorithm";
518 must "../private-key";
519 description
520 "A binary that contains the value of the public key. The
521 interpretation of the content is defined by the key
522 algorithm. For example, a DSA key is an integer, an RSA
523 key is represented as RSAPublicKey as defined in
524 [RFC3447], and an Elliptic Curve Cryptography (ECC) key
525 is represented using the 'publicKey' described in
526 [RFC5915]";
527 reference
528 "RFC 3447: Public-Key Cryptography Standards (PKCS) #1:
529 RSA Cryptography Specifications Version 2.1.
530 RFC 5915: Elliptic Curve Private Key Structure.";
531 }
532 action generate-private-key {
533 description
534 "Requests the device to generate a private key using the
535 specified key algorithm. This action is primarily to
536 support cryptographic processors that must generate
537 the private key themselves. The resulting key is
538 considered operational state and hence only present
539 in .";
540 input {
541 leaf algorithm {
542 type identityref {
543 base "key-algorithm";
544 }
545 mandatory true;
546 description
547 "The algorithm to be used when generating the key.";
548 }
549 }
550 } // end generate-private-key
551 }
553 grouping certificates-grouping {
554 description
555 "A container of certificates, and an action to generate
556 a certificate signing request.
558 This grouping is currently used by the YANG modules
559 ietf-ssh-client, ietf-ssh-server, ietf-tls-client,
560 and ietf-tls-server, where it populates the SSH/TLS
561 peer object's value for a certificates associated
562 with the private key.";
564 container certificates {
565 description
566 "Certificates associated with this key. More than one
567 certificate supports, for instance, a TPM-protected
568 key that has both IDevID and LDevID certificates
569 associated.";
570 list certificate {
571 key name;
572 description
573 "A certificate for this private key.";
574 leaf name {
575 type string;
576 description
577 "An arbitrary name for the certificate.";
578 }
579 leaf value {
580 type binary;
581 description
582 "A PKCS #7 SignedData structure, as specified by
583 Section 9.1 in RFC 2315, containing just certificates
584 (no content, signatures, or CRLs), encoded using ASN.1
585 distinguished encoding rules (DER), as specified in
586 ITU-T X.690.
588 This structure contains the certificate itself as well
589 as any intermediate certificates leading up to a trust
590 anchor certificate. The trust anchor certificate MAY
591 be included as well.";
592 reference
593 "RFC 2315:
594 PKCS #7: Cryptographic Message Syntax Version 1.5.
595 ITU-T X.690:
596 Information technology - ASN.1 encoding rules:
597 Specification of Basic Encoding Rules (BER),
598 Canonical Encoding Rules (CER) and Distinguished
599 Encoding Rules (DER).";
600 }
601 }
602 }
603 action generate-certificate-signing-request {
604 description
605 "Generates a certificate signing request structure for
606 the associated private key using the passed subject and
607 attribute values. The specified assertions need to be
608 appropriate for the certificate's use. For example,
609 an entity certificate for a TLS server SHOULD have
610 values that enable clients to satisfy RFC 6125
611 processing.";
613 input {
614 leaf subject {
615 type binary;
616 mandatory true;
617 description
618 "The 'subject' field from the CertificationRequestInfo
619 structure as specified by RFC 2986, Section 4.1 encoded
620 using the ASN.1 distinguished encoding rules (DER), as
621 specified in ITU-T X.690.";
622 reference
623 "RFC 2986:
624 PKCS #10: Certification Request Syntax Specification
625 Version 1.7.
626 ITU-T X.690:
627 Information technology - ASN.1 encoding rules:
628 Specification of Basic Encoding Rules (BER),
629 Canonical Encoding Rules (CER) and Distinguished
630 Encoding Rules (DER).";
631 }
632 leaf attributes {
633 type binary;
634 description
635 "The 'attributes' field from the CertificationRequestInfo
636 structure as specified by RFC 2986, Section 4.1 encoded
637 using the ASN.1 distinguished encoding rules (DER), as
638 specified in ITU-T X.690.";
639 reference
640 "RFC 2986:
641 PKCS #10: Certification Request Syntax Specification
642 Version 1.7.
643 ITU-T X.690:
644 Information technology - ASN.1 encoding rules:
645 Specification of Basic Encoding Rules (BER),
646 Canonical Encoding Rules (CER) and Distinguished
647 Encoding Rules (DER).";
648 }
649 }
650 output {
651 leaf certificate-signing-request {
652 type binary;
653 mandatory true;
654 description
655 "A CertificationRequest structure as specified by RFC
656 2986, Section 4.1 encoded using the ASN.1 distinguished
657 encoding rules (DER), as specified in ITU-T X.690.";
658 reference
659 "RFC 2986:
660 PKCS #10: Certification Request Syntax Specification
661 Version 1.7.
662 ITU-T X.690:
663 Information technology - ASN.1 encoding rules:
664 Specification of Basic Encoding Rules (BER),
665 Canonical Encoding Rules (CER) and Distinguished
666 Encoding Rules (DER).";
668 }
669 }
670 }
671 }
673 notification certificate-expiration {
674 description
675 "A notification indicating that a configured certificate is
676 either about to expire or has already expired. When to send
677 notifications is an implementation specific decision, but
678 it is RECOMMENDED that a notification be sent once a month
679 for 3 months, then once a week for four weeks, and then once
680 a day thereafter.";
681 leaf certificate {
682 type instance-identifier;
683 mandatory true;
684 description
685 "Identifies which certificate is expiring or is expired.";
686 }
687 leaf expiration-date {
688 type yang:date-and-time;
689 mandatory true;
690 description
691 "Identifies the expiration date on the certificate.";
692 }
693 }
695 }
696
698 5. Security Considerations
700 TBD
702 6. IANA Considerations
703 6.1. The IETF XML Registry
705 This document registers one URI in the IETF XML registry [RFC3688].
706 Following the format in [RFC3688], the following registration is
707 requested:
709 URI: urn:ietf:params:xml:ns:yang:ietf-crypto-types
710 Registrant Contact: The NETCONF WG of the IETF.
711 XML: N/A, the requested URI is an XML namespace.
713 6.2. The YANG Module Names Registry
715 This document registers one YANG module in the YANG Module Names
716 registry [RFC6020]. Following the format in [RFC6020], the the
717 following registration is requested:
719 name: ietf-crypto-types
720 namespace: urn:ietf:params:xml:ns:yang:ietf-crypto-types
721 prefix: ct
722 reference: RFC XXXX
724 7. Acknowledgements
726 The authors would like to thank for following for lively discussions
727 on list and in the halls (ordered by last name):
729 8. References
731 8.1. Normative References
733 [ITU.X690.1994]
734 International Telecommunications Union, "Information
735 Technology - ASN.1 encoding rules: Specification of Basic
736 Encoding Rules (BER), Canonical Encoding Rules (CER) and
737 Distinguished Encoding Rules (DER)", ITU-T Recommendation
738 X.690, 1994.
740 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
741 Requirement Levels", BCP 14, RFC 2119,
742 DOI 10.17487/RFC2119, March 1997,
743 .
745 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
746 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998,
747 .
749 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
750 Request Syntax Specification Version 1.7", RFC 2986,
751 DOI 10.17487/RFC2986, November 2000,
752 .
754 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
755 Standards (PKCS) #1: RSA Cryptography Specifications
756 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
757 2003, .
759 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
760 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
761 January 2006, .
763 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
764 Housley, R., and W. Polk, "Internet X.509 Public Key
765 Infrastructure Certificate and Certificate Revocation List
766 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
767 .
769 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
770 "Elliptic Curve Cryptography Subject Public Key
771 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
772 .
774 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key
775 Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010,
776 .
778 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
779 the Network Configuration Protocol (NETCONF)", RFC 6020,
780 DOI 10.17487/RFC6020, October 2010,
781 .
783 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
784 Protocol (NETCONF) Access Control Model", RFC 6536,
785 DOI 10.17487/RFC6536, March 2012,
786 .
788 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
789 RFC 6991, DOI 10.17487/RFC6991, July 2013,
790 .
792 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
793 RFC 7950, DOI 10.17487/RFC7950, August 2016,
794 .
796 8.2. Informative References
798 [I-D.ietf-netmod-yang-tree-diagrams]
799 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
800 ietf-netmod-yang-tree-diagrams-06 (work in progress),
801 February 2018.
803 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
804 DOI 10.17487/RFC3688, January 2004,
805 .
807 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
808 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
809 May 2017, .
811 Appendix A. Example YANG Module
813 The following example YANG module has been constructed to illustrate
814 the groupings defined in the "ietf-crypto-types" module. This YANG
815 module is uses as a basis for the protocol examples in Section 3.
817 module ex-crypto-types-usage {
818 yang-version 1.1;
820 namespace "http://example.com/ns/example-crypto-types-usage";
821 prefix "ctu";
823 import ietf-crypto-types {
824 prefix ct;
825 reference
826 "RFC XXXX: Common YANG Data Types for Cryptography";
827 }
829 organization
830 "IETF NETCONF (Network Configuration) Working Group";
832 contact
833 "WG Web:
834 WG List:
835 Author: Kent Watsen ";
837 description
838 "This module illustrates using groupings defined in the YANG
839 module ietf-crypto-types.";
841 revision "YYYY-MM-DD" {
842 description
843 "Initial version";
844 }
846 container key {
847 uses ct:private-key-grouping;
848 uses ct:certificates-grouping;
849 description
850 "A container of certificates, and an action to generate
851 a certificate signing request.";
852 }
853 }
855 Appendix B. Change Log
857 TBD
859 Author's Address
861 Kent Watsen
862 Juniper Networks
864 EMail: kwatsen@juniper.net