1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
|
<pre>Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 5914 Vigil Security, LLC
Category: Standards Track S. Ashmore
ISSN: 2070-1721 National Security Agency
C. Wallace
Cygnacom Solutions
June 2010
<span class="h1">Trust Anchor Format</span>
Abstract
This document describes a structure for representing trust anchor
information. A trust anchor is an authoritative entity represented
by a public key and associated data. The public key is used to
verify digital signatures, and the associated data is used to
constrain the types of information or actions for which the trust
anchor is authoritative. The structures defined in this document are
intended to satisfy the format-related requirements defined in Trust
Anchor Management Requirements.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc5914">http://www.rfc-editor.org/info/rfc5914</a>.
<span class="grey">Housley, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5914">RFC 5914</a> TAF June 2010</span>
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Trust Anchor Information Syntax . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Version . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. Public Key . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.3">2.3</a>. Key Identifier . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.4">2.4</a>. Trust Anchor Title . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.5">2.5</a>. Certification Path Controls . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.6">2.6</a>. Extensions . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3">3</a>. Trust Anchor List . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4">4</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5">5</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5.1">5.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5.2">5.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#appendix-A">Appendix A</a>. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#appendix-A.1">A.1</a>. ASN.1 Module Using 2002 Syntax . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#appendix-A.2">A.2</a>. ASN.1 Module Using 1988 Syntax . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#appendix-A.2.1">A.2.1</a>. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<span class="grey">Housley, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5914">RFC 5914</a> TAF June 2010</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Trust anchors are widely used to verify digital signatures and
validate certification paths [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>][X.509]. They are required
when validating certification paths. Though widely used, there is no
standard format for representing trust anchor information. This
document describes the TrustAnchorInfo structure. This structure is
intended to satisfy the format-related requirements expressed in
Trust Anchor Management Requirements [<a href="#ref-TA-MGMT-REQS" title=""Trust Anchor Management Requirements"">TA-MGMT-REQS</a>] and is expressed
using ASN.1 [<a href="#ref-X.680" title=""ITU-T Recommendation X.680: Information Technology - Abstract Syntax Notation One"">X.680</a>]. It can provide a more compact alternative to
X.509 certificates for exchanging trust anchor information and
provides a means of associating additional or alternative constraints
with certificates without breaking the signature on the certificate.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Trust Anchor Information Syntax</span>
This section describes the TrustAnchorInfo structure.
TrustAnchorInfo ::= SEQUENCE {
version TrustAnchorInfoVersion DEFAULT v1,
pubKey SubjectPublicKeyInfo,
keyId KeyIdentifier,
taTitle TrustAnchorTitle OPTIONAL,
certPath CertPathControls OPTIONAL,
exts [1] EXPLICIT Extensions OPTIONAL,
taTitleLangTag [2] UTF8String OPTIONAL }
TrustAnchorInfoVersion ::= INTEGER { v1(1) }
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Version</span>
version identifies the version of TrustAnchorInfo. Future updates to
this document may include changes to the TrustAnchorInfo structure,
in which case the version number should be incremented. However, the
default value, v1, cannot be changed.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Public Key</span>
pubKey identifies the public key and algorithm associated with the
trust anchor using the SubjectPublicKeyInfo structure [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>]. The
SubjectPublicKeyInfo structure contains the algorithm identifier
followed by the public key itself. The algorithm field is an
<span class="grey">Housley, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5914">RFC 5914</a> TAF June 2010</span>
AlgorithmIdentifier, which contains an object identifier and OPTIONAL
parameters. The object identifier names the public key algorithm and
indicates the syntax of the parameters, if present, as well as the
format of the public key. The public key is encoded as a BIT STRING.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Key Identifier</span>
keyId contains the public key identifier of the trust anchor public
key. See <a href="./rfc5280#section-4.2.1.2">Section 4.2.1.2 of [RFC5280]</a> for a description of common
key identifier calculation methods.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Trust Anchor Title</span>
TrustAnchorTitle ::= UTF8String (SIZE (1..64))
taTitle is OPTIONAL. When it is present, it provides a human-
readable name for the trust anchor. The text is encoded in UTF-8
[<a href="./rfc3629" title=""UTF-8, a transformation format of ISO 10646"">RFC3629</a>], which accommodates most of the world's writing systems.
The taTitleLangTag field identifies the language used to express the
taTitle. When taTitleLangTag is absent, English ("en" language tag)
is used. The value of the taTitleLangTag should be a language tag as
described in [<a href="./rfc5646" title=""Tags for Identifying Languages"">RFC5646</a>].
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. Certification Path Controls</span>
CertPathControls ::= SEQUENCE {
taName Name,
certificate [0] Certificate OPTIONAL,
policySet [1] CertificatePolicies OPTIONAL,
policyFlags [2] CertPolicyFlags OPTIONAL,
nameConstr [3] NameConstraints OPTIONAL,
pathLenConstraint[4] INTEGER (0..MAX) OPTIONAL}
certPath is OPTIONAL. When it is present, it provides the controls
needed to initialize an X.509 certification path validation algorithm
implementation (see <a href="./rfc5280#section-6">Section 6 of [RFC5280]</a>). When absent, the trust
anchor cannot be used to validate the signature on an X.509
certificate.
taName provides the X.500 distinguished name associated with the
trust anchor, and this distinguished name is used to construct and
validate an X.509 certification path. The name MUST NOT be an empty
sequence.
certificate provides an OPTIONAL X.509 certificate, which can be used
in some environments to represent the trust anchor in certification
path development and validation. If the certificate is present, the
subject name in the certificate MUST exactly match the X.500
<span class="grey">Housley, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5914">RFC 5914</a> TAF June 2010</span>
distinguished name provided in the taName field, the public key MUST
exactly match the public key in the pubKey field, and the
subjectKeyIdentifier extension, if present, MUST exactly match the
key identifier in the keyId field. The complete description of the
syntax and semantics of the Certificate are provided in [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>].
Constraints defined in the policySet, policyFlags, nameConstr,
pathLenConstraint, and exts fields within TrustAnchorInfo replace
values contained in a certificate or provide values for extensions
not present in the certificate. Values defined in these
TrustAnchorInfo fields are always enforced. Extensions included in a
certificate are enforced only if there is no corresponding value in
the TrustAnchorInfo. Correspondence between extensions within
certificate and TrustAnchorInfo fields is defined as follows:
o an id-ce-certificatePolicies certificate extension corresponds to
the CertPathControls.policySet field.
o an id-ce-policyConstraints certificate extension corresponds to
the CertPolicyFlags.inhibitPolicyMapping and
CertPolicyFlags.requireExplicitPolicy fields.
o an id-ce-inhibitAnyPolicy certificate extension corresponds to the
CertPolicyFlags.inhibitAnyPolicy field.
o an id-ce-nameConstraints certificate extension corresponds to the
CertPathControls.nameConstr field.
o the pathLenConstraint field of an id-ce-basicConstraints
certificate extension corresponds to the
CertPathControls.pathLenConstraint field (the presence of a
CertPathControls structure corresponds to a TRUE value in the cA
field of a BasicConstraints extension).
o any other certificate extension corresponds to the same type of
extension in the TrustAnchorInfo.exts field.
CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
PolicyInformation ::= SEQUENCE {
policyIdentifier CertPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL }
CertPolicyId ::= OBJECT IDENTIFIER
policySet is OPTIONAL. When present, it contains a sequence of
certificate policy identifiers to be provided as inputs to the
certification path validation algorithm. When absent, the special
<span class="grey">Housley, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5914">RFC 5914</a> TAF June 2010</span>
value any-policy is provided as the input to the certification path
validation algorithm. The complete description of the syntax and
semantics of the CertificatePolicies are provided in [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>],
including the syntax for PolicyInformation. In this context, the
OPTIONAL policyQualifiers structure MUST NOT be included.
CertPolicyFlags ::= BIT STRING {
inhibitPolicyMapping (0),
requireExplicitPolicy (1),
inhibitAnyPolicy (2) }
policyFlags is OPTIONAL. When present, three Boolean values for
input to the certification path validation algorithm are provided in
a BIT STRING. When absent, the input to the certification path
validation algorithm is { FALSE, FALSE, FALSE }, which represents the
most liberal setting for these flags. The three bits are used as
follows:
inhibitPolicyMapping indicates if policy mapping is allowed in the
certification path. When set to TRUE, policy mapping is not
permitted. This value represents the initial-policy-mapping-
inhibit input value to the certification path validation algorithm
described in <a href="./rfc5280#section-6.1.1">Section 6.1.1 of [RFC5280]</a>.
requireExplicitPolicy indicates if the certification path MUST be
valid for at least one of the certificate policies in the
policySet. When set to TRUE, all certificates in the
certification path MUST contain an acceptable policy identifier in
the certificate policies extension. This value represents the
initial-explicit-policy input value to the certification path
validation algorithm described in <a href="./rfc5280#section-6.1.1">Section 6.1.1 of [RFC5280]</a>. An
acceptable policy identifier is a member of the policySet or the
identifier of a policy that is declared to be equivalent through
policy mapping. This bit MUST be set to FALSE if policySet is
absent.
inhibitAnyPolicy indicates whether the special anyPolicy policy
identifier, with the value { 2 5 29 32 0 }, is considered an
explicit match for other certificate policies. This value
represents the initial-any-policy-inhibit input value to the
certification path validation algorithm described in <a href="./rfc5280#section-6.1.1">Section 6.1.1
of [RFC5280]</a>.
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
<span class="grey">Housley, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5914">RFC 5914</a> TAF June 2010</span>
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)
nameConstr is OPTIONAL. It has the same syntax and semantics as the
Name Constraints certificate extension [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>], which includes a
list of permitted names and a list of excluded names. The definition
of GeneralName can be found in [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>]. When it is present,
constraints are provided on names (including alternative names) that
might appear in subsequent X.509 certificates in a certification
path. This field is used to set the initial-permitted-subtrees and
initial-excluded-subtrees input values to the certification path
validation algorithm described in <a href="./rfc5280#section-6.1.1">Section 6.1.1 of [RFC5280]</a>. When
this field is absent, the initial-permitted-subtrees variable is
unbounded and the initial-excluded-subtrees variable is empty.
The pathLenConstraint field gives the maximum number of non-self-
issued intermediate certificates that may follow this certificate in
a valid certification path. (Note: The last certificate in the
certification path is not an intermediate certificate and is not
included in this limit. Usually, the last certificate is an end
entity certificate, but it can be a CA certificate.) A
pathLenConstraint of zero indicates that no non-self-issued
intermediate certification authority (CA) certificates may follow in
a valid certification path. Where it appears, the pathLenConstraint
field MUST be greater than or equal to zero. Where pathLenConstraint
does not appear, no limit is imposed.
When the trust anchor is used to validate a certification path,
CertPathControls provides limitations on certification paths that
will successfully validate. An application that is validating a
certification path SHOULD NOT ignore these limitations, but the
application can impose additional limitations to ensure that the
validated certification path is appropriate for the intended
application context. As input to the certification path validation
algorithm, an application MAY:
o Provide a subset of the certification policies provided in the
policySet;
o Provide a TRUE value, if appropriate, for any of the flags in the
policyFlags;
o Provide a subset of the permitted names provided in the
nameConstr;
<span class="grey">Housley, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5914">RFC 5914</a> TAF June 2010</span>
o Provide additional excluded names to the ones that are provided in
the nameConstr;
o Provide a smaller value for pathLenConstraint.
<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>. Extensions</span>
exts is OPTIONAL. When it is present, it can be used to associate
additional information with the trust anchor using the standard
Extensions structure. Extensions that are anticipated to be widely
used have been included in the CertPathControls structure to avoid
overhead associated with use of the Extensions structure. To avoid
duplication with the CertPathControls field, the following types of
extensions MUST NOT appear in the exts field and are ignored if they
do appear: id-ce-certificatePolicies, id-ce-policyConstraints, id-ce-
inhibitAnyPolicy, or id-ce-nameConstraints.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Trust Anchor List</span>
TrustAnchorInfo allows for the representation of a single trust
anchor. In many cases, it is convenient to represent a collection of
trust anchors. The TrustAnchorList structure is defined for this
purpose. TrustAnchorList is defined as a sequence of one or more
TrustAnchorChoice objects. TrustAnchorChoice provides three options
for representing a trust anchor. The certificate option allows for
the use of a certificate with no additional associated constraints.
The tbsCert option allows for associating constraints by removing a
signature on a certificate and changing the extensions field. The
taInfo option allows for use of the TrustAnchorInfo structure defined
in this document.
TrustAnchorList ::= SEQUENCE SIZE (1..MAX) OF TrustAnchorChoice
TrustAnchorChoice ::= CHOICE {
certificate Certificate,
tbsCert [1] EXPLICIT TBSCertificate,
taInfo [2] EXPLICIT TrustAnchorInfo }
trust-anchor-list PKCS7-CONTENT-TYPE ::=
{ TrustAnchorList IDENTIFIED BY id-ct-trustAnchorList }
The TrustAnchorList structure can be protected using the SignedData
structure defined in the Cryptographic Message Syntax (CMS)
[<a href="./rfc5652" title=""Cryptographic Message Syntax (CMS)"">RFC5652</a>]. The id-ct-trustAnchorList object identifier has been
defined to represent TrustAnchorList payloads with CMS structures.
<span class="grey">Housley, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5914">RFC 5914</a> TAF June 2010</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
Compromise of a trust anchor private key permits unauthorized parties
to masquerade as the trust anchor, with potentially severe
consequences. Where TA-based constraints are enforced, the
unauthorized holder of the trust anchor private key will be limited
by the certification path controls associated with the trust anchor,
as expressed in the certPath and exts fields. For example, name
constraints in the trust anchor will determine the name space that
will be accepted in certificates that are validated using the
compromised trust anchor. Reliance on an inappropriate or incorrect
trust anchor public key has similar potentially severe consequences.
The compromise of a CA's private key leads to the same type of
problems as the compromise of a trust anchor private key. The
unauthorized holder of the CA private key will be limited by the
certification path controls associated with the trust anchor, as
expressed in the certPath field or as an extension.
Usage of a certificate independent of the TrustAnchorInfo structure
that envelopes it must be carefully managed to avoid violating
constraints expressed in the TrustAnchorInfo. When enveloping a
certificate in a TrustAnchorInfo structure, values included in the
certificate should be evaluated to ensure there is no confusion or
conflict with values in the TrustAnchorInfo structure.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. References</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC3629">RFC3629</a>] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, <a href="./rfc3629">RFC 3629</a>, November 2003.
[<a id="ref-RFC5652">RFC5652</a>] Housley, R., "Cryptographic Message Syntax (CMS)",
<a href="./rfc5652">RFC 5652</a>, September 2009.
[<a id="ref-RFC5280">RFC5280</a>] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", <a href="./rfc5280">RFC 5280</a>, May 2008.
[<a id="ref-RFC5646">RFC5646</a>] Phillips, A. and M. Davis, "Tags for Identifying
Languages", <a href="https://www.rfc-editor.org/bcp/bcp47">BCP 47</a>, <a href="./rfc5646">RFC 5646</a>, September 2009.
<span class="grey">Housley, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5914">RFC 5914</a> TAF June 2010</span>
[<a id="ref-RFC5912">RFC5912</a>] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)",
<a href="./rfc5912">RFC 5912</a>, June 2010.
[<a id="ref-X.680">X.680</a>] "ITU-T Recommendation X.680: Information Technology -
Abstract Syntax Notation One", 2002.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Informative References</span>
[<a id="ref-TA-MGMT-REQS">TA-MGMT-REQS</a>] Reddy, R. and C. Wallace, "Trust Anchor Management
Requirements", Work in Progress, March 2010.
[<a id="ref-X.509">X.509</a>] "ITU-T Recommendation X.509 - The Directory -
Authentication Framework", 2000.
<span class="grey">Housley, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5914">RFC 5914</a> TAF June 2010</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. ASN.1 Modules</span>
<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>. ASN.1 Module Using 2002 Syntax</span>
<a href="#appendix-A.1">Appendix A.1</a> provides the normative ASN.1 definitions for the
structures described in this specification using ASN.1 as defined in
[<a href="#ref-X.680" title=""ITU-T Recommendation X.680: Information Technology - Abstract Syntax Notation One"">X.680</a>]. It includes definitions imported from [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>] and
[<a href="./rfc5912" title=""New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)"">RFC5912</a>].
TrustAnchorInfoModule
{ joint-iso-ccitt(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) modules(0) 33 }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
Certificate, Name, SubjectPublicKeyInfo, TBSCertificate
FROM PKIX1Explicit-2009 -- from [<a href="./rfc5912" title=""New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)"">RFC5912</a>]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)}
CertificatePolicies, KeyIdentifier, NameConstraints
FROM PKIX1Implicit-2009 -- from [<a href="./rfc5912" title=""New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)"">RFC5912</a>]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}
Extensions{}
FROM PKIX-CommonTypes-2009 -- from [<a href="./rfc5912" title=""New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)"">RFC5912</a>]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) } ;
TrustAnchorInfo ::= SEQUENCE {
version TrustAnchorInfoVersion DEFAULT v1,
pubKey SubjectPublicKeyInfo,
keyId KeyIdentifier,
taTitle TrustAnchorTitle OPTIONAL,
certPath CertPathControls OPTIONAL,
exts [1] EXPLICIT Extensions {{...}} OPTIONAL,
taTitleLangTag [2] UTF8String OPTIONAL }
TrustAnchorInfoVersion ::= INTEGER { v1(1) }
TrustAnchorTitle ::= UTF8String (SIZE (1..64))
CertPathControls ::= SEQUENCE {
taName Name,
certificate [0] Certificate OPTIONAL,
policySet [1] CertificatePolicies OPTIONAL,
<span class="grey">Housley, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5914">RFC 5914</a> TAF June 2010</span>
policyFlags [2] CertPolicyFlags OPTIONAL,
nameConstr [3] NameConstraints OPTIONAL,
pathLenConstraint[4] INTEGER (0..MAX) OPTIONAL}
CertPolicyFlags ::= BIT STRING {
inhibitPolicyMapping (0),
requireExplicitPolicy (1),
inhibitAnyPolicy (2) }
TrustAnchorList ::= SEQUENCE SIZE (1..MAX) OF TrustAnchorChoice
TrustAnchorChoice ::= CHOICE {
certificate Certificate,
tbsCert [1] EXPLICIT TBSCertificate,
taInfo [2] EXPLICIT TrustAnchorInfo }
id-ct-trustAnchorList OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-smime(16) id-ct(1) 34 }
PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER
trust-anchor-list PKCS7-CONTENT-TYPE ::=
{ TrustAnchorList IDENTIFIED BY id-ct-trustAnchorList }
END
<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>. ASN.1 Module Using 1988 Syntax</span>
<a href="#appendix-A.2">Appendix A.2</a> provides the normative ASN.1 definitions for the
structures described in this specification using ASN.1 as defined in
[<a href="#ref-X.680" title=""ITU-T Recommendation X.680: Information Technology - Abstract Syntax Notation One"">X.680</a>].
<span class="h4"><a class="selflink" id="appendix-A.2.1" href="#appendix-A.2.1">A.2.1</a>. ASN.1 Module</span>
TrustAnchorInfoModule-88
{ joint-iso-ccitt(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) modules(0) 37 }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
Certificate, Name, Extensions,
SubjectPublicKeyInfo, TBSCertificate
FROM PKIX1Explicit88 -- from [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
<span class="grey">Housley, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5914">RFC 5914</a> TAF June 2010</span>
id-pkix1-explicit(18) }
CertificatePolicies, KeyIdentifier, NameConstraints
FROM PKIX1Implicit88 -- [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19) }
;
TrustAnchorInfo ::= SEQUENCE {
version TrustAnchorInfoVersion DEFAULT v1,
pubKey SubjectPublicKeyInfo,
keyId KeyIdentifier,
taTitle TrustAnchorTitle OPTIONAL,
certPath CertPathControls OPTIONAL,
exts [1] EXPLICIT Extensions OPTIONAL,
taTitleLangTag [2] UTF8String OPTIONAL }
TrustAnchorInfoVersion ::= INTEGER { v1(1) }
TrustAnchorTitle ::= UTF8String (SIZE (1..64))
CertPathControls ::= SEQUENCE {
taName Name,
certificate [0] Certificate OPTIONAL,
policySet [1] CertificatePolicies OPTIONAL,
policyFlags [2] CertPolicyFlags OPTIONAL,
nameConstr [3] NameConstraints OPTIONAL,
pathLenConstraint[4] INTEGER (0..MAX) OPTIONAL}
CertPolicyFlags ::= BIT STRING {
inhibitPolicyMapping (0),
requireExplicitPolicy (1),
inhibitAnyPolicy (2) }
TrustAnchorList ::= SEQUENCE SIZE (1..MAX) OF TrustAnchorChoice
TrustAnchorChoice ::= CHOICE {
certificate Certificate,
tbsCert [1] EXPLICIT TBSCertificate,
taInfo [2] EXPLICIT TrustAnchorInfo }
id-ct-trustAnchorList OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-smime(16) id-ct(1) 34 }
END
<span class="grey">Housley, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5914">RFC 5914</a> TAF June 2010</span>
Authors' Addresses
Russ Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
EMail: housley@vigilsec.com
Sam Ashmore
National Security Agency
Suite 6751
9800 Savage Road
Fort Meade, MD 20755
EMail: srashmo@radium.ncsc.mil
Carl Wallace
Cygnacom Solutions
Suite 5400
7925 Jones Branch Drive
McLean, VA 22102
EMail: cwallace@cygnacom.com
Housley, et al. Standards Track [Page 14]
</pre>
|
