-
Notifications
You must be signed in to change notification settings - Fork 2
/
draft-ounsworth-pkix-key-attestation.txt
1176 lines (725 loc) · 40.3 KB
/
draft-ounsworth-pkix-key-attestation.txt
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
LAMPS M. Ounsworth
Internet-Draft Entrust
Intended status: Standards Track R. Kettlewell
Expires: 14 September 2023 Entrust - nCipher
B. Couillard
JP Fiset
Crypto4A
13 March 2023
PKIX Key Attestation Format
draft-ounsworth-pkix-key-attestation-02
Abstract
This document describes syntax for conveying key origin attestation
information to a Certification Authority (CA) or other entity, so
that they may decide how much trust to place in the management of the
private key. For example, a reliant party may use this information
to support a decision about whether to issue a certificate. In
contrast to other key attestation formats, the one defined in this
document requires only ASN.1 and the standard PKIX modules.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ounsworth-pkix-key-
attestation/.
Discussion of this document takes place on the Limited Additional
Mechanisms for PKIX and SMIME (lamps) Working Group mailing list
(mailto:[email protected]), which is archived at
https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at
https://www.ietf.org/mailman/listinfo/spasm/.
Source for this draft and an issue tracker can be found at
https://github.com/EntrustCorporation/draft-ounsworth-pq-composite-
keys.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Ounsworth, et al. Expires 14 September 2023 [Page 1]
Internet-Draft PKIX Key Attestation March 2023
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 14 September 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) 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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Cryptographic Keys . . . . . . . . . . . . . . . . . . . . . 4
3.1. Trust Anchor Key . . . . . . . . . . . . . . . . . . . . 4
3.2. Intermediate CA Key . . . . . . . . . . . . . . . . . . . 4
3.3. Device Identity Key . . . . . . . . . . . . . . . . . . . 5
3.4. Device Certification Subkey . . . . . . . . . . . . . . . 5
3.5. Application Key . . . . . . . . . . . . . . . . . . . . . 6
4. Key Attestations . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Key Attestation Bundle . . . . . . . . . . . . . . . . . 6
4.2. Intermediate CA Certificate . . . . . . . . . . . . . . . 7
4.3. Device Identity Certificate . . . . . . . . . . . . . . . 8
4.4. Device Delegation Certificate . . . . . . . . . . . . . . 9
4.5. Key Attestation Certificate . . . . . . . . . . . . . . . 10
4.5.1. Vendor-Specific Information . . . . . . . . . . . . . 11
5. Key Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Distinctions between Key Use Policies . . . . . . . . . . 13
5.2. Recoverable Keys . . . . . . . . . . . . . . . . . . . . 13
5.3. Key Protection . . . . . . . . . . . . . . . . . . . . . 13
5.4. Vendor-Defined Key Use Policies . . . . . . . . . . . . . 14
Ounsworth, et al. Expires 14 September 2023 [Page 2]
Internet-Draft PKIX Key Attestation March 2023
6. Embedding Key Attestations in Certification Requests . . . . 14
7. Implementation Considerations . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9.1. Key Use Constraints . . . . . . . . . . . . . . . . . . . 16
9.2. Verification Model . . . . . . . . . . . . . . . . . . . 16
9.3. Recoverable Keys . . . . . . . . . . . . . . . . . . . . 17
9.4. Uniqueness of Keys . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Samples . . . . . . . . . . . . . . . . . . . . . . 18
Appendix B. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 18
Appendix C. Intellectual Property Considerations . . . . . . . . 19
Appendix D. Contributors and Acknowledgements . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
Key attestation refers to the originator of a cryptographic key pair
providing information about the provenance of that key pair, in a
manner that can be cryptographically verified. The information
provided may include, for example, the model and identity of the
device that created the key pair and any policies that may be
enforced upon the use of the private key, contained in a
cryptographic envelope that can be chained to a manufacturing public
key of the device vendor.
This information can be used by a Certification Authority (CA) to
decide whether to issue a certificate, to apply a given policy or
certificate template, or by other entities for their own purposes.
The CA may choose to publish some or all of the key attestation data
in the certificate for the use of parties that will rely on this
certificate.
Many devices, including Hardware Security Modules, provide
attestation information of some form in proprietary formats. A
common syntax for key attestations is required to reduce the
implementation burden on CA implementors and operators. Furthermore
it is desirable that the syntax is sympathetic to existing CA
implementations.
Ounsworth, et al. Expires 14 September 2023 [Page 3]
Internet-Draft PKIX Key Attestation March 2023
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Cryptographic Keys
This section describes the cryptographic keys referenced in this
document.
3.1. Trust Anchor Key
A trust anchor key is a signing key held by a vendor. For the
purposes of this document, a trust anchor may be a proper Trust
Anchor as defined in [RFC5914], or a root certification authority as
defined in [RFC5280]. It is used either to directly sign device
identity keys as defined in Section 3.3 or to sign intermediate CA
keys. A trust anchor key MUST be associated with a vendor identity.
Constraints:
* A trust anchor key MUST only be used for purposes consistent with
signing intermediate CA keys or devices (i.e. signing delegation
certificates, CRLs, etc).
3.2. Intermediate CA Key
An intermediate CA key is a signing key held by a vendor and
certified by that vendor's trust anchor.
It can be used for one of two purposes:
* To certify device identity keys (see Section 3.3) by signing
device identity certificates (see Section 4.3)
* To certify further intermediate CA keys
The exact configuration and management of trust anchor keys and
intermediate CA keys is beyond the scope of this document. An
example configuration is that a vendor have an offline trust anchor,
and an intermediate CA in each of its manufacturing sites, certified
by the trust anchor key when a manufacturing site is created or
during maintenance or recovery activities.
Ounsworth, et al. Expires 14 September 2023 [Page 4]
Internet-Draft PKIX Key Attestation March 2023
It may be impossible recertify a device after manufacture, and it may
be impossible for a manufacturer to know when a device has been
retired from use. Therefore:
* An intermediate CA need not track and public revocation
information
* Intermediate CA keys MAY have an expiration date of
99991231235959Z ([RFC5280] section 4.1.2.5).
Constraints:
* An intermediate CA key MUST only be used for purposes consistent
with certifying intermediate CA keys (i.e. signing delegation
certificates, CRLs, etc) or devices.
3.3. Device Identity Key
A device identity key is a signing key held by a device. It is
assumed that the key is unique to the device and cannot be extracted
or used for any purpose other than the ones listed below. It is
envisaged that this key will persist for the lifetime of the device.
It can be used for one of two purposes:
* To sign key attestations directly
* To sign device delegation certificates (see Section 4.4), which
are used to certify device certification subkeys (see
Section 3.4).
Constraints:
* A device identity key MUST NOT be used for any purpose other than
signing key attestation certificates or device delegation
certificates.
3.4. Device Certification Subkey
A device certification key is a signing key held by a device. It is
assumed that the key is unique to the device and cannot be extracted
or used for any purpose other than the ones listed below. Depending
on the device architecture, it may also be limited to a particular
context or partition of the device; in this case it is assumed to be
unique to the context. A device certification key may have any
lifetime, from single use to the lifetime of the device.
It can be used for one of two purposes:
Ounsworth, et al. Expires 14 September 2023 [Page 5]
Internet-Draft PKIX Key Attestation March 2023
* To sign key attestations directly
* To sign further device delegation certificates.
Constraints:
* A device certification subkey MUST NOT be used for any purpose
other than signing key attestation certificates (see Section 4.5)
or device delegation certificates (see Section 4.4).
3.5. Application Key
An application key is a key created and managed by a device
(excluding the device identity key and device certification subkey
described above). Its purpose and lifetime are arbitrary - in other
words, it can be used for any purpose a user of the device wishes.
_(MikeO: maybe I'm a noob here, but the distinction between this an a
Device Certification Subkey could be stated more clearly. Maybe the
distinction "This is envisioned for cases where a device needs an
attested key which may be used for arbitrary purposes".)_
_(RJK: it's not really about what the device desires - these are the
keys that we are trying to attest the origin of. The user has some
higher-level purpose, e.g. code signing, which requires them to
define a code signing key and attest to its origins in an HSM; from
the point of view of this spec, their code-signing key is an
application key. Keeping this comment open in the hope we can find a
clear way of articulating this.)_
4. Key Attestations
A verifier is an entity which wishes to verify the origin of a key,
based on its trust in a trust anchor.
For example, it could be a certificate authority with an operational
constraint that it only certifies hardware-protected keys.
4.1. Key Attestation Bundle
A key attestation consists of a nonempty sequence of [RFC5280]
certificates, containing key attestation extensions as described
below.
Specifically, a key attestation consists of:
* Zero or more intermediate certificates (see Section 4.2)
Ounsworth, et al. Expires 14 September 2023 [Page 6]
Internet-Draft PKIX Key Attestation March 2023
* Exactly one device identity certificate (see Section 4.3)
* Zero or more device delegation certificates (see Section 4.4)
* Exactly one key attestation certificate (see Section 4.5)
The first certificate (whether it is an intermediate certificate or
the device identity certificate) is signed by a trust anchor key. A
verifier must decide through its own policies and processes which
trust anchors keys to trust and what policies to accept in key
attestations certified by them. A trust anchor key MUST be
associated with a vendor identity.
Constraints:
* A verifier MUST verify that each certificate is well-formed
(except that expiry and revocation information need not be
present)
* A verifier MUST verify that the first certificate is signed by a
trust anchor key
* A verifier MUST verify that each certificate, apart from the
first, is certified by the previous certificate in the key
attestation.
* A verifier MUST verify that the ordering of certificates is as
described above.
4.2. Intermediate CA Certificate
An intermediate CA delegation certificate certifies an intermediate
CA. Apart from the absence of any constraints on expiry time and
revocation, it is little different from any other intermediate CA's
certificate.
It MUST have the [RFC5280] basic constraints extension with the cA
boolean set to true.
It MAY have the [RFC5280] pathLenConstraint, and there is no change
to the [RFC5280] interpretation this field. Therefore, if it is
present, it must permit sufficiently many following certificates to
account for certificates signed by the device i.e. device identity
certificates (see Section 4.3) and device delegation certificates
(see Section 4.4).
Ounsworth, et al. Expires 14 September 2023 [Page 7]
Internet-Draft PKIX Key Attestation March 2023
It MUST NOT have any of the extensions defined in the following
sections (Section 4.3, Section 4.4 and Section 4.5). A verifier may
detect an intermediate CA delegation by the presence of a true cA
boolean and the absence of these extensions.
Constraints:
* A verifier MUST honor pathLenConstraint if present.
* There may be any number of intermediate CA certificates, including
0.
4.3. Device Identity Certificate
A device identity certificate certifies a specific device by binding
its public device identity key (defined in Section 3.3) to a vendor-
specific representation of device identity such as vendor name,
model, and serial number. For a hardware device, it is envisaged
that a manufacturing facility will use its trust anchor or
intermediate CA to sign a device identity certificate for each device
as it is manufactured.
A device identity certificate MUST contain a DeviceInformation
extension, identified by id-device-information. This extension
contains the vendor identity, device model and device serial.
Together these are called the device identity and MUST uniquely
define a particular device.
id-device-information OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 54392 5 1567 }
DeviceInformation ::= SEQUENCE {
vendor UTF8STring -- manufacturer of device
model UTF8STring -- device model information
serial UTF8STring -- device instance information
}
EDNOTE: this is a temporary OID for the purposes of prototyping.
We are requesting IANA to assign a permanent OID, see Section 8.
A device identity certificate MUST have the [RFC5280] basic
constraints extension with the cA boolean set to true (since the
device is acting as a CA).
No significance is attached to the subject field of a device identity
certificate.
Constraints:
Ounsworth, et al. Expires 14 September 2023 [Page 8]
Internet-Draft PKIX Key Attestation March 2023
* A verifier MUST reject any key attestation that does not contain
exactly one device identity certificate.
* A verifier MUST reject any device identity certificate whose
vendor identity as indicated in the vendor field does not match
the one associated with the trust anchor used to verify the key
attestation.
* Two distinct devices from the same vendor MUST NOT have the same
device identity, i.e. they must have different values for at least
one field of DeviceIdentity.
* Two distinct devices MUST NOT have the same device identity key.
As a matter of interpretation, it is envisaged that the uniqueness
requirement on device identity keys (and all other keys in this
specification) is achieved by generating keys of adequate size and
using cryptographically secure pseudorandom number generators, rather
than by maintaining an industry-wide database of all device identity
keys.
4.4. Device Delegation Certificate
A device delegation certificate certifies that a specific
certification subkey (defined in Section 3.4) belongs to a specific
device by binding it to a vendor-specific representation of the
device and the subkey's purpose. It is envisaged that a single
hardware device may have multiple certification subkeys each being
restricted to, for example, a single partition or application
context. The device may create new certification subkeys and
therefore new device delegation certificates over time, for instance
when the device is re-initialized, or if the device supports dynamic
creation of users or application contexts and needs to create
distinct certification subkeys for each.
A device delegation certificate MUST contain a
DeviceSubkeyInformation extension, identified by id-device-subkey-
information. This contains the vendor identity, device model, device
serial and key purpose. Note that this does not uniquely define the
certification subkey.
Ounsworth, et al. Expires 14 September 2023 [Page 9]
Internet-Draft PKIX Key Attestation March 2023
id-device-subkey-information OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 54392 5 1568 }
DeviceSubkeyInformation ::= SEQUENCE {
vendor UTF8STring -- manufacturer of device
model UTF8STring -- device model information
serial UTF8STring -- device instance information
purpose UTF8String -- description of subkey purpose
}
EDNOTE: this is a temporary OID for the purposes of prototyping.
We are requesting IANA to assign a permanent OID, see Section 8.
The meaning of the purpose field is entirely dependent on the device.
It MUST have the [RFC5280] basic constraints extension with the cA
boolean set to true (since the device is acting as a CA).
No significance is attached to the subject field of a device
delegation certificate.
Constraints:
* A verifier MUST reject any device delegation certificate whose
device identity as indicated in the vendor, model and serial
fields does not match the values from the device identity
certificate.
* The purpose field may have any value.
* Two device delegation certificates signed by the same key MAY have
the same purpose field.
4.5. Key Attestation Certificate
A key attestation certificate certifies that an application key was
created in a particular device and is managed according to a
particular policy.
A key attestation certificate MUST contain a
ApplicationKeyInformation extension identified by id-application-key-
information. This contains the vendor identity, device model, device
serial and vendor-specific information.
A key attestation certificate MUST contain an [RFC5280] Extended Key
Usage extension documenting how the device will permit the key to be
used. See Section 5 for more details.
Ounsworth, et al. Expires 14 September 2023 [Page 10]
Internet-Draft PKIX Key Attestation March 2023
ApplicationKeyInformation ::= SEQUENCE {
vendor UTF8STring -- manufacturer of device
model UTF8STring -- device model information
vendorinfo OCTET STRING -- vendor-specific information
}
EDNOTE: this is a temporary OID for the purposes of prototyping.
We are requesting IANA to assign a permanent OID, see Section 8.
If the key attestation certificate contains the [RFC5280] Basic
Constraints extension then it MUST have the cA boolean set to false.
No significance is attached to the subject field of a key attestation
certificate.
Constraints:
* A verifier MUST reject any key attestation certificate whose
device identity as indicated in the vendor, model and serial
fields does not match the values from the device identity
certificate.
* A verifier MUST reject any key attestation certificate which does
not contain exactly one [RFC5280] Extended Key Usage extension
* A verifier MUST reject any key attestation certificate which
permits operations inconsistent with its acceptable policies.
4.5.1. Vendor-Specific Information
The ApplicationKeyInformation.vendorInfo field of the key attestation
certificate MAY contain any octet string (including the empty
string). The interpretation is up to the vendor. For example, it
may be used to convey information about how the key was generated or
a vendor-specific description of the policies that govern its use.
5. Key Usage
Key attestation certificates contain an [RFC5280] s4.2.1.12 Extended
Key Usage extension describing how the device will permit the key to
be used.
Ounsworth, et al. Expires 14 September 2023 [Page 11]
Internet-Draft PKIX Key Attestation March 2023
The standard ExtendedKeyUsage purposes defined in [RFC5280] are not
necessarily suitable in this context. For example the standard
ExtendedKeyUsage OIDs are also not necessarily suitable. For example
the device may have no information about whether a signing key is
intended to be used for server authentication, client authentication,
or any other application of digital signatures. For this reason an
additional set of key usage purposes are defined here.
id-Signature OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 54392 5 1613 }
-- the device will generate signatures with the key
id-Decryption OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 54392 5 1614 }
-- the device will decrypt messages with the key and return the plaintext
id-KeyAgreement OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 54392 5 1615 }
-- the device will use the key for key agreement
id-KeyTransport OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 54392 5 1616 }
-- the device will use the key for key transport
id-Recoverable OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 54392 5 1612 }
-- the key is can be recovered under administrative authorization
EDNOTE: these are a temporary OIDs for the purposes of
prototyping. We are requesting IANA to assign a permanent OID,
see Section 8.
EDNOTE: We should consult particularly with CAs to see if there
are other properties that would be beneficial to include in this
list.
Constraints:
* If the device does not include id-Signature in the list of key use
purposes then it MUST NOT generate signatures with the key.
* If the device does not include id-Decryption in the list of key
use purposes then it MUST NOT decrypt ciphertexts with the key.
* If the device does not include id-KeyAgreement in the list of key
use purposes then it MUST NOT use the key for key agreement.
Ounsworth, et al. Expires 14 September 2023 [Page 12]
Internet-Draft PKIX Key Attestation March 2023
* If the device does not include id-KeyTransport in the list of key
use purposes then it MUST NOT use the key for key transport.
* If the device does not include id-Recoverable in the list of key
use purposes then it MUST NOT permit recovery operations on the
key.
5.1. Distinctions between Key Use Policies
* Decryption means using the key to decrypt a ciphertext and
returning the plaintext to the caller, outside the device
* Key Transport means using the key to decrypt a ciphertext and
using the plaintext as key material, managed by the device
* Key Agreement means using the key to agree a secret shared with
another party, as prelude to further secure communication
5.2. Recoverable Keys
The id-Recoverable key use purpose indicates that the policies
controlling use of the key may be modified by a suitably authorized
administrator. This may be necessary, for example, to ensure that
the key remains available for use even when an authentication token
is lost or destroyed.
The scope of possible modifications, and the kind of authorization
required, are intentionally vague.
See Section 9.3 for further discussion.
5.3. Key Protection
These key use purposes are not intended to describe how applications
keys is protected by the device. For example one device may protect
keys by maintaining them inside a hardened boundary at all times;
another may allow keys to be used across multiple devices by
encrypting them under a shared master key, or by sharing them with
other authorized devices via a secure channel.
Provided the device is able to guarantee that the key use policy it
signs will be honored, the mechanism is uses to protect application
keys is not relevant.
Ounsworth, et al. Expires 14 September 2023 [Page 13]
Internet-Draft PKIX Key Attestation March 2023
5.4. Vendor-Defined Key Use Policies
A vendor may define key use policies outside the list above, for
example reflecting policies not envisaged by this document or to
cover device-specific functionality. For example they may describe a
policy in terms of their device's proprietary policy or access
control syntax and publish an OID reflecting that policy.
A verifier MUST NOT accept such a vendor-defined policy unless they
fully understand the intended meaning.
6. Embedding Key Attestations in Certification Requests
A convenient way to convey a key attestation is to embed it into a
[RFC2986] certification request. This may be done via the
AttestationBundle extension, identified by the OID id-attestation-
bundle.
Constraints:
* A certification request SHOULD only have one embedded key
attestation.
* A CA MUST follow meet all the constraints on verifiers described
above.
* A CA MUST verify that the subject public key in the certification
request is the same as the subject public key in the key
attestation certificate.
*RJK TODO tidy up all this section
(MikeO: We'll need to be explicit about how to bundle this into a
[RFC2986] Attribute. Do we need an OID for the type? I assume the
values is straight-forward: it'll be a single item, which is the
OCTET STRING of the AttestationBundle?
Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE { type
ATTRIBUTE.&id({IOSet}), values SET SIZE(1..MAX) OF
ATTRIBUTE.&Type({IOSet}{@type}) }
)
id-attestation-bundle OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 54392 5 1571 }
AttestationBundle ::= SEQUENCE OF Certificate
Ounsworth, et al. Expires 14 September 2023 [Page 14]
Internet-Draft PKIX Key Attestation March 2023
EDNOTE: this is a temporary OID for the purposes of prototyping.
We are requesting IANA to assign a permanent OID, see Section 8.
7. Implementation Considerations
... TODO document any (non-security) GOTCHAs ...
8. IANA Considerations
The following Object Identifiers are to be assigned by IANA:
id-device-information OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 54392 5 1567 }
id-device-subkey-information OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 54392 5 1568 }
id-application-key-information OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 54392 5 1569 }
id-attestation-bundle OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 54392 5 1571 }
id-Signature OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 54392 5 1613 }
id-Decryption OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 54392 5 1614 }
id-KeyAgreement OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 54392 5 1615 }
id-KeyTransport OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 54392 5 1616 }
id-Recoverable OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 54392 5 1612 }
TODO: suggest to IANA which public arc we want these in (these are
just placeholders).
TODO update for our new EKU OIDs
*RJK: the OIDs are assigned by a free OID assignment service. If I
can have something under Entrust then I'll replace them with that.
9. Security Considerations
Ounsworth, et al. Expires 14 September 2023 [Page 15]
Internet-Draft PKIX Key Attestation March 2023
9.1. Key Use Constraints
The key use constraints describe above are essential. For example if
a device identity key could be used by a user to sign arbitrary
messages, that user could forge key attestations.
9.2. Verification Model
An API that verifies a key attestation may be designed in a number of
different ways.
1. It may accept just a key attestation. It will verify it, and
return either an error indicator or the public trust anchor key,
vendor identity, public application key, and the policy governing
is use. The caller must check at least that the trust anchor key
is acceptable; the vendor identity from the key attestation
matches the one associated with the trust anchor; and that the
policy is acceptable, before using the application key. If the
caller is running in a context where there are multiple copies of
the application key (for example, the certification request
verification described in Section 6 it must also check that all
copies of the application key match.
2. It may accept a key attestation, trust anchor, vendor identity
and at least one acceptable policy. It will verify the key
attestation using the trust anchor, and check that the vendor
identities in the key attestation match the trust anchor, and
check that the policy is acceptable. It will return either an
error indicator or the application key. If the caller is running
in a context where there are multiple copies of the application
key then it must also check that all copies of the application
key match. Apart from that it can use the application key
without further checks.
3. It may accept a key attestation, trust anchor, vendor identity,
application key and at least one acceptable policy. It will
verify the key attestation using the trust anchor, and check that
the vendor identities in the key attestation match the trust
anchor, check that the policy is acceptable, and that the
application key is the expected value. It will return either an
error or a success indicator. The caller can use the application
key without further checks.
In all of these models the same set of checks must be done, but in
the first two some of the checks are delegated to the caller. The
advantage of the later models is that they are more robust against
the caller ommitting some of the necessary checks. For a publicly
available API this robustness is particularly appropriate.
Ounsworth, et al. Expires 14 September 2023 [Page 16]
Internet-Draft PKIX Key Attestation March 2023
9.3. Recoverable Keys
The definition of recoverability is intentionally vague. Depending
on the device it may mean that, for example, a signature-only RSA key
could additionally be given decrypt permission, or it could mean that
private key material could be extracted in plaintext. The range of
possibilities is too broad to tie down in a device-independent
specification.
It should be noted that placing trust in a key does mean generally
placing trust in the operators and administrators of the device that
contains it, even without any possibility of administrator override
of the policy governing its use. For example, even if a key is not
recoverable, there is nothing to prevent a key owner exposing a
signature oracle for their key, allowing anyone to sign with it. As
such, if the key owner and the device administrator belong to the
same organization, and have aligned priorities, there is not much
practical difference between recoverable and non-recoverable keys.
However, in the example where a device is owned and managed by a
service provider but leased to an end user, the key owner and the
device administrators belong to separate organizations and have
different priorities. In that case a verifier may prefer to reject
recoverable keys.
9.4. Uniqueness of Keys
It's generally assumed that all keys are unique. This is the
expected outcome for properly generated cryptographic keys, and while
a collision is in principle possible by chance, it's much more likely
that a collision indicates a failure in the key generation process
(for example, [DSA1571]).
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>.
Ounsworth, et al. Expires 14 September 2023 [Page 17]
Internet-Draft PKIX Key Attestation March 2023
[RFC5280] 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", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
Format", RFC 5914, DOI 10.17487/RFC5914, June 2010,
<https://www.rfc-editor.org/info/rfc5914>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the
Cryptographic Algorithm Object Identifier Range",
RFC 8411, DOI 10.17487/RFC8411, August 2018,
<https://www.rfc-editor.org/info/rfc8411>.
[X.690] ITU-T, "Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ISO/IEC 8825-1:2015, November 2015.
10.2. Informative References
[DSA1571] Debian Project, "DSA-1571-1 openssl - predictable random
number generator", May 2008,
<https://www.debian.org/security/2008/dsa-1571>.
Appendix A. Samples
... either place samples here inline, or reference on Github. I've
got a script I've used in other I-Ds to inline include files, if
that's useful here.
Appendix B. ASN.1 Module
... any ASN.1 that we are defining goes here ...