forked from ietf-roll/anima-bootstrap-state-considerations
-
Notifications
You must be signed in to change notification settings - Fork 0
/
rfc3779.xml
1164 lines (1163 loc) · 52.6 KB
/
rfc3779.xml
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
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?><?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-ietf-xml2rfc-template-05" ipr="trust200902">
<front>
<title abbrev="Unknown(short)">Unknown</title>
<author fullname="Unknown Person" initials="X" role="editor"
surname="Unknown">
<organization>Not converted</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Unknown</city>
<region></region>
<code></code>
<country>Unknown</country>
</postal>
<phone>+1 234 5678 9012</phone>
<email>[email protected]</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author><date day="1" month="January" year="1900" />
</front>
<middle>
<section title=" Introduction"> <!-- 1, line 116-->
<t>This document defines two X.509 v3 certificate extensions that
authorize the transfer of the right-to-use for a set of IP addresses and
autonomous system identifiers from IANA through the regional Internet
registries (RIRs) to Internet service providers (ISPs) and user
organizations. The first binds a list of IP address blocks, often
represented as IP address prefixes, to the subject (private key
holder) of a certificate. The second binds a list of autonomous
system (AS) identifiers to the subject (private key holder) of a
certificate. The issuer of the certificate is an entity (e.g., the
IANA, a regional Internet registry, or an ISP) that has the authority
to transfer custodianship of ("allocate") the set of IP address
blocks and AS identifiers to the subject of the certificate. These
certificates provide a scalable means of verifying the right-to-use
for a set of IP address prefixes and AS identifiers. They may be used
by routing protocols, such as Secure BGP [S-BGP], to verify legitimacy and
correctness of routing information, or by Internet routing registries
to verify data that they receive.
</t>
<t>Sections 2 and 3 specify several rules about the encoding of the
extensions defined in this specification that MUST be followed.
These encoding rules serve the following purposes. First, they
result in a unique encoding of the extension's value; two instances
of an extension can be compared for equality octet-by-octet. Second,
they achieve the minimal size encoding of the information. Third,
they allow relying parties to use one-pass algorithms when performing
certification path validation; in particular, the relying parties do
not need to sort the information, or to implement extra code
in the subset checking algorithms to handle several boundary cases
(adjacent, overlapping, or subsumed ranges).
</t>
<section title=" Terminology"> <!-- 1.1, line 149-->
<t>It is assumed that the reader is familiar with the terms and concepts
described in "Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile" [RFC3280], "INTERNET
PROTOCOL" [RFC791], "Internet Protocol Version 6 (IPv6) Addressing
Architecture" [RFC3513], "INTERNET REGISTRY IP ALLOCATION
GUIDELINES" [RFC2050], and related regional Internet registry address
management policy documents. Some relevant terms include:
</t>
<t>allocate - the transfer of custodianship of a resource to an
intermediate organization (see [RFC2050]).
</t>
<t>assign - the transfer of custodianship of a resource to an end
organization (see [RFC2050]).
</t>
<t>Autonomous System (AS) - a set of routers under a single technical
administration with a uniform policy, using one or more interior
gateway protocols and metrics to determine how to route packets
within the autonomous system, and using an exterior gateway
protocol to determine how to route packets to other autonomous
systems.
</t>
<t>Autonomous System number - a 32-bit number that identifies an
autonomous system.
</t>
<t>delegate - transfer of custodianship (that is, the right-to-use) of an
IP address block or AS identifier through issuance of a
certificate to an entity.
</t>
<t>initial octet - the first octet in the value of a DER encoded BIT
STRING [X.690].
</t>
<t>IP v4 address - a 32-bit identifier written as four decimal numbers,
each in the range 0 to 255, separated by a ".". 10.5.0.5 is an
example of an IPv4 address.
</t>
<t>IP v6 address - a 128-bit identifier written as eight hexadecimal
quantities, each in the range 0 to ffff, separated by a ":".
2001:0:200:3:0:0:0:1 is an example of an IPv6 address. One string
of :0: fields may be replaced by "::", thus 2001:0:200:3::1
represents the same address as the immediately preceding example.
(See [RFC3513]).
</t>
<t>prefix - a bit string that consists of some number of initial bits of
an address, written as an address followed by a "/", and the
number of initial bits. 10.5.0.0/16 and 2001:0:200:3:0:0:0:0/64
(or 2001:0:200:3::/64) are examples of prefixes. A prefix is
often abbreviated by omitting the less-significant zero fields,
but there should be enough fields to contain the indicated number
of initial bits. 10.5/16 and 2001:0:200:3/64 are examples of
abbreviated prefixes.
</t>
<t>Regional Internet Registry (RIR) - any of the bodies recognized by
IANA as the regional authorities for management of IP addresses
and AS identifiers. At the time of writing, these include AfriNIC,
APNIC, ARIN, LACNIC, and RIPE NCC.
</t>
<t>right-to-use - for an IP address prefix, being authorized to specify
the AS that may originate advertisements of the prefix throughout
the Internet. For an autonomous system identifier, being
authorized to operate a network(s) that identifies itself to other
network operators using that autonomous system identifier.
</t>
<t>subsequent octets - the second through last octets in the value of a
DER encoded BIT STRING [X.690].
</t>
<t>trust anchor - a certificate that is to be trusted when performing
certification path validation (see [RFC3280]).
</t>
<t>The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, and MAY, and OPTIONAL, when they appear in
this document, are to be interpreted as described in [RFC2119].
</t>
</section> <!-- ends: "1.1 from line 149-->
</section> <!-- ends: "1 from line 116-->
<section title=" IP Address Delegation Extension"> <!-- 2, line 239-->
<t>This extension conveys the allocation of IP addresses to an entity by
binding those addresses to a public key belonging to the entity.
</t>
<section title=" Context"> <!-- 2.1, line 245-->
<t>IP address space is currently managed by a hierarchy nominally rooted
at IANA, but managed by the RIRs. IANA allocates IP address space to
the RIRs, who in turn allocate IP address space to Internet service
providers (ISPs), who may allocate IP address space to down stream
providers, customers, etc. The RIRs also may assign IP address space
to organizations who are end entities, i.e., organizations who will
not be reassigning any of their space to other organizations. (See
[RFC2050] and related RIR policy documents for the guidelines on the
allocation and assignment process).
</t>
<t>The IP address delegation extension is intended to enable
verification of the proper delegation of IP address blocks, i.e., of
the authorization of an entity to use or sub-allocate IP address
space. Accordingly, it makes sense to take advantage of the inherent
authoritativeness of the existing administrative framework for
allocating IP address space. As described in Section 1 above, this
will be achieved by issuing certificates carrying the extension
described in this section. An example of one use of the information
in this extension is an entity using it to verify the authorization
of an organization to originate a BGP UPDATE advertising a path to a
particular IP address block; see, e.g., [RFC1771], [S-BGP].
</t>
<section title=" Encoding of an IP Address or Prefix"> <!-- 2.1.1, line 270-->
<t>There are two families of IP addresses: IPv4 and IPv6.
</t>
<t>An IPv4 address is a 32-bit quantity that is written as four decimal
numbers, each in the range 0 through 255, separated by a dot
("."). 10.5.0.5 is an example of an IPv4 address.
An IPv6 address is a 128-bit quantity that is written as eight
hexadecimal numbers, each in the range 0 through ffff, separated by a
semicolon (":"); 2001:0:200:3:0:0:0:1 is an example of an IPv6
address. IPv6 addresses frequently have adjacent fields whose value
is 0. One such group of 0 fields may be abbreviated by two
semicolons ("::"). The previous example may thus be represented by
2001:0:200:3::1.
</t>
<t>An address prefix is a set of 2^k continuous addresses whose
most-significant bits are identical. For example, the set of 512 IPv4
addresses from 10.5.0.0 through 10.5.1.255 all have the same 23
most-significant bits. The set of addresses is written by appending a
slash ("/") and the number of constant bits to the lowest address in
the set. The prefix for the example set is 10.5.0.0/23, and contains
2^(32-23) = 2^9 addresses. The set of IPv6 addresses
2001:0:200:0:0:0:0:0 through 2001:0:3ff:ffff:ffff:ffff:ffff:ffff
(2^89 addresses) is represented by 2001:0:200:0:0:0:0:0/39 or
equivalently 2001:0:200::/39. A prefix may be abbreviated by
omitting the least-significant zero fields, but there should be enough
fields to contain the indicated number of constant bits. The
abbreviated forms of the example IPv4 prefix is 10.5.0/23, and of the
example IPv6 prefix is 2001:0:200/39.
</t>
<t>An IP address or prefix is encoded in the IP address delegation
extension as a DER-encoded ASN.1 BIT STRING containing the constant
most-significant bits. Recall [X.690] that the DER encoding of a BIT
STRING consists of the BIT STRING type (0x03), followed by (an
encoding of) the number of value octets, followed by the value. The
value consists of an "initial octet" that specifies the number of
unused bits in the last value octet, followed by the "subsequent
octets" that contain the octets of the bit string. (For IP
addresses, the encoding of the length will be just the length.)
</t>
<t>In the case of a single address, all the bits are constant, so the
bit string for an IPv4 address contains 32 bits. The subsequent
octets in the DER-encoding of the address 10.5.0.4 are 0x0a 0x05 0x00
0x04. Since all the bits in the last octet are used, the initial
octet is 0x00. The octets in the DER-encoded BIT STRING is thus:
</t>
<t>Type Len Unused Bits ...
0x03 0x05 0x00 0x0a 0x05 0x00 0x04
</t>
<t>Similarly, the DER-encoding of the prefix 10.5.0/23 is:
</t>
<t>Type Len Unused Bits ...
0x03 0x04 0x01 0x0a 0x05 0x00
In this case, the three subsequent octets contain 24 bits, but the
prefix only uses 23, so there is one unused bit in the last octet,
thus the initial octet is 1 (the DER require that all unused bits
MUST be set to zero-bits).
</t>
<t>The DER-encoding of the IPv6 address 2001:0:200:3:0:0:0:1 is:
</t>
<t>Type Len Unused Bits ...
0x03 0x11 0x00 0x20 0x01 0x00 0x00 0x02 0x00 0x00 0x03
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01
</t>
<t>and the DER-encoding of the prefix 2001:0:200/39, which has one
unused bit in the last octet, is:
</t>
<t>Type Len Unused Bits ...
0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02
</t>
</section> <!-- ends: "2.1.1 from line 270-->
<section title=" Encoding of a Range of IP Addresses"> <!-- 2.1.2, line 357-->
<t>While any contiguous range of IP addresses can be represented by a
set of contiguous prefixes, a more concise representation is achieved
by encoding the range as a SEQUENCE containing the lowest address and
the highest address, where each address is encoded as a BIT STRING.
Within the SEQUENCE, the bit string representing the lowest address
in the range is formed by removing all the least-significant zero-
bits from the address, and the bit string representing the highest
address in the range is formed by removing all the least-significant
one-bits. The DER BIT STRING encoding requires that all the unused
bits in the last octet MUST be set to zero-bits. Note that a prefix
can always be expressed as a range, but a range cannot always be
expressed as a prefix.
</t>
<t>The range of addresses represented by the prefix 10.5.0/23 is
10.5.0.0 through 10.5.1.255. The lowest address ends in sixteen
zero-bits that are removed. The DER-encoding of the resulting
sixteen-bit string is:
</t>
<t>Type Len Unused Bits ...
0x03 0x03 0x00 0x0a 0x05
</t>
<t>The highest address ends in nine one-bits that are removed. The DER-
encoding of the resulting twenty-three-bit string is:
</t>
<t>Type Len Unused Bits ...
0x03 0x04 0x01 0x0a 0x05 0x00
The prefix 2001:0:200/39 can be encoded as a range where the DER-
encoding of the lowest address (2001:0:200::) is:
</t>
<t>Type Len Unused Bits ...
0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02
</t>
<t>and the largest address (2001:0:3ff:ffff:ffff:ffff:ffff:ffff), which,
after removal of the ninety least-significant one-bits leaves a
thirty-eight bit string, is encoded as:
</t>
<t>Type Len Unused Bits ...
0x03 0x06 0x02 0x20 0x01 0x00 0x00 0x00
</t>
<t>The special case of all IP address blocks, i.e., a prefix of all
zero-bits -- "0/0", MUST be encoded per the DER with a length octet
of one, an initial octet of zero, and no subsequent octets:
</t>
<t>Type Len Unused Bits ...
0x03 0x01 0x00
</t>
<t>Note that for IP addresses the number of trailing zero-bits is
significant. For example, the DER-encoding of 10.64/12:
</t>
<t>Type Len Unused Bits ...
0x03 0x03 0x04 0x0a 0x40
</t>
<t>is different than the DER-encoding of 10.64.0/20:
</t>
<t>Type Len Unused Bits ...
0x03 0x04 0x04 0x0a 0x40 0x00
</t>
</section> <!-- ends: "2.1.2 from line 357-->
</section> <!-- ends: "2.1 from line 245-->
<section title=" Specification"> <!-- 2.2, line 445-->
<section title=" OID"> <!-- 2.2.1, line 448-->
<t>The OID for this extension is id-pe-ipAddrBlocks.
</t>
<t> id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
</t>
<t>where [RFC3280] defines:
</t>
<t> id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
</t>
<t> id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
</t>
</section> <!-- ends: "2.2.1 from line 448-->
<section title=" Criticality"> <!-- 2.2.2, line 463-->
<t>This extension SHOULD be CRITICAL. The intended use of this
extension is to connote a right-to-use for the block(s) of IP addresses
identified in the extension. A CA marks the extension as CRITICAL to
convey the notion that a relying party MUST understand the semantics
of the extension to make use of the certificate for the purpose it
was issued. Newly created applications that use certificates
containing this extension are expected to recognize the extension.
</t>
</section> <!-- ends: "2.2.2 from line 463-->
<section title=" Syntax"> <!-- 2.2.3, line 475-->
<t>id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
</t>
<t>IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
</t>
<t>IPAddressFamily ::= SEQUENCE { -- AFI & optional SAFI --
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }
</t>
<t>IPAddressChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
addressesOrRanges SEQUENCE OF IPAddressOrRange }
</t>
<t>IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
</t>
<t>IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
</t>
<t>IPAddress ::= BIT STRING
</t>
<section title=" Type IPAddrBlocks"> <!-- 2.2.3.1, line 502-->
<t>The IPAddrBlocks type is a SEQUENCE OF IPAddressFamily types.
</t>
</section> <!-- ends: "2.2.3.1 from line 502-->
<section title=" Type IPAddressFamily"> <!-- 2.2.3.2, line 507-->
<t>The IPAddressFamily type is a SEQUENCE containing an addressFamily
and ipAddressChoice element.
</t>
</section> <!-- ends: "2.2.3.2 from line 507-->
<section title=" Element addressFamily"> <!-- 2.2.3.3, line 513-->
<t>The addressFamily element is an OCTET STRING containing a two-octet
Address Family Identifier (AFI), in network byte order, optionally
followed by a one-octet Subsequent Address Family Identifier (SAFI).
AFIs and SAFIs are specified in [IANA-AFI] and [IANA-SAFI],
respectively.
</t>
<t>If no authorization is being granted for a particular AFI and
optional SAFI, then there MUST NOT be an IPAddressFamily member for
that AFI/SAFI in the IPAddrBlocks SEQUENCE.
</t>
<t>There MUST be only one IPAddressFamily SEQUENCE per unique
combination of AFI and SAFI. Each SEQUENCE MUST be ordered by
ascending addressFamily values (treating the octets as unsigned
quantities). An addressFamily without a SAFI MUST precede one that
contains an SAFI. When both IPv4 and IPv6 addresses are specified,
the IPv4 addresses MUST precede the IPv6 addresses (since the IPv4
AFI of 0001 is less than the IPv6 AFI of 0002).
</t>
</section> <!-- ends: "2.2.3.3 from line 513-->
<section title=" Element ipAddressChoice and Type IPAddressChoice"> <!-- 2.2.3.4, line 534-->
<t>The ipAddressChoice element is of type IPAddressChoice. The
IPAddressChoice type is a CHOICE of either an inherit or
addressesOrRanges element.
</t>
</section> <!-- ends: "2.2.3.4 from line 534-->
<section title=" Element inherit"> <!-- 2.2.3.5, line 541-->
<t>If the IPAddressChoice CHOICE contains the inherit element, then the
set of authorized IP addresses for the specified AFI and optional
SAFI is taken from the issuer's certificate, or from the issuer's issuer's
certificate, recursively, until a certificate containing an
IPAddressChoice containing an addressesOrRanges element is located.
</t>
</section> <!-- ends: "2.2.3.5 from line 541-->
<section title=" Element addressesOrRanges"> <!-- 2.2.3.6, line 550-->
<t>The addressesOrRanges element is a SEQUENCE OF IPAddressOrRange
types. The addressPrefix and addressRange elements MUST be sorted
using the binary representation of:
</t>
<t><lowest IP address in range> | <prefix length>
</t>
<t>where "|" represents concatenation. Note that the octets in this
representation (a.b.c.d | length for IPv4 or s:t:u:v:w:x:y:z | length
for IPv6) are not the octets that are in the DER-encoded BIT STRING
value. For example, given two addressPrefix:
IP addr | length DER encoding
---------------- ------------------------
Type Len Unused Bits...
10.32.0.0 | 12 03 03 04 0a 20
10.64.0.0 | 16 03 03 00 0a 40
</t>
<t>the prefix 10.32.0.0/12 MUST come before the prefix 10.64.0.0/16
since 32 is less than 64; whereas if one were to sort by the DER BIT
STRINGs, the order would be reversed as the unused bits octet would
sort in the opposite order. Any pair of IPAddressOrRange choices in
an extension MUST NOT overlap each other. Any contiguous address
prefixes or ranges MUST be combined into a single range or, whenever
possible, a single prefix.
</t>
</section> <!-- ends: "2.2.3.6 from line 550-->
<section title=" Type IPAddressOrRange"> <!-- 2.2.3.7, line 583-->
<t>The IPAddressOrRange type is a CHOICE of either an addressPrefix (an
IP prefix or address) or an addressRange (an IP address range)
element.
</t>
<t>This specification requires that any range of addresses that can be
encoded as a prefix MUST be encoded using an IPAddress element (a BIT
STRING), and any range that cannot be encoded as a prefix MUST be
encoded using an IPAddressRange (a SEQUENCE containing two BIT
STRINGs). The following pseudo code illustrates how to select the
encoding of a given range of addresses.
</t>
<t>LET N = the number of matching most-significant bits in the
lowest and highest addresses of the range
IF all the remaining bits in the lowest address are zero-bits
AND all the remaining bits in the highest address are one-bits
THEN the range MUST be encoded as an N-bit IPAddress
ELSE the range MUST be encoded as an IPAddressRange
</t>
</section> <!-- ends: "2.2.3.7 from line 583-->
<section title=" Element addressPrefix and Type IPAddress"> <!-- 2.2.3.8, line 608-->
<t>The addressPrefix element is an IPAddress type. The IPAddress type
defines a range of IP addresses in which the most-significant (left-
most) N bits of the address remain constant, while the remaining bits
(32 - N bits for IPv4, or 128 - N bits for IPv6) may be either zero
or one. For example, the IPv4 prefix 10.64/12 corresponds to the
addresses 10.64.0.0 to 10.79.255.255, while 10.64/11 corresponds to
10.64.0.0 to 10.95.255.255. The IPv6 prefix 2001:0:2/48 represents
addresses 2001:0:2:: to 2001:0:2:ffff:ffff:ffff:ffff:ffff.
</t>
<t>An IP address prefix is encoded as a BIT STRING. The DER encoding of
a BIT STRING uses the initial octet of the string to specify how many
of the least-significant bits of the last subsequent octet are
unused. The DER encoding specifies that these unused bits MUST be
set to zero-bits.
</t>
<t>Example:
128.0.0.0 = 1000 0000.0000 0000.0000 0000.0000 0000
to 143.255 255 255 = 1000 1111.1111 1111.1111 1111.1111 1111
bit string to encode = 1000
Type Len Unused Bits ...
Encoding = 0x03 0x02 0x04 0x80
</t>
</section> <!-- ends: "2.2.3.8 from line 608-->
<section title=" Element addressRange and Type IPAddressRange"> <!-- 2.2.3.9, line 635-->
<t>The addressRange element is of type IPAddressRange. The
IPAddressRange type consists of a SEQUENCE containing a minimum
(element min) and maximum (element max) IP address. Each IP address
is encoded as a BIT STRING. The semantic interpretation of the
minimum address in an IPAddressRange is that all the unspecified bits
(for the full length of the IP address) are zero-bits. The semantic
interpretation of the maximum address is that all the unspecified
bits are one-bits. The BIT STRING for the minimum address results
from removing all the least-significant zero-bits from the minimum
address. The BIT STRING for the maximum address results from
removing all the least-significant one-bits from the maximum address.
</t>
<t>Example:
129.64.0.0 = 1000 0001.0100 0000.0000 0000.0000 0000
to 143.255.255.255 = 1000 1111.1111 1111.1111 1111.1111 1111
minimum bit string = 1000 0001.01
maximum bit string = 1000
Encoding = SEQUENCE {
Type Len Unused Bits ...
min 0x03 0x03 0x06 0x81 0x40
max 0x03 0x02 0x04 0x80
}
</t>
<t>To simplify the comparison of IP address blocks when performing
certification path validation, a maximum IP address MUST contain at
least one bit whose value is 1, i.e., the subsequent octets may
not be omitted nor all zero.
</t>
</section> <!-- ends: "2.2.3.9 from line 635-->
</section> <!-- ends: "2.2.3 from line 475-->
</section> <!-- ends: "2.2 from line 445-->
<section title=" IP Address Delegation Extension Certification Path Validation"> <!-- 2.3, line 668-->
<t>Certification path validation of a certificate containing the IP
address delegation extension requires additional processing. As each
certificate in a path is validated, the IP addresses in the IP
address delegation extension of that certificate MUST be subsumed by
IP addresses in the IP address delegation extension in the issuer's
certificate. Validation MUST fail when this is not the case. A
certificate that is a trust anchor for certification path validation
of certificates containing the IP address delegation extension, as
well as all certificates along the path, MUST each contain the IP
address delegation extension. The initial set of allowed address
ranges is taken from the trust anchor certificate.
</t>
</section> <!-- ends: "2.3 from line 668-->
</section> <!-- ends: "2 from line 239-->
<section title=" Autonomous System Identifier Delegation Extension"> <!-- 3, line 683-->
<t>This extension conveys the allocation of autonomous system (AS)
identifiers to an entity by binding those AS identifiers to a public
key belonging to the entity.
</t>
<section title=" Context"> <!-- 3.1, line 690-->
<t>AS identifier delegation is currently managed by a hierarchy
nominally rooted at IANA, but managed by the RIRs. IANA allocates AS
identifiers to the RIRs, who in turn assign AS identifiers to
organizations who are end entities, i.e., will not be re-allocating
any of their AS identifiers to other organizations. The AS
identifier delegation extension is intended to enable verification of
the proper delegation of AS identifiers, i.e., of the authorization
of an entity to use these AS identifiers. Accordingly, it makes
sense to take advantage of the inherent authoritativeness of the
existing administrative framework for management of AS identifiers. As
described in Section 1 above, this will be achieved by issuing
certificates carrying the extension described in this section. An
example of one use of the information in this extension is an entity
using it to verify the authorization of an organization to manage the
AS identified by an AS identifier in the extension. The use of this
extension to represent assignment of AS identifiers is not intended to
alter the procedures by which AS identifiers are managed, or when an AS
should be used c.f., [RFC1930].
</t>
</section> <!-- ends: "3.1 from line 690-->
<section title=" Specification"> <!-- 3.2, line 712-->
<section title=" OID"> <!-- 3.2.1, line 715-->
<t>The OID for this extension is id-pe-autonomousSysIds.
</t>
<t> id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
</t>
<t>where [RFC3280] defines:
</t>
<t> id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
</t>
<t> id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
</t>
</section> <!-- ends: "3.2.1 from line 715-->
<section title=" Criticality"> <!-- 3.2.2, line 731-->
<t>This extension SHOULD be CRITICAL. The intended use of this
extension is to connote a right-to-use for the AS identifiers in the
extension. A CA marks the extension as CRITICAL to convey the notion
that a relying party must understand the semantics of the extension
to make use of the certificate for the purpose it was issued. Newly
created applications that use certificates containing this extension
are expected to recognize the extension.
</t>
</section> <!-- ends: "3.2.2 from line 731-->
<section title=" Syntax"> <!-- 3.2.3, line 742-->
<t>id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
</t>
<t>ASIdentifiers ::= SEQUENCE {
asnum [0] EXPLICIT ASIdentifierChoice OPTIONAL,
rdi [1] EXPLICIT ASIdentifierChoice OPTIONAL}
</t>
<t>ASIdentifierChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
asIdsOrRanges SEQUENCE OF ASIdOrRange }
</t>
<t>ASIdOrRange ::= CHOICE {
id ASId,
range ASRange }
</t>
<t>ASRange ::= SEQUENCE {
min ASId,
max ASId }
</t>
<t>ASId ::= INTEGER
</t>
<section title=" Type ASIdentifiers"> <!-- 3.2.3.1, line 767-->
<t>The ASIdentifiers type is a SEQUENCE containing one or more forms of
autonomous system identifiers -- AS numbers (in the asnum element) or
routing domain identifiers (in the rdi element). When the
ASIdentifiers type contains multiple forms of identifiers, the asnum
entry MUST precede the rdi entry. AS numbers are used by BGP, and
routing domain identifiers are specified in the IDRP [RFC1142].
</t>
</section> <!-- ends: "3.2.3.1 from line 767-->
<section title=" Elements asnum, rdi, and Type ASIdentifierChoice"> <!-- 3.2.3.2, line 777-->
<t>The asnum and rdi elements are both of type ASIdentifierChoice. The
ASIdentifierChoice type is a CHOICE of either the inherit or
asIdsOrRanges element.
</t>
</section> <!-- ends: "3.2.3.2 from line 777-->
<section title=" Element inherit"> <!-- 3.2.3.3, line 784-->
<t>If the ASIdentifierChoice choice contains the inherit element, then
the set of authorized AS identifiers is taken from the issuer's
certificate, or from the issuer's issuer's certificate, recursively, until
a certificate containing an ASIdentifierChoice containing an
asIdsOrRanges element is located. If no authorization is being
granted for a particular form of AS identifier, then there MUST NOT be
a corresponding asnum/rdi member in the ASIdentifiers sequence.
</t>
</section> <!-- ends: "3.2.3.3 from line 784-->
<section title=" Element asIdsOrRanges"> <!-- 3.2.3.4, line 795-->
<t>The asIdsOrRanges element is a SEQUENCE of ASIdOrRange types. Any
pair of items in the asIdsOrRanges SEQUENCE MUST NOT overlap. Any
contiguous series of AS identifiers MUST be combined into a single range
whenever possible. The AS identifiers in the asIdsOrRanges element
MUST be sorted by increasing numeric value.
</t>
</section> <!-- ends: "3.2.3.4 from line 795-->
<section title=" Type ASIdOrRange"> <!-- 3.2.3.5, line 804-->
<t>The ASIdOrRange type is a CHOICE of either a single integer (ASId) or
a single sequence (ASRange).
</t>
</section> <!-- ends: "3.2.3.5 from line 804-->
<section title=" Element id"> <!-- 3.2.3.6, line 810-->
<t>The id element has type ASId.
</t>
</section> <!-- ends: "3.2.3.6 from line 810-->
<section title=" Element range"> <!-- 3.2.3.7, line 815-->
<t>The range element has type ASRange.
</t>
</section> <!-- ends: "3.2.3.7 from line 815-->
<section title=" Type ASRange"> <!-- 3.2.3.8, line 820-->
<t>The ASRange type is a SEQUENCE consisting of a min and a max element,
and is used to specify a range of AS identifier values.
</t>
</section> <!-- ends: "3.2.3.8 from line 820-->
<section title=" Elements min and max"> <!-- 3.2.3.9, line 826-->
<t>The min and max elements have type ASId. The min element is used to
specify the value of the minimum AS identifier in the range, and the
max element specifies the value of the maximum AS identifier in the
range.
</t>
</section> <!-- ends: "3.2.3.9 from line 826-->
<section title=" Type ASId"> <!-- 3.2.3.10, line 834-->
<t>The ASId type is an INTEGER.
</t>
</section> <!-- ends: "3.2.3.10 from line 834-->
</section> <!-- ends: "3.2.3 from line 742-->
</section> <!-- ends: "3.2 from line 712-->
<section title=" Autonomous System Identifier Delegation Extension Certification"> <!-- 3.3, line 839-->
<t>Path Validation
</t>
<t>Certification path validation of a certificate containing the
autonomous system identifier delegation extension requires additional
processing. As each certificate in a path is validated, the AS
identifiers in the autonomous system identifier delegation extension
of that certificate MUST be subsumed by the AS identifiers in the
autonomous system identifier delegation extension in the issuer's
certificate. Validation MUST fail when this is not the case. A
certificate that is a trust anchor for certification path validation
of certificates containing the autonomous system identifier
delegation extension, as well as all certificates along the path,
MUST each contain the autonomous system identifier delegation
extension. The initial set of allowed AS identifiers is taken from
the trust anchor certificate.
</t>
</section> <!-- ends: "3.3 from line 839-->
</section> <!-- ends: "3 from line 683-->
<section title=" Security Considerations"> <!-- 4, line 858-->
<t>This specification describes two X.509 extensions. Since X.509
certificates are digitally signed, no additional integrity service is
necessary. Certificates with these extensions need not be kept
secret, and unrestricted and anonymous access to these certificates
has no security implications.
</t>
<t>However, security factors outside the scope of this specification
will affect the assurance provided to certificate users. This
section highlights critical issues that should be considered by
implementors, administrators, and users.
</t>
<t>These extensions represent authorization information, i.e., a
right-to-use for IP addresses or AS identifiers. They were developed to
support a secure version of BGP [S-BGP], but may be employed in other
contexts. In the secure BGP context, certificates containing these
extensions function as capabilities: the certificate asserts that the
holder of the private key (the Subject) is authorized to use the IP
addresses or AS identifiers represented in the extension(s). As a
result of this capability model, the Subject field is largely
irrelevant for security purposes, contrary to common PKI conventions.
</t>
</section> <!-- ends: "4 from line 858-->
<section title=" Acknowledgments"> <!-- 5, line 882-->
<t>The authors would like to acknowledge the contributions to this
specification by Charles Gardiner, Russ Housley, James Manger, and
Jim Schaad.
</t>
<t>Appendix A -- ASN.1 Module
</t>
<t>This normative appendix describes the IP address and AS identifiers
extensions used by conforming PKI components in ASN.1 syntax.
</t>
<t>IPAddrAndASCertExtn { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
id-mod-ip-addr-and-as-ident(30) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- Copyright (C) The Internet Society (2004). This --
-- version of this ASN.1 module is part of RFC 3779; --
-- see the RFC itself for full legal notices. --
</t>
<t>-- EXPORTS ALL --
</t>
<t>IMPORTS
</t>
<t>-- PKIX specific OIDs and arcs --
id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) };
</t>
<t>-- IP Address Delegation Extension OID --
</t>
<t>id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
</t>
<t>-- IP Address Delegation Extension Syntax --
</t>
<t>IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
</t>
<t>IPAddressFamily ::= SEQUENCE { -- AFI & opt SAFI --
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }
</t>
<t>IPAddressChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
addressesOrRanges SEQUENCE OF IPAddressOrRange }
</t>
<t>IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
</t>
<t>IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
</t>
<t>IPAddress ::= BIT STRING
</t>
<t>-- Autonomous System Identifier Delegation Extension OID --
</t>
<t>id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
</t>
<t>-- Autonomous System Identifier Delegation Extension Syntax --
</t>
<t>ASIdentifiers ::= SEQUENCE {
asnum [0] ASIdentifierChoice OPTIONAL,
rdi [1] ASIdentifierChoice OPTIONAL }
</t>
<t>ASIdentifierChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
asIdsOrRanges SEQUENCE OF ASIdOrRange }
</t>
<t>ASIdOrRange ::= CHOICE {
id ASId,
range ASRange }
</t>
<t>ASRange ::= SEQUENCE {
min ASId,
max ASId }
</t>
<t>ASId ::= INTEGER
</t>
<t>END
</t>
<t>Appendix B -- Examples of IP Address Delegation Extensions
</t>
<t>A critical X.509 v3 certificate extension that specifies:
IPv4 unicast address prefixes
1) 10.0.32/20 i.e., 10.0.32.0 to 10.0.47.255
2) 10.0.64/24 i.e., 10.0.64.0 to 10.0.64.255
3) 10.1/16 i.e., 10.1.0.0 to 10.1.255.255
4) 10.2.48/20 i.e., 10.2.48.0 to 10.2.63.255
5) 10.2.64/24 i.e., 10.2.64.0 to 10.2.64.255
6) 10.3/16 i.e., 10.3.0.0 to 10.3.255.255, and
7) inherits all IPv6 addresses from the issuer's certificate
would be (in hexadecimal):
</t>
<t>30 46 Extension {
06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7
01 01 ff critical
04 37 extnValue {
30 35 IPAddrBlocks {
30 2b IPAddressFamily {
04 03 0001 01 addressFamily: IPv4 Unicast
IPAddressChoice
30 24 addressesOrRanges {
IPAddressOrRange
03 04 04 0a0020 addressPrefix 10.0.32/20
IPAddressOrRange
03 04 00 0a0040 addressPrefix 10.0.64/24
IPAddressOrRange
03 03 00 0a01 addressPrefix 10.1/16
IPAddressOrRange
30 0c addressRange {
03 04 04 0a0230 min 10.2.48.0
03 04 00 0a0240 max 10.2.64.255
} -- addressRange
IPAddressOrRange
03 03 00 0a03 addressPrefix 10.3/16
} -- addressesOrRanges
} -- IPAddressFamily
30 06 IPAddressFamily {
04 02 0002 addressFamily: IPv6
IPAddressChoice
05 00 inherit from issuer
} -- IPAddressFamily
} -- IPAddrBlocks
} -- extnValue
} -- Extension
</t>
<t>This example illustrates how the prefixes and ranges are sorted.
</t>
<t>+ Prefix 1 MUST precede prefix 2, even though the number of unused
bits (4) in prefix 1 is larger than the number of unused bits (0)
in prefix 2.
</t>
<t>+ Prefix 2 MUST precede prefix 3 even though the number of octets
(4) in the BIT STRING encoding of prefix 2 is larger than the
number of octets (3) in the BIT STRING encoding of prefix 3.
</t>
<t>+ Prefixes 4 and 5 are adjacent (representing the range of addresses
from 10.2.48.0 to 10.2.64.255), so MUST be combined into a range
(since the range cannot be encoded by a single prefix).
</t>
<t>+ Note that the six trailing zero bits in the max element of the
range are significant to the semantic interpretation of the value
(as all unused bits are interpreted to be 1's, not 0's). The four
trailing zero bits in the min element are not significant and MUST
be removed (thus the (4) unused bits in the encoding of the min
element). (DER encoding requires that any unused bits in the last
subsequent octet MUST be set to zero.)
</t>
<t>+ The range formed by prefixes 4 and 5 MUST precede prefix 6 even
though the SEQUENCE tag for a range (30) is larger than the tag
for the BIT STRING (03) used to encode prefix 6.
</t>
<t>+ The IPv4 information MUST precede the IPv6 information since the
address family identifier for IPv4 (0001) is less than the
identifier for IPv6 (0002).
</t>
<t>An extension specifying the IPv6 prefix 2001:0:2/48 and the IPv4
prefixes 10/8 and 172.16/12, and which inherits all IPv4 multicast
addresses from the issuer's certificate would be (in hexadecimal):
</t>
<t>30 3d Extension {
06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7
01 01 ff critical
04 2e extnValue {
30 2c IPAddrBlocks {
30 10 IPAddressFamily {
04 03 0001 01 addressFamily: IPv4 Unicast
IPAddressChoice
30 09 addressesOrRanges {
IPAddressOrRange
03 02 00 0a addressPrefix 10/8
IPAddressOrRange
03 03 04 b010 addressPrefix 172.16/12
} -- addressesOrRanges
} -- IPAddressFamily
30 07 IPAddressFamily {
04 03 0001 02 addressFamily: IPv4 Multicast
IPAddressChoice
05 00 inherit from issuer
} -- IPAddressFamily
30 0f IPAddressFamily {
04 02 0002 addressFamily: IPv6
IPAddressChoice
30 09 addressesOrRanges {
IPAddressOrRange
03 07 00 200100000002 addressPrefix 2001:0:2/47
} -- addressesOrRanges
} -- IPAddressFamily
} -- IPAddrBlocks
} -- extnValue
} -- Extension
</t>
<t>Appendix C -- Example of an AS Identifier Delegation Extension
</t>
<t>An extension that specifies AS numbers 135, 3000 to 3999, and 5001,
and which inherits all routing domain identifiers from the issuer's
certificate would be (in hexadecimal):
</t>
<t>30 2b Extension {
06 08 2b06010505070108 extnID 1.3.6.1.5.5.7.1.8
01 01 ff critical
04 1c extnValue {
30 1a ASIdentifiers {
a0 14 asnum
ASIdentifierChoice
30 12 asIdsOrRanges {
ASIdOrRange
02 02 0087 ASId
ASIdOrRange
30 08 ASRange {
02 02 0bb8 min
02 02 0f9f max
} -- ASRange
ASIdOrRange
02 02 1389 ASId
} -- asIdsOrRanges
} -- asnum
a1 02 rdi {
ASIdentifierChoice
05 00 inherit from issuer
} -- rdi
} -- ASIdentifiers
} -- extnValue
} -- Extension
</t>
<t>Appendix D -- Use of X.509 Attribute Certificates
</t>
<t>This appendix discusses issues arising from a proposal to use
attribute certificates (ACs, as specified in [RFC3281]) to convey,
from the Regional Internet Registries (RIRs) to the end-user
organizations, the "right-to-use" for IP address blocks or AS
identifiers.
</t>
<t>The two resources, AS identifiers and IP address blocks, are
currently managed differently. All organizations with the
right-to-use for an AS identifier receive the authorization directly from
an RIR. Organizations with a right-to-use for an IP address block receive the
authorization either directly from an RIR, or indirectly, e.g., from
a down stream service provider, who might receive its authorization
from an Internet service provider, who in turn gets its authorization
from a RIR. Note that AS identifiers might be sub-allocated in the
future, so the mechanisms used should not rely upon a three level
hierarchy.
</t>
<t>In section 1 of RFC 3281, two reasons are given for why the use of ACs
might be preferable to the use of public key certificates (PKCs) with
extensions that convey the authorization information:
</t>
<t>"Authorization information may be placed in a PKC extension or
placed in a separate attribute certificate (AC). The placement of
authorization information in PKCs is usually undesirable for two
reasons. First, authorization information often does not have the
same lifetime as the binding of the identity and the public key.
When authorization information is placed in a PKC extension, the
general result is the shortening of the PKC useful lifetime.
Second, the PKC issuer is not usually authoritative for the
authorization information. This results in additional steps for
the PKC issuer to obtain authorization information from the
authoritative source."
</t>
<t>"For these reasons, it is often better to separate authorization
information from the PKC. Yet, authorization information also
needs to be bound to an identity. An AC provides this binding; it
is simply a digitally signed (or certified) identity and set of
attributes."
</t>
<t>In the case of the IP address and AS identifier authorizations, these
reasons do not apply. First, the public key certificates are issued
exclusively for authorization, so the certificate lifetime
corresponds exactly to the authorization lifetime, which is often
tied to a contractual relationship between the issuer and entity
receiving the authorization. The Subject and Issuer names are only
used for chaining during certification path validation, and the names
need not correspond to any physical entity. The Subject name in the
PKCs may actually be randomly assigned by the issuing CA, allowing
the resource holder limited anonymity. Second, the certificate
hierarchy is constructed so that the certificate issuer is
authoritative for the authorization information.
</t>
<t>Thus the two points in the first cited paragraph above are not true
in the case of AS number and IP address block allocations. The point
of the second cited paragraph is also not applicable as the resources
are not being bound to an identity but to the holder of the private
key corresponding to the public key in the PKC.
</t>
<t>RFC 3281 specifies several requirements that a conformant Attribute
Certificate must meet. In relation to S-BGP, the more-significant
requirements are:
</t>
<t>1 from section 1: "this specification does NOT RECOMMEND the use of
AC chains. Other (future) specifications may address the use of
AC chains."
</t>
<t>Allocation from IANA to RIRs to ISPs to DSPs and assignment to end
organizations would require the use of chains, at least for IP address
blocks. A description of how the superior's AC should be located and
how it should be processed would have to be provided. Readers of this
document are encouraged to propose ways the chaining might be
avoided.
</t>
<t>2 from section 4.2.9: "section 4.3 defines the extensions that MAY
be used with this profile, and whether or not they may be marked
critical. If any other critical extension is used, the AC does
not conform to this profile. However, if any other non-critical
extension is used, the AC does conform to this profile."
</t>
<t>This means that the delegation extensions defined in this
specification, which are critical, could not be simply placed into
an AC. They could be used if not marked critical, but the
intended use requires that the extensions be critical so that the
certificates containing them cannot be used as identity
certificates by an unsuspecting application.
</t>
<t>3 from section 4.5: "an AC issuer, MUST NOT also be a PKC
issuer. That is, an AC issuer cannot be a CA as well."
</t>
<t>This means that for each AC issuer there would need to be a
separate CA to issue the PKC that contains the public key of the
AC holder. The AC issuer cannot issue the PKC of the holder, and
the PKC issuer cannot sign the AC. Thus, each entity in the PKI