idnits 2.17.1 draft-birkholz-core-coid-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 06, 2019) is 1749 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-ace-cwt-proof-of-possession-06 == Outdated reference: A later version (-07) exists of draft-ietf-oauth-jwt-bcp-06 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-01 == Outdated reference: A later version (-22) exists of draft-tschofenig-rats-psa-token-01 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-07) exists of draft-bormann-cbor-tags-oid-06 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Informational C. Bormann 5 Expires: January 7, 2020 Universitaet Bremen TZI 6 M. Pritikin 7 Cisco 8 R. Moskowitz 9 Huawei 10 July 06, 2019 12 Concise Identities 13 draft-birkholz-core-coid-02 15 Abstract 17 There is an increased demand of trustworthy claim sets -- a set of 18 system entity characteristics tied to an entity via signatures -- in 19 order to provide information. Claim sets represented via CBOR Web 20 Tokens (CWT) can compose a variety of evidence suitable for 21 constrained-node networks and to support secure device automation. 22 This document focuses on sets of identifiers and attributes that are 23 tied to a system entity and are typically used to compose identities 24 appropriate for Constrained RESTful Environment (CoRE) authentication 25 needs. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 7, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 2. Claims in a Concise Identity . . . . . . . . . . . . . . . . 5 65 2.1. iss: CWT issuer . . . . . . . . . . . . . . . . . . . . . 5 66 2.2. sub: CWT subject . . . . . . . . . . . . . . . . . . . . 5 67 2.3. aud: CWT audience . . . . . . . . . . . . . . . . . . . . 5 68 2.4. exp: CWT expiration time . . . . . . . . . . . . . . . . 5 69 2.5. nbf: CWT start of validity . . . . . . . . . . . . . . . 6 70 2.6. iat: CWT time of issue . . . . . . . . . . . . . . . . . 6 71 2.7. cti: CWT ID . . . . . . . . . . . . . . . . . . . . . . . 6 72 2.8. cnf: CWT proof-of-possession key claim . . . . . . . . . 6 73 3. The Essential Qualities of the Subject Claim . . . . . . . . 6 74 4. Signature Envelope . . . . . . . . . . . . . . . . . . . . . 7 75 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 7 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 8.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Appendix A. Common Terminology on Identity Documents . . . . . . 10 82 A.1. Terms Specified in IEEE 802.1AR . . . . . . . . . . . . . 10 83 A.2. Terms Specified in RFC 4949 . . . . . . . . . . . . . . . 10 84 A.3. Terms specified in ISO/IEC 9594-8:2017 . . . . . . . . . 11 85 Appendix B. Concise Identities and Trust Relationships . . . . . 11 86 Appendix C. Concise Identity (CoID) CDDL Data Definition based 87 on RFC 5280 . . . . . . . . . . . . . . . . . . . . 12 88 Appendix D. Concise Secure Device Identifier (CoDeID) based on 89 IEEE 802.1AR-2018 . . . . . . . . . . . . . . . . . 12 90 D.1. The Intended Use of DevIDs . . . . . . . . . . . . . . . 13 91 D.2. DevID Flavors . . . . . . . . . . . . . . . . . . . . . . 13 92 D.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 D.4. Concise DevID CDDL data definition (sans COSE header) . . 14 94 Appendix E. Concise Attribute Documents . . . . . . . . . . . . 16 95 Appendix F. Attic . . . . . . . . . . . . . . . . . . . . . . . 16 96 F.1. Examples of claims taken from IEEE 802.1AR identifiers . 16 97 F.1.1. 7.2.1 version . . . . . . . . . . . . . . . . . . . . 17 98 F.1.2. 7.2.2 serialNumber . . . . . . . . . . . . . . . . . 17 99 F.1.3. 7.2.3 signature . . . . . . . . . . . . . . . . . . . 17 100 F.1.4. 7.2.4 issuer Name . . . . . . . . . . . . . . . . . . 17 101 F.1.5. 7.2.5 authoritykeyidentifier . . . . . . . . . . . . 17 102 F.1.6. 7.2.7.1 notBefore . . . . . . . . . . . . . . . . . . 17 103 F.1.7. 7.2.7.2 notAfter . . . . . . . . . . . . . . . . . . 18 104 F.1.8. 7.2.10 subjectPublicKeyInfo . . . . . . . . . . . . . 18 105 F.1.9. 7.2.11 signatureAlgorithm . . . . . . . . . . . . . . 18 106 F.1.10. 7.2.12 signatureValue . . . . . . . . . . . . . . . . 18 107 F.2. Examples of claims taken from X.509 certificates . . . . 18 108 F.2.1. 2.5.29.35 - Authority Key Identifier . . . . . . . . 18 109 F.2.2. 2.5.29.14 - Subject Key Identifier . . . . . . . . . 18 110 F.2.3. 2.5.29.15 - Key Usage . . . . . . . . . . . . . . . . 18 111 F.2.4. 2.5.29.37 - Extended key usage . . . . . . . . . . . 19 112 F.2.5. 1.3.6.1.5.5.7.1.1 - Authority Information Access . . 19 113 F.2.6. 1.3.6.1.4.1.311.20.2 - Certificate Template Name 114 Domain Controller (Microsoft) . . . . . . . . . . . . 19 115 Appendix G. Graveyard . . . . . . . . . . . . . . . . . . . . . 19 116 G.1. 7.2.9 subjectAltName . . . . . . . . . . . . . . . . . . 19 117 G.2. 7.2.13 extensions . . . . . . . . . . . . . . . . . . . . 19 118 G.3. 2.5.29.31 - CRL Distribution Points . . . . . . . . . . . 19 119 G.4. 2.5.29.17 - Subject Alternative Name . . . . . . . . . . 19 120 G.5. 2.5.29.19 - Basic Constraints . . . . . . . . . . . . . . 20 121 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 124 1. Introduction 126 X.509 certificates [RFC5280] and Secure Device Identifier 127 [IEEE-802.1AR] are ASN.1 encoded Identity Documents and intended to 128 be tied to a system entity uniquely identified via these Identity 129 Documents. An Identity Document - in general, a public-key 130 certificate - can be conveyed to other system entities in order to 131 prove or authenticate the identity of the owner of the Identity 132 Document. Trust in the proof can be established by mutual trust of 133 the provider and assessor of the identity in a third party 134 verification (TVP) provided, for example, by a certificate authority 135 (CA) or its subsidiaries (sub CA). 137 The evidence a certificate comprises is typically composed of a set 138 of claims that is signed using secret keys issued by a (sub) CA. The 139 core set of claims included in a certificate - its attributes - are 140 well defined in the X.509v3 specifications and IEEE 802.1AR. 142 This document summarizes the core set of attributes and provides a 143 corresponding list of claims using concise integer labels to be used 144 in claim sets for CBOR Web Tokens (CWT) [RFC8392]. A resulting 145 Concise Identity (CoID) is able to represent a signed set of claims 146 that composes an Identity as defined in [RFC4949]. 148 The objective of using CWT as a basis for the signed claim sets 149 defined in this document is to gain more flexibility and at the same 150 time more rigorously defined semantics for the signed claim sets. In 151 addition, the benefits of using CBOR, COSE, and the corresponding CWT 152 structure accrue, including more compact encoding and a simpler 153 implementation in contrast to classical ASN.1 (DER/BER/PEM) 154 structures and the X.509 complexity and uncertainty that has accreted 155 since X.509 was released 29 years ago. One area where both the 156 compactness and the definiteness are highly desirable is in 157 Constrained-Node Networks [RFC7228], which may also make use of the 158 Constrained Application Protocol (CoAP, [RFC7252]); however, the area 159 of application of Concise Identities is not limited to constrained- 160 node networks. 162 The present version of this document is a strawman that attempts to 163 indicate the direction the work is intended to take. Not all 164 inspirations this version takes from X.509 maybe need to be taken. 166 1.1. Terminology 168 This document uses terminology from [RFC8392] and therefore also 169 [RFC7519], as well as from [RFC8152]. Specifically, we note: 171 Assertion: A statement made by an entity without accompanying 172 evidence of its validity [X.1252]. 174 Claim: A piece of information asserted about a subject. A claim is 175 represented as a name/value pair consisting of a Claim Name and a 176 Claim Value. 178 Claims are grouped into claims sets (represented here by a CWT), 179 which need to be interpreted as a whole. Note that this usage is a 180 bit different from idiomatic English usage, where a claim would stand 181 on its own. 183 (Note that the current version of this draft is not very explicit 184 about the relationship of identities and identifiers. To be done in 185 next version.) 187 1.2. Requirements Language 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 191 "OPTIONAL" in this document are to be interpreted as described in 192 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 193 capitals, as shown here. 195 2. Claims in a Concise Identity 197 A Concise Identity (CoID) is a CBOR Web Token [RFC8392] with certain 198 claims present. It can be signed in a number of ways, including a 199 COSE_Sign1 data object [RFC8152]. 201 2.1. iss: CWT issuer 203 Optional: identifies the principal that is the claimant for the 204 claims in the CoID ([RFC8392] Section 3.1.1, cf. Section 4.1.1 in 205 [RFC7519]). 207 o Note that this is a StringOrURI (if it contains a ":" it needs to 208 be a URI) 210 o For the "string" case (no ":"), there is no way to extract 211 meaningful components from the string 213 o Make it a URI if it needs to be structured (not for routine 214 retrieval, unless specified so by an application) 216 o If this URI looks like an HTTP or HTTPS URI then something 217 retrievable by humans should exist there. 219 o Alternatively, some arithmetic can be applied to the URI (extract 220 origin, add /.well-known/...) to find relevant information. 222 2.2. sub: CWT subject 224 Optional: identifies the principal that is the subject for the claims 225 in the CoID ([RFC8392] Section 3.1.2, cf. Section 4.1.2 in 226 [RFC7519]). 228 2.3. aud: CWT audience 230 Optional: identifies the recipients that the CoID is intended for 231 ([RFC8392] Section 3.1.4, cf. Section 4.1.4 in [RFC7519]). 233 2.4. exp: CWT expiration time 235 Optional: the time on or after which the CoID must no longer be 236 accepted for processing ([RFC8392] Section 3.1.4, cf. Section 4.1.4 237 in [RFC7519]). 239 2.5. nbf: CWT start of validity 241 Optional: the time before which the CoID must not be accepted for 242 processing ([RFC8392] Section 3.1.5, cf. Section 4.1.5 in [RFC7519]). 244 2.6. iat: CWT time of issue 246 Optional: the creation time of the CoID ([RFC8392] Section 3.1.6, cf. 247 Section 4.1.6 in [RFC7519]). 249 2.7. cti: CWT ID 251 The "cti" (CWT ID) claim provides a unique identifier for the CoID 252 ([RFC8392] Section 3.1.7, cf. "jti" in Section 4.1.7 in [RFC7519]). 254 CWT IDs are intended to be unique within an application, so they need 255 to be either coordinated between issuers or based on sufficient 256 randomness (e.g., 112 bits or more). 258 2.8. cnf: CWT proof-of-possession key claim 260 The "cnf" claim identifies the key that can be used by the subject 261 for proof-of-possession and provides parameters to identify the CWT 262 Confirmation Method ([I-D.ietf-ace-cwt-proof-of-possession] 263 Section 3.1). 265 3. The Essential Qualities of the Subject Claim 267 As highlighted above, the base definition of the representation of 268 the "sub claim" is already covered by [RFC8392] and [RFC7519]. 270 If claim sets need to be made about multiple subjects, the favored 271 approach in CoID is to create multiple CoIDs, one each per subject. 273 In certain cases, the subject of a CoID needs to be an X.500 274 Distinguished Name in its full glory. These are sequences of 275 relative names, where each relative name has a relative name type and 276 a (text string) value. 278 dn-subject = [*(relativenametype, relativenamevalue)] 280 (RFC 5280 does not appear to specify how many DN components must be 281 in a DN, so this uses a zero or more quantity.) 283 Any RelativeDistinguishedName values that are SETs of more than one 284 AttributeTypeAndValue are translated into a sequence of pairs of the 285 nametype used and each of the namevalues, lexicographically sorted. 287 To be able to map these to CBOR, we define labels for the relative 288 name types listed in Section 4.1.2.4 of [RFC5280]: 290 (Note that unusual relative name types could be represented as OIDs; 291 this would probably best be done by reviving the currently dormant 292 [I-D.bormann-cbor-tags-oid].) 294 relativenametype = &( 295 country: 1 296 organization: 2 297 organizational-unit: 3 298 distinguished-name-qualifier: 4 299 state-or-province-name: 5 300 common-name: 6 301 serial-number: 7 302 locality: 8 303 title: 9 304 surname: 10 305 given-name: 11 306 initials: 12 307 pseudonym: 13 308 generation-qualifier: 14 309 ) 311 The relative name values for these types are always expressed as CBOR 312 text strings, i.e., in UTF-8: 314 relativenamevalue = text 316 4. Signature Envelope 318 The signature envelope [TBD: need not actually be envelope, may be 319 detached, too] carries additional information, e.g., the signature, 320 as well as the identification of the signature algorithm employed 321 (COSE: alg). Additional information may pertain to the signature (as 322 opposed to the claims being signed), e.g., a key id (COSE: kid) may 323 be given in the header of the signature. 325 5. Processing Rules 327 (TBD: This should contain some discussion of the processing rules 328 that apply for CoIDs. Some of this will just be pointers to 329 [I-D.ietf-oauth-jwt-bcp].) 331 6. IANA Considerations 333 This document makes no requests of IANA 335 7. Security Considerations 337 8. References 339 8.1. Normative References 341 [I-D.ietf-ace-cwt-proof-of-possession] 342 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 343 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 344 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 345 possession-06 (work in progress), February 2019. 347 [I-D.ietf-oauth-jwt-bcp] 348 Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best 349 Current Practices", draft-ietf-oauth-jwt-bcp-06 (work in 350 progress), June 2019. 352 [I-D.ietf-rats-eat] 353 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 354 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 355 ietf-rats-eat-01 (work in progress), July 2019. 357 [I-D.tschofenig-rats-psa-token] 358 Tschofenig, H., Frost, S., Brossard, M., and A. Shaw, 359 "Arm's Platform Security Architecture (PSA) Attestation 360 Token", draft-tschofenig-rats-psa-token-01 (work in 361 progress), April 2019. 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, 365 DOI 10.17487/RFC2119, March 1997, 366 . 368 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 369 Housley, R., and W. Polk, "Internet X.509 Public Key 370 Infrastructure Certificate and Certificate Revocation List 371 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 372 . 374 [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet 375 Attribute Certificate Profile for Authorization", 376 RFC 5755, DOI 10.17487/RFC5755, January 2010, 377 . 379 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 380 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 381 . 383 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 384 RFC 8152, DOI 10.17487/RFC8152, July 2017, 385 . 387 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 388 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 389 May 2017, . 391 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 392 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 393 May 2018, . 395 [X.1252] "ITU-T X.1252 (04/2010)", n.d.. 397 8.2. Informative References 399 [I-D.bormann-cbor-tags-oid] 400 Bormann, C. and S. Leonard, "Concise Binary Object 401 Representation (CBOR) Tags and Techniques for Object 402 Identifiers, UUIDs, Enumerations, Binary Entities, Regular 403 Expressions, and Sets", draft-bormann-cbor-tags-oid-06 404 (work in progress), March 2017. 406 [IEEE-802.1AR] 407 "ISO/IEC/IEEE International Standard for Information 408 technology -- Telecommunications and information exchange 409 between systems -- Local and metropolitan area networks -- 410 Part 1AR: Secure device identity", IEEE standard, 411 DOI 10.1109/ieeestd.2014.6739984, n.d.. 413 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 414 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 415 . 417 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 418 RFC 5652, DOI 10.17487/RFC5652, September 2009, 419 . 421 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 422 Constrained-Node Networks", RFC 7228, 423 DOI 10.17487/RFC7228, May 2014, 424 . 426 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 427 Application Protocol (CoAP)", RFC 7252, 428 DOI 10.17487/RFC7252, June 2014, 429 . 431 Appendix A. Common Terminology on Identity Documents 433 To illustrate the purpose and intent of Identity Documents, 434 typically, terms, such as certificates, certificate chains/paths and 435 trust anchors, are used. To provide more context and for the 436 convenience of the reader, three sources of definitions are 437 highlighted in this section. 439 A.1. Terms Specified in IEEE 802.1AR 441 1. a certificate is "a digitally signed object that binds 442 information identifying an entity that possesses a secret private 443 key to the corresponding public key." 445 2. a certificate chain is "an ordered list of intermediate 446 certificates that links an end entity certificate ([...] a DevID 447 certificate) to a trust anchor." 449 3. a trust anchor is "a Certificate Authority that is trusted and 450 for which the trusting party holds information, usually in the 451 form of a self-signed certificate issued by the trust anchor". 453 A.2. Terms Specified in RFC 4949 455 1. a public-key certificate is "a digital certificate that binds a 456 system entity's identifier to a public key value, and possibly to 457 additional, secondary data items; i.e., a digitally signed data 458 structure that attests to the ownership of a public key". 460 2. a certification path is "a linked sequence of one or more public- 461 key certificates [...] that enables a certificate user to verify 462 the signature on the last certificate in the path, and thus 463 enables the user to obtain (from that last certificate) a 464 certified public key, or certified attributes, of the system 465 entity that is the subject of that last certificate". 467 3. a trust anchor is "a CA that is the subject of a trust anchor 468 certificate or otherwise establishes a trust anchor key". 469 Correspondingly, a trust anchor has a trust anchor certificate 470 that "is a public-key certificate that is used to provide the 471 first public key in a certification path". 473 A.3. Terms specified in ISO/IEC 9594-8:2017 475 1. a public-key certificate is "the public key of an entity, 476 together with some other information, rendered unforgeable by 477 digital signature with the private key of the certification 478 authority (CA) that issued it". 480 2. a certification path is "an ordered list of one or more public- 481 key certificates, starting with a public-key certificate signed 482 by the trust anchor, and ending with the end-entity public-key 483 certificate to be validated. All intermediate public-key 484 certificates, if any, are certification authority (CA) 485 certificates in which the subject of the preceding public-key 486 certificate is the issuer of the following public-key 487 certificate". 489 3. a trust anchor is "an entity that is trusted by a relying party 490 and used for validating public-key certificates". 492 Appendix B. Concise Identities and Trust Relationships 494 Following the terminology highlighted above, Concise Identities are 495 signed CBOR Web Tokens that compose public-key Identity Documents 496 based on asymmetric key pairs, potentially including additional 497 assertions: claims that are secondary data items. 499 In the context of certification paths, the "last certificate" in the 500 certification path is the Identity Document that resides on the 501 system component, which presents its Identity Document to relying 502 partyies in order to be authenticated. The "first certificate" in 503 the certification path resides on the trust anchor. 505 In order to be able to rely on the trust put into the Identity 506 Document presented to relying parties, these have to put trust into 507 two assumptions first: 509 o the corresponding trust anchor (certificate) is trusted. In 510 consequence, the consumer of the Identity Document requires a 511 basis for decision whether to rely on the trust put in the trust 512 anchor certificate, or not (e.g. via policies or a known 513 certification paths). 515 o the secret key included in the system component that is presenting 516 its Identity Document is protected. In consequence, the secret 517 key has to be stored in a shielded location. Type and quality of 518 the protection or shielding or even its location are assertions 519 that can be included as secondary data items in the Identity 520 Document. 522 In summary, a path of trust relationships between a system 523 component's Identity Document and a trusted authority's Identity 524 Document is required to enable transitive trust in the system 525 component that presents the Identity Document. 527 Appendix C. Concise Identity (CoID) CDDL Data Definition based on RFC 528 5280 530 COSE MUST be used to sign this CoID template flavor. 532 "signatureAlgorithm" and "signature" are not part of the CoID map but 533 of the COSE envelope. 535 CoID = { version: uint .range 1..3 ; (8) 536 issuer: text, ; iss(1) 537 subject: text / bytes, ; sub(2) 538 notAfter: uint, ; exp(4) 539 notBefore: uint ; nbf(5) 540 serialNumber: uint,; (7) 541 subjectPublicKeyInfo: [ algorithm: COSE-Algorithm-Value, 542 subjectPublicKey: bytes, 543 ], ;(9) 544 ? extensions: [ + [ extension-id: uint / registeredID, 545 extension-value: any, 546 ? criticality: bool, 547 ] 548 ], ;(0) 549 } 551 COSE-Algorithm-Value = uint .size 0..2 / nint .size 0..2 552 registeredID = [ + uint ] ; OID 554 extensions = 0 555 issuer = 1 556 subject = 2 557 notAfter = 4 558 notBefore = 5 559 serialNumber = 7 560 version = 8 561 subjectPublicKeyInfo = 9 563 Appendix D. Concise Secure Device Identifier (CoDeID) based on IEEE 564 802.1AR-2018 566 This section illustrates the context and background of Secure Device 567 Identifiers. 569 D.1. The Intended Use of DevIDs 571 IEEE 802.1AR Secure Device Identifier are a specific subset of X.509 572 Identity Documents that are intended to "authenticate a device's 573 identity", where the corresponding Identity Document is 574 "cryptographically bound to that device". In this context, 575 "cryptographically bound" means that the Identity Document is 576 "constructed using cryptographic operations to combine a secret with 577 other arbitrary data objects such that it may be proven that the 578 result could only be created by an entity having knowledge of the 579 secret." 581 While the intent of using X.509 Identity Documents as Device 582 Identifiers starts to blur the line between authentication and 583 authorization, the specification of IEEE 802.1AR Identity Documents 584 provides a meaningful subset of assertions that can be used to 585 identify one or more system components. The following CDDL data 586 definition maps the semantics of an RFC 5280 Public Key 587 Infrastructure Certificate Profile, which provides the basis for the 588 Secure Device Identifier semantics. Both are mapped to a CWT 589 representation. 591 D.2. DevID Flavors 593 In order to provide consistent semantics for the claims as defined 594 below, understanding the distinction of IDevIDs (mandatory 595 representation capabilities) and LDevIDs (recommended representation 596 capabilities) is of the essence. 598 Both flavors of Secure Device Identifiers share most of their 599 assertion semantics (claim sets). 601 IDevIDs are the _initially_ Secure Device Identifiers that "are 602 normally created during manufacturing or initial provisioning" and 603 are "installed on the device by the manufacturer". IDevIDs are 604 intended to be globally unique and to be stored in a way that 605 protects it from modification (typically, a shielded location). It 606 is important to note that a potential segregation of a manufacturer 607 into separate supply chain/tree entities is not covered by the 608 802.1AR specification. 610 LDevIDs are the _local significant_ Secure Device Identifiers that 611 are intended to be "unique in the local administrative domain in 612 which the device is used". In essence, LDevIDs "can be created at 613 any time [after IDevID provisioning], in accordance with local 614 policies". An "LDevID is bound to the device in a way that makes it 615 infeasible for it to be forged or transferred to a device with a 616 different IDevID without knowledge of the private key used to effect 617 the cryptographic binding". 619 D.3. Privacy 621 The exposition iof IDevID Identity Documents enables global unique 622 identification of a system component. To mitigate the obvious 623 privacy LDevIDs may also be used as the sole identifier (by disabling 624 the IDevID) to assure the privacy of the user of a DevID and the 625 equipment in which it is installed. 627 D.4. Concise DevID CDDL data definition (sans COSE header) 629 COSE MUST be used to sign this DevID flavor, if represented via CoID. 631 "signature" and "signatureValue" are not part of the CoID map but of 632 the COSE envelope. 634 "AlgorithmIdentifier" and corresponding "algorithm" and "parameters" 635 should be part of the COSE envelope. 637 CoDeID = { version: 3, ;(8) 638 serialNumber: uint,(7) 639 issuer: text, ; iss(1) 640 notAfter: uint, ; exp(4) 641 notBefore: uint ; nbf(5) 642 subject: text / URI, ; sub(2) 643 subjectPublicKeyInfo: [ algorithm: COSE-Algorithm-Value, 644 subjectPublicKey: bytes, 645 ], ;(9) 646 signatureAlgorithm: COSE-Algorithm-Value ; 802.1ar-2018 states 647 ; this must be identical 648 ; to cose sig-alg (rm?) 649 authorityKeyidentifier: bytes, ; all, non-critical, 650 ? subjectKeyIdentifier; bytes, ; only intermediates, non-critical 651 ? keyUsage : [ bitmask: bytes .size 1, 652 ? criticality: bool, 653 ] 654 ? subjectAltName: text / iPAddress / registeredID, 655 ? HardwareModuleName: [ hwType: registeredID, 656 hwSerialNum: bytes, 657 ], 658 ? extensions: [ + [ extension-id: uint, 659 extension-value: any, 660 ? criticality: bool, 661 ], 662 } 664 COSE-Algorithm-Value = uint .size 0..2 / nint .size 0..2 665 iPAddress = bytes .size 4 / bytes .size 16 666 registeredID = [ + uint ] ; OID 668 extensions = 0 669 issuer = 1 670 subject = 2 671 notAfter = 4 672 notBefore = 5 673 serialNumber = 7 674 version = 8 675 subjectPublicKeyInfo = 9 676 signatureAlgorithm = 10 677 authorityKeyidentifier = 11 678 subjectKeyIdentifier = 12 679 keyUsage = 13 ; could move to COSE header? 680 subjectAltName = 14 681 HardwareModuleName = 15 682 Appendix E. Concise Attribute Documents 684 Additional well-defined sets of characteristics can be bound to 685 Identity Documents [RFC5280] or Secure Device Identifiers 686 [IEEE-802.1AR]. CDDL specifications to define these can be found in 687 the corresponding appendices above and the Profile for X.509 Internet 688 Attribute Certificates is defined in [RFC5755]. 690 Essentially, various existing CWT specializations, such as the Entity 691 Attestation Tokens [I-D.ietf-rats-eat] and the Platform Security 692 Architecture Tokens [I-D.tschofenig-rats-psa-token] already compose a 693 type of Attribute Certificates today. In order to bridge the gap 694 between these already existing Concise Attribute Documents and 695 binding them to traditional X.509 Identity Documents (pub-key 696 certificates), a sub claim referencing the corresponding Identity 697 Document has to be included in the signed CBOR Web Token (flavor). 698 The mechanics of how to handle the corresponding key material is also 699 defined in [RFC5755] (and this document will elaborate on these in 700 future versions). 702 With respect to Concise Identity Documents the dn-subject claim 703 should be used. If a Concise Attribute Certificate has to refer to a 704 traditional ASN.1 encoded X.509 Identity document the subject claim 705 should be used. This procedure provides a migration path from ASN.1 706 encoded Identity documents [RFC5280] to CBOR encoded Concise Identity 707 documents that allows to bind Concise Attribute Documents, such as 708 EAT or PSA Tokens to both kinds of certificates. In an ideal 709 scenario CBOR encoding in the form of [RFC8392] is used both for 710 Concise Identity Documents and Concise Attribute Documents. The 711 alternate uses of subject claims or dn-subject claims addresses the 712 fact that the vast majority of constrained node devices still use an 713 ASN.1 encoding and simplified interoperability between CBOR encoded 714 and ASN.1 encoded documents is still of essence today. 716 Appendix F. Attic 718 Notes and previous content that will be pruned in next versions. 720 F.1. Examples of claims taken from IEEE 802.1AR identifiers 722 This appendix briefly discusses common fields in a X.509 certificate 723 or an IEEE 802.1AR Secure Device Identifier and relates them to 724 claims in a CoID. 726 The original purpose of X.509 was only to sign the association 727 between a name and a public key. In principle, if something else 728 needs to be signed as well, CMS [RFC5652] is required. This 729 principle has not been strictly upheld over time; this is 730 demonstrated by the growth of various extensions to X.509 731 certificates that might or might not be interpreted to carry various 732 additional claims. 734 This document details only the claim sets for CBOR Web Tokens that 735 are necessary for authentication. The plausible integration or 736 replacement of ASN.1 formats in enrollment protocols, (D)TLS 737 handshakes and similar are not in scope of this document. 739 Subsections in this appendix are marked by the ASN.1 Object 740 Identifier (OID) typically used for the X.509 item. [TODO: Make this 741 true; there are still some section numbers.] 743 F.1.1. 7.2.1 version 745 The version field is typically not employed usefully in an X.509 746 certificate, except possibly in legacy applications that accept 747 original (pre-v3) X.509 certificates. 749 Generally, the point of versioning is to deliberately inhibit 750 interoperability (due to semantic meaning changes). CoIDs do not 751 employ versioning. Where future work requires semantic changes, 752 these will be expressed by making alternate kinds of claims. 754 F.1.2. 7.2.2 serialNumber 756 Covered by cti claim. 758 F.1.3. 7.2.3 signature 760 The signature, as well as the identification of the signature 761 algorithm, are provided by the COSE container (e.g., COSE_Sign1) used 762 to sign the CoID's CWT. 764 F.1.4. 7.2.4 issuer Name 766 Covered by iss claim. 768 F.1.5. 7.2.5 authoritykeyidentifier 770 Covered by COSE kid in signature, if needed. 772 F.1.6. 7.2.7.1 notBefore 774 Covered by nbf claim. 776 F.1.7. 7.2.7.2 notAfter 778 Covered by exp claim. 780 For Secured Device identifiers, this claim is typically left out. 782 o get a new one whenver you think you need it ("normal path") 784 o nonced ocsp? might benefit from a more lightweight freshness 785 verification of existing signed assertion - exploration required! 787 o (first party only verfiable freshness may be cheaper than third- 788 party verifiable?) 790 F.1.8. 7.2.10 subjectPublicKeyInfo 792 Covered by cnf claim. 794 F.1.9. 7.2.11 signatureAlgorithm 796 In COSE_Sign1 envelope. 798 F.1.10. 7.2.12 signatureValue 800 In COSE_Sign1 envelope. 802 F.2. Examples of claims taken from X.509 certificates 804 Most claims in X.509 certificates take the form of certificate 805 extensions. This section reviews a few common (and maybe not so 806 common) certificate extensions and assesses their usefulness in 807 signed claim sets. 809 F.2.1. 2.5.29.35 - Authority Key Identifier 811 Used in certificate chaining. Can be mapped to COSE "kid" of the 812 issuer. 814 F.2.2. 2.5.29.14 - Subject Key Identifier 816 Used in certificate chaining. Can be mapped to COSE "kid" in the 817 "cnf" (see Section 3.4 of [I-D.ietf-ace-cwt-proof-of-possession]). 819 F.2.3. 2.5.29.15 - Key Usage 821 Usage information for a key claim that is included in the signed 822 claims. Can be mapped to COSE "key_ops" [TBD: Explain details]. 824 F.2.4. 2.5.29.37 - Extended key usage 826 Can include additional usage information such as 1.3.6.1.5.5.7.3.1 827 for TLS server certificates or 1.3.6.1.5.5.7.3.2 for TLS client 828 certificates. 830 F.2.5. 1.3.6.1.5.5.7.1.1 - Authority Information Access 832 More information about the signer. May include a pointer to signers 833 higher up in the certificate chain (1.3.6.1.5.5.7.48.2), typically in 834 the form of a URI to their certificate. 836 F.2.6. 1.3.6.1.4.1.311.20.2 - Certificate Template Name Domain 837 Controller (Microsoft) 839 This is an example for many ill-defined extensions that are on some 840 arcs of the OID space somewhere. 842 E.g., the UCS-2 string (ASN.1 BMPString) "IPSECIntermediateOffline" 844 Appendix G. Graveyard 846 Items and Content that was already discarded. 848 G.1. 7.2.9 subjectAltName 850 (See "sub"). 852 G.2. 7.2.13 extensions 854 Extensions are handled by adding CWT claims to the CWT. 856 G.3. 2.5.29.31 - CRL Distribution Points 858 Usually URIs of places where a CRL germane to the certificate can be 859 obtained. Other forms of validating claim sets may be more 860 appropriate than CRLs for the applications envisaged here. 862 (Might be replaced by a more general freshness verification approach 863 later. For example one could define a generic "is this valid" 864 request to an authority.) 866 G.4. 2.5.29.17 - Subject Alternative Name 868 Additional names for the Subject. 870 These may be an "OtherName", i.e. a mistery blob "defined by" an 871 ASN.1 OID such as 1.3.6.1.4.1.9.21.2.3, or one out of a few formats 872 such as URIs (which may, then, turn out not to be really URIs). 873 Naming subjects obviously is a major issue that needs attention. 875 G.5. 2.5.29.19 - Basic Constraints 877 Can identify the key claim as that for a CA, and can limit the length 878 of a certificate path. Empty in all the examples analyzed. 880 Any application space can define new fields / claims as appropriate 881 and use them. There is no need for the underlying structure to 882 define an additional extension method for this. Instead, they can 883 use the registry as defined in Section 9.1 of [RFC8392].> 885 Acknowledgements 887 Authors' Addresses 889 Henk Birkholz 890 Fraunhofer SIT 891 Rheinstrasse 75 892 Darmstadt 64295 893 Germany 895 Email: henk.birkholz@sit.fraunhofer.de 897 Carsten Bormann 898 Universitaet Bremen TZI 899 Postfach 330440 900 Bremen D-28359 901 Germany 903 Phone: +49-421-218-63921 904 Email: cabo@tzi.org 906 Max Pritikin 907 Cisco 909 Email: pritikin@cisco.com 911 Robert Moskowitz 912 Huawei 913 Oak Park, MI 48237 915 Email: rgm@labs.htt-consult.com