idnits 2.17.1 draft-birkholz-core-coid-01.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 432: '... COSE MUST be used to sign this CoID...' RFC 2119 keyword, line 531: '... COSE MUST be used to sign this DevI...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 02, 2019) is 1933 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-05 == Outdated reference: A later version (-07) exists of draft-ietf-oauth-jwt-bcp-04 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 3 errors (**), 0 flaws (~~), 4 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: July 6, 2019 Universitaet Bremen TZI 6 M. Pritikin 7 Cisco 8 R. Moskowitz 9 Huawei 10 January 02, 2019 12 Concise Identities 13 draft-birkholz-core-coid-01 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 July 6, 2019. 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 2. Claims in a Concise Identity . . . . . . . . . . . . . . . . 4 64 2.1. iss: CWT issuer . . . . . . . . . . . . . . . . . . . . . 5 65 2.2. sub: CWT subject . . . . . . . . . . . . . . . . . . . . 5 66 2.3. aud: CWT audience . . . . . . . . . . . . . . . . . . . . 5 67 2.4. exp: CWT expiration time . . . . . . . . . . . . . . . . 5 68 2.5. nbf: CWT start of validity . . . . . . . . . . . . . . . 5 69 2.6. iat: CWT time of issue . . . . . . . . . . . . . . . . . 5 70 2.7. cti: CWT ID . . . . . . . . . . . . . . . . . . . . . . . 6 71 2.8. cnf: CWT proof-of-possession key claim . . . . . . . . . 6 72 3. Signature Envelope . . . . . . . . . . . . . . . . . . . . . 6 73 4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 6 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 78 7.2. Informative References . . . . . . . . . . . . . . . . . 7 79 Appendix A. Common Terminology on Identity Documents . . . . . . 8 80 A.1. Terms Specified in IEEE 802.1AR . . . . . . . . . . . . . 8 81 A.2. Terms Specified in RFC 4949 . . . . . . . . . . . . . . . 8 82 A.3. Terms specified in ISO/IEC 9594-8:2017 . . . . . . . . . 8 83 Appendix B. Concise Identities and Trust Relationships . . . . . 9 84 Appendix C. Concise Identity (CoID) CDDL Data Definition based 85 on RFC 5280 . . . . . . . . . . . . . . . . . . . . 10 86 Appendix D. Concise Secure Device Identifier (CoDeID) based on 87 IEEE 802.1AR-2018 . . . . . . . . . . . . . . . . . 10 88 D.1. The Intended Use of DevIDs . . . . . . . . . . . . . . . 10 89 D.2. DevID Flavors . . . . . . . . . . . . . . . . . . . . . . 11 90 D.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 D.4. Concise DevID CDDL data definition (sans COSE header) . . 12 92 Appendix E. Attic . . . . . . . . . . . . . . . . . . . . . . . 14 93 E.1. Examples of claims taken from IEEE 802.1AR identifiers . 14 94 E.1.1. 7.2.1 version . . . . . . . . . . . . . . . . . . . . 14 95 E.1.2. 7.2.2 serialNumber . . . . . . . . . . . . . . . . . 14 96 E.1.3. 7.2.3 signature . . . . . . . . . . . . . . . . . . . 14 97 E.1.4. 7.2.4 issuer Name . . . . . . . . . . . . . . . . . . 15 98 E.1.5. 7.2.5 authoritykeyidentifier . . . . . . . . . . . . 15 99 E.1.6. 7.2.7.1 notBefore . . . . . . . . . . . . . . . . . . 15 100 E.1.7. 7.2.7.2 notAfter . . . . . . . . . . . . . . . . . . 15 101 E.1.8. 7.2.8 subject . . . . . . . . . . . . . . . . . . . . 15 102 E.1.9. 7.2.10 subjectPublicKeyInfo . . . . . . . . . . . . . 15 103 E.1.10. 7.2.11 signatureAlgorithm . . . . . . . . . . . . . . 15 104 E.1.11. 7.2.12 signatureValue . . . . . . . . . . . . . . . . 15 105 E.2. Examples of claims taken from X.509 certificates . . . . 16 106 E.2.1. 2.5.29.35 - Authority Key Identifier . . . . . . . . 16 107 E.2.2. 2.5.29.14 - Subject Key Identifier . . . . . . . . . 16 108 E.2.3. 2.5.29.15 - Key Usage . . . . . . . . . . . . . . . . 16 109 E.2.4. 2.5.29.37 - Extended key usage . . . . . . . . . . . 16 110 E.2.5. 1.3.6.1.5.5.7.1.1 - Authority Information Access . . 16 111 E.2.6. 1.3.6.1.4.1.311.20.2 - Certificate Template Name 112 Domain Controller (Microsoft) . . . . . . . . . . . . 16 113 Appendix F. Graveyard . . . . . . . . . . . . . . . . . . . . . 16 114 F.1. 7.2.9 subjectAltName . . . . . . . . . . . . . . . . . . 17 115 F.2. 7.2.13 extensions . . . . . . . . . . . . . . . . . . . . 17 116 F.3. 2.5.29.31 - CRL Distribution Points . . . . . . . . . . . 17 117 F.4. 2.5.29.17 - Subject Alternative Name . . . . . . . . . . 17 118 F.5. 2.5.29.19 - Basic Constraints . . . . . . . . . . . . . . 17 119 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 122 1. Introduction 124 X.509 certificates [RFC5280] and Secure Device Identifier 125 [IEEE-802.1AR] are ASN.1 encoded Identity Documents and intended to 126 be tied to a system entity uniquely identified via these Identity 127 Documents. An Identity Document - in general, a public-key 128 certificate - can be conveyed to other system entities in order to 129 prove or authenticate the identity of the owner of the Identity 130 Document. Trust in the proof can be established by mutual trust of 131 the provider and assessor of the identity in a third party 132 verification (TVP) provided, for example, by a certificate authority 133 (CA) or its subsidiaries (sub CA). 135 The evidence a certificate comprises is typically composed of a set 136 of claims that is signed using secret keys issued by a (sub) CA. The 137 core set of claims included in a certificate - its attributes - are 138 well defined in the X.509v3 specifications and IEEE 802.1AR. 140 This document summarizes the core set of attributes and provides a 141 corresponding list of claims using concise integer labels to be used 142 in claim sets for CBOR Web Tokens (CWT) [RFC8392]. A resulting 143 Concise Identity (CoID) is able to represent a signed set of claims 144 that composes an Identity as defined in [RFC4949]. 146 The objective of using CWT as a basis for the signed claim sets 147 defined in this document is to gain more flexibility and at the same 148 time more rigorously defined semantics for the signed claim sets. In 149 addition, the benefits of using CBOR, COSE, and the corresponding CWT 150 structure accrue, including more compact encoding and a simpler 151 implementation in contrast to classical ASN.1 (DER/BER/PEM) 152 structures and the X.509 complexity and uncertainty that has accreted 153 since X.509 was released 29 years ago. One area where both the 154 compactness and the definiteness are highly desirable is in 155 Constrained-Node Networks [RFC7228], which may also make use of the 156 Constrained Application Protocol (CoAP, [RFC7252]); however, the area 157 of application of Concise Identities is not limited to constrained- 158 node networks. 160 The present version of this document is a strawman that attempts to 161 indicate the direction the work is intended to take. Not all 162 inspirations this version takes from X.509 maybe need to be taken. 164 1.1. Terminology 166 This document uses terminology from [RFC8392] and therefore also 167 [RFC7519], as well as from [RFC8152]. Specifically, we note: 169 Assertion: 171 Claim: A piece of information asserted about a subject. A claim is 172 represented as a name/value pair consisting of a Claim Name and a 173 Claim Value. 175 Claims are grouped into claims sets (represented here by a CWT), 176 which need to be interpreted as a whole. Note that this usage is a 177 bit different from idiomatic English usage, where a claim would stand 178 on its own. 180 (Note that the current version of this draft is not very explicit 181 about the relationship of identities and identifiers. To be done in 182 next version.) 184 2. Claims in a Concise Identity 186 A Concise Identity (CoID) is a CBOR Web Token [RFC8392] with certain 187 claims present. It can be signed in a number of ways, including a 188 COSE_Sign1 data object [RFC8152]. 190 2.1. iss: CWT issuer 192 Optional: identifies the principal that is the claimant for the 193 claims in the CoID ([RFC8392] Section 3.1.1, cf. Section 4.1.1 in 194 [RFC7519]). 196 o Note that this is a StringOrURI (if it contains a ":" it needs to 197 be a URI) 199 o For the "string" case (no ":"), there is no way to extract 200 meaningful components from the string 202 o Make it a URI if it needs to be structured (not for routine 203 retrieval, unless specified so by an application) 205 o If this URI looks like an HTTP or HTTPS URI then something 206 retrievable by humans should exist there. 208 o Alternatively, some arithmetic can be applied to the URI (extract 209 origin, add /.well-known/...) to find relevant information. 211 2.2. sub: CWT subject 213 Optional: identifies the principal that is the subject for the claims 214 in the CoID ([RFC8392] Section 3.1.2, cf. Section 4.1.2 in 215 [RFC7519]). 217 2.3. aud: CWT audience 219 Optional: identifies the recipients that the CoID is intended for 220 ([RFC8392] Section 3.1.4, cf. Section 4.1.4 in [RFC7519]). 222 2.4. exp: CWT expiration time 224 Optional: the time on or after which the CoID must no longer be 225 accepted for processing ([RFC8392] Section 3.1.4, cf. Section 4.1.4 226 in [RFC7519]). 228 2.5. nbf: CWT start of validity 230 Optional: the time before which the CoID must not be accepted for 231 processing ([RFC8392] Section 3.1.5, cf. Section 4.1.5 in [RFC7519]). 233 2.6. iat: CWT time of issue 235 Optional: the creation time of the CoID ([RFC8392] Section 3.1.6, cf. 236 Section 4.1.6 in [RFC7519]). 238 2.7. cti: CWT ID 240 The "cti" (CWT ID) claim provides a unique identifier for the CoID 241 ([RFC8392] Section 3.1.7, cf. "jti" in Section 4.1.7 in [RFC7519]). 243 CWT IDs are intended to be unique within an application, so they need 244 to be either coordinated between issuers or based on sufficient 245 randomness (e.g., 112 bits or more). 247 2.8. cnf: CWT proof-of-possession key claim 249 The "cnf" claim identifies the key that can be used by the subject 250 for proof-of-possession and provides parameters to identify the CWT 251 Confirmation Method ([I-D.ietf-ace-cwt-proof-of-possession] 252 Section 3.1). 254 3. Signature Envelope 256 The signature envelope [TBD: need not actually be envelope, may be 257 detached, too] carries additional information, e.g., the signature, 258 as well as the identification of the signature algorithm employed 259 (COSE: alg). Additional information may pertain to the signature (as 260 opposed to the claims being signed), e.g., a key id (COSE: kid) may 261 be given in the header of the signature. 263 4. Processing Rules 265 (TBD: This should contain some discussion of the processing rules 266 that apply for CoIDs. Some of this will just be pointers to 267 [I-D.ietf-oauth-jwt-bcp].) 269 5. IANA Considerations 271 This document makes no requests of IANA 273 6. Security Considerations 275 7. References 277 7.1. Normative References 279 [I-D.ietf-ace-cwt-proof-of-possession] 280 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 281 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 282 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 283 possession-05 (work in progress), November 2018. 285 [I-D.ietf-oauth-jwt-bcp] 286 Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best 287 Current Practices", draft-ietf-oauth-jwt-bcp-04 (work in 288 progress), November 2018. 290 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 291 Housley, R., and W. Polk, "Internet X.509 Public Key 292 Infrastructure Certificate and Certificate Revocation List 293 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 294 . 296 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 297 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 298 . 300 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 301 RFC 8152, DOI 10.17487/RFC8152, July 2017, 302 . 304 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 305 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 306 May 2018, . 308 7.2. Informative References 310 [IEEE-802.1AR] 311 "IEEE Standard for Local and Metropolitan Area Networks - 312 Secure Device Identity", IEEE standard, 313 DOI 10.1109/ieeestd.2018.8423794, n.d.. 315 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 316 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 317 . 319 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 320 RFC 5652, DOI 10.17487/RFC5652, September 2009, 321 . 323 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 324 Constrained-Node Networks", RFC 7228, 325 DOI 10.17487/RFC7228, May 2014, 326 . 328 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 329 Application Protocol (CoAP)", RFC 7252, 330 DOI 10.17487/RFC7252, June 2014, 331 . 333 Appendix A. Common Terminology on Identity Documents 335 To illustrate the purpose and intent of Identity Documents, 336 typically, terms, such as certificates, certificate chains/paths and 337 trust anchors, are used. To provide more context and for the 338 convenience of the reader, three sources of definitions are 339 highlighted in this section. 341 A.1. Terms Specified in IEEE 802.1AR 343 1. a certificate is "a digitally signed object that binds 344 information identifying an entity that possesses a secret private 345 key to the corresponding public key." 347 2. a certificate chain is "an ordered list of intermediate 348 certificates that links an end entity certificate ([...] a DevID 349 certificate) to a trust anchor." 351 3. a trust anchor is "a Certificate Authority that is trusted and 352 for which the trusting party holds information, usually in the 353 form of a self-signed certificate issued by the trust anchor". 355 A.2. Terms Specified in RFC 4949 357 1. a public-key certificate is "a digital certificate that binds a 358 system entity's identifier to a public key value, and possibly to 359 additional, secondary data items; i.e., a digitally signed data 360 structure that attests to the ownership of a public key". 362 2. a certification path is "a linked sequence of one or more public- 363 key certificates [...] that enables a certificate user to verify 364 the signature on the last certificate in the path, and thus 365 enables the user to obtain (from that last certificate) a 366 certified public key, or certified attributes, of the system 367 entity that is the subject of that last certificate". 369 3. a trust anchor is "a CA that is the subject of a trust anchor 370 certificate or otherwise establishes a trust anchor key". 371 Correspondingly, a trust anchor has a trust anchor certificate 372 that "is a public-key certificate that is used to provide the 373 first public key in a certification path". 375 A.3. Terms specified in ISO/IEC 9594-8:2017 377 1. a public-key certificate is "the public key of an entity, 378 together with some other information, rendered unforgeable by 379 digital signature with the private key of the certification 380 authority (CA) that issued it". 382 2. a certification path is "an ordered list of one or more public- 383 key certificates, starting with a public-key certificate signed 384 by the trust anchor, and ending with the end-entity public-key 385 certificate to be validated. All intermediate public-key 386 certificates, if any, are certification authority (CA) 387 certificates in which the subject of the preceding public-key 388 certificate is the issuer of the following public-key 389 certificate". 391 3. a trust anchor is "an entity that is trusted by a relying party 392 and used for validating public-key certificates". 394 Appendix B. Concise Identities and Trust Relationships 396 Following the terminology highlighted above, Concise Identities are 397 signed CBOR Web Tokens that compose public-key Identity Documents 398 based on asymmetric key pairs, potentially including additional 399 assertions: claims that are secondary data items. 401 In the context of certification paths, the "last certificate" in the 402 certification path is the Identity Document that resides on the 403 system component, which presents its Identity Document to relying 404 partyies in order to be authenticated. The "first certificate" in 405 the certification path resides on the trust anchor. 407 In order to be able to rely on the trust put into the Identity 408 Document presented to relying parties, these have to put trust into 409 two assumptions first: 411 o the corresponding trust anchor (certificate) is trusted. In 412 consequence, the consumer of the Identity Document requires a 413 basis for decision whether to rely on the trust put in the trust 414 anchor certificate, or not (e.g. via policies or a known 415 certification paths). 417 o the secret key included in the system component that is presenting 418 its Identity Document is protected. In consequence, the secret 419 key has to be stored in a shielded location. Type and quality of 420 the protection or shielding or even its location are assertions 421 that can be included as secondary data items in the Identity 422 Document. 424 In summary, a path of trust relationships between a system 425 component's Identity Document and a trusted authority's Identity 426 Document is required to enable transitive trust in the system 427 component that presents the Identity Document. 429 Appendix C. Concise Identity (CoID) CDDL Data Definition based on RFC 430 5280 432 COSE MUST be used to sign this CoID template flavor. 434 "signatureAlgorithm" and "signature" are not part of the CoID map but 435 of the COSE envelope. 437 CoID = { version: uint .range 1..3 ; (8) 438 issuer: text, ; iss(1) 439 subject: text / bytes, ; sub(2) 440 notAfter: uint, ; exp(4) 441 notBefore: uint ; nbf(5) 442 serialNumber: uint,; (7) 443 subjectPublicKeyInfo: [ algorithm: COSE-Algorithm-Value, 444 subjectPublicKey: bytes, 445 ], ;(9) 446 ? extensions: [ + [ extension-id: uint / registeredID, 447 extension-value: any, 448 ? criticality: bool, 449 ] 450 ], ;(0) 451 } 453 COSE-Algorithm-Value = uint .size 0..2 / nint .size 0..2 454 registeredID = [ + uint ] ; OID 456 extensions = 0 457 issuer = 1 458 subject = 2 459 notAfter = 4 460 notBefore = 5 461 serialNumber = 7 462 version = 8 463 subjectPublicKeyInfo = 9 465 Appendix D. Concise Secure Device Identifier (CoDeID) based on IEEE 466 802.1AR-2018 468 This section illustrates the context and background of Secure Device 469 Identifiers. 471 D.1. The Intended Use of DevIDs 473 IEEE 802.1AR Secure Device Identifier are a specific subset of X.509 474 Identity Documents that are intended to "authenticate a device's 475 identity", where the corresponding Identity Document is 476 "cryptographically bound to that device". In this context, 477 "cryptographically bound" means that the Identity Document is 478 "constructed using cryptographic operations to combine a secret with 479 other arbitrary data objects such that it may be proven that the 480 result could only be created by an entity having knowledge of the 481 secret." 483 While the intent of using X.509 Identity Documents as Device 484 Identifiers starts to blur the line between authentication and 485 authorization, the specification of IEEE 802.1AR Identity Documents 486 provides a meaningful subset of assertions that can be used to 487 identify one or more system components. The following CDDL data 488 definition maps the semantics of an RFC 5280 Public Key 489 Infrastructure Certificate Profile, which provides the basis for the 490 Secure Device Identifier semantics. Both are mapped to a CWT 491 representation. 493 D.2. DevID Flavors 495 In order to provide consistent semantics for the claims as defined 496 below, understanding the distinction of IDevIDs (mandatory 497 representation capabilities) and LDevIDs (recommended representation 498 capabilities) is of the essence. 500 Both flavors of Secure Device Identifiers share most of their 501 assertion semantics (claim sets). 503 IDevIDs are the _initially_ Secure Device Identifiers that "are 504 normally created during manufacturing or initial provisioning" and 505 are "installed on the device by the manufacturer". IDevIDs are 506 intended to be globally unique and to be stored in a way that 507 protects it from modification (typically, a shielded location). It 508 is important to note that a potential segregation of a manufacturer 509 into separate supply chain/tree entities is not covered by the 510 802.1AR specification. 512 LDevIDs are the _local significant_ Secure Device Identifiers that 513 are intended to be "unique in the local administrative domain in 514 which the device is used". In essence, LDevIDs "can be created at 515 any time [after IDevID provisioning], in accordance with local 516 policies". An "LDevID is bound to the device in a way that makes it 517 infeasible for it to be forged or transferred to a device with a 518 different IDevID without knowledge of the private key used to effect 519 the cryptographic binding". 521 D.3. Privacy 523 The exposition iof IDevID Identity Documents enables global unique 524 identification of a system component. To mitigate the obvious 525 privacy LDevIDs may also be used as the sole identifier (by disabling 526 the IDevID) to assure the privacy of the user of a DevID and the 527 equipment in which it is installed. 529 D.4. Concise DevID CDDL data definition (sans COSE header) 531 COSE MUST be used to sign this DevID flavor, if represented via CoID. 533 "signature" and "signatureValue" are not part of the CoID map but of 534 the COSE envelope. 536 "AlgorithmIdentifier" and corresponding "algorithm" and "parameters" 537 should be part of the COSE envelope. 539 CoDeID = { version: 3, ;(8) 540 serialNumber: uint,(7) 541 issuer: text, ; iss(1) 542 notAfter: uint, ; exp(4) 543 notBefore: uint ; nbf(5) 544 subject: text / URI, ; sub(2) 545 subjectPublicKeyInfo: [ algorithm: COSE-Algorithm-Value, 546 subjectPublicKey: bytes, 547 ], ;(9) 548 signatureAlgorithm: COSE-Algorithm-Value ; 802.1ar-2018 states 549 ; this must be identical 550 ; to cose sig-alg (rm?) 551 authorityKeyidentifier: bytes, ; all, non-critical, 552 ? subjectKeyIdentifier; bytes, ; only intermediates, non-critical 553 ? keyUsage : [ bitmask: bytes .size 1, 554 ? criticality: bool, 555 ] 556 ? subjectAltName: text / iPAddress / registeredID, 557 ? HardwareModuleName: [ hwType: registeredID, 558 hwSerialNum: bytes, 559 ], 560 ? extensions: [ + [ extension-id: uint, 561 extension-value: any, 562 ? criticality: bool, 563 ], 564 } 566 COSE-Algorithm-Value = uint .size 0..2 / nint .size 0..2 567 iPAddress = bytes .size 4 / bytes .size 16 568 registeredID = [ + uint ] ; OID 570 extensions = 0 571 issuer = 1 572 subject = 2 573 notAfter = 4 574 notBefore = 5 575 serialNumber = 7 576 version = 8 577 subjectPublicKeyInfo = 9 578 signatureAlgorithm = 10 579 authorityKeyidentifier = 11 580 subjectKeyIdentifier = 12 581 keyUsage = 13 ; could move to COSE header? 582 subjectAltName = 14 583 HardwareModuleName = 15 584 Appendix E. Attic 586 Notes and previous content that will be pruned in next versions. 588 E.1. Examples of claims taken from IEEE 802.1AR identifiers 590 This appendix briefly discusses common fields in a X.509 certificate 591 or an IEEE 802.1AR Secure Device Identifier and relates them to 592 claims in a CoID. 594 The original purpose of X.509 was only to sign the association 595 between a name and a public key. In principle, if something else 596 needs to be signed as well, CMS [RFC5652] is required. This 597 principle has not been strictly upheld over time; this is 598 demonstrated by the growth of various extensions to X.509 599 certificates that might or might not be interpreted to carry various 600 additional claims. 602 This document details only the claim sets for CBOR Web Tokens that 603 are necessary for authentication. The plausible integration or 604 replacement of ASN.1 formats in enrollment procotols, [D]TLS 605 handshakes and similar are not in scope of this document. 607 Subsections in this appendix are marked by the ASN.1 Object 608 Identifier (OID) typically used for the X.509 item. [TODO: Make this 609 true; there are still some section numbers.] 611 E.1.1. 7.2.1 version 613 The version field is typically not employed usefully in an X.509 614 certificate, except possibly in legacy applications that accept 615 original (pre-v3) X.509 certificates. 617 Generally, the point of versioning is to deliberately inhibit 618 interoperability (due to semantic meaning changes). CoIDs do not 619 employ versioning. Where future work requires semantic changes, 620 these will be expressed by making alternate kinds of claims. 622 E.1.2. 7.2.2 serialNumber 624 Covered by cti claim. 626 E.1.3. 7.2.3 signature 628 The signature, as well as the identification of the signature 629 algorithm, are provided by the COSE container (e.g., COSE_Sign1) used 630 to sign the CoID's CWT. 632 E.1.4. 7.2.4 issuer Name 634 Covered by iss claim. 636 E.1.5. 7.2.5 authoritykeyidentifier 638 Covered by COSE kid in signature, if needed. 640 E.1.6. 7.2.7.1 notBefore 642 Covered by nbf claim. 644 E.1.7. 7.2.7.2 notAfter 646 Covered by exp claim. 648 For Secured Device identifiers, this claim is typically left out. 650 o get a new one whenver you think you need it ("normal path") 652 o nonced ocsp? might benefit from a more lightweight freshness 653 verification of existing signed assertion - exploration required! 655 o (first party only verfiable freshness may be cheaper than third- 656 party verifiable?) 658 E.1.8. 7.2.8 subject 660 Covered by sub claim. 662 Note that if claim sets need to be made about multiple subjects, the 663 favored approach in CoID is to create multiple CoIDs, one each per 664 subject. 666 E.1.9. 7.2.10 subjectPublicKeyInfo 668 Covered by cnf claim. 670 E.1.10. 7.2.11 signatureAlgorithm 672 In COSE_Sign1 envelope. 674 E.1.11. 7.2.12 signatureValue 676 In COSE_Sign1 envelope. 678 E.2. Examples of claims taken from X.509 certificates 680 Most claims in X.509 certificates take the form of certificate 681 extensions. This section reviews a few common (and maybe not so 682 common) certificate extensions and assesses their usefulness in 683 signed claim sets. 685 E.2.1. 2.5.29.35 - Authority Key Identifier 687 Used in certificate chaining. Can be mapped to COSE "kid" of the 688 issuer. 690 E.2.2. 2.5.29.14 - Subject Key Identifier 692 Used in certificate chaining. Can be mapped to COSE "kid" in the 693 "cnf" (see Section 3.4 of [I-D.ietf-ace-cwt-proof-of-possession]). 695 E.2.3. 2.5.29.15 - Key Usage 697 Usage information for a key claim that is included in the signed 698 claims. Can be mapped to COSE "key_ops" [TBD: Explain details]. 700 E.2.4. 2.5.29.37 - Extended key usage 702 Can include additional usage information such as 1.3.6.1.5.5.7.3.1 703 for TLS server certificates or 1.3.6.1.5.5.7.3.2 for TLS client 704 certificates. 706 E.2.5. 1.3.6.1.5.5.7.1.1 - Authority Information Access 708 More information about the signer. May include a pointer to signers 709 higher up in the certificate chain (1.3.6.1.5.5.7.48.2), typically in 710 the form of a URI to their certificate. 712 E.2.6. 1.3.6.1.4.1.311.20.2 - Certificate Template Name Domain 713 Controller (Microsoft) 715 This is an example for many ill-defined extensions that are on some 716 arcs of the OID space somewhere. 718 E.g., the UCS-2 string (ASN.1 BMPString) "IPSECIntermediateOffline" 720 Appendix F. Graveyard 722 Items and Content that was already discarded. 724 F.1. 7.2.9 subjectAltName 726 (See "sub"). 728 F.2. 7.2.13 extensions 730 Extensions are handled by adding CWT claims to the CWT. 732 F.3. 2.5.29.31 - CRL Distribution Points 734 Usually URIs of places where a CRL germane to the certificate can be 735 obtained. Other forms of validating claim sets may be more 736 appropriate than CRLs for the applications envisaged here. 738 (Might be replaced by a more general freshness verification approach 739 later. For example one could define a generic "is this valid" 740 request to an authority.) 742 F.4. 2.5.29.17 - Subject Alternative Name 744 Additional names for the Subject. 746 These may be an "OtherName", i.e. a mistery blob "defined by" an 747 ASN.1 OID such as 1.3.6.1.4.1.9.21.2.3, or one out of a few formats 748 such as URIs (which may, then, turn out not to be really URIs). 749 Naming subjects obviously is a major issue that needs attention. 751 F.5. 2.5.29.19 - Basic Constraints 753 Can identify the key claim as that for a CA, and can limit the length 754 of a certificate path. Empty in all the examples analyzed. 756 Any application space can define new fields / claims as appropriate 757 and use them. There is no need for the underlying structure to 758 define an additional extension method for this. Instead, they can 759 use the registry as defined in Section 9.1 of [RFC8392].> 761 Acknowledgements 763 Authors' Addresses 765 Henk Birkholz 766 Fraunhofer SIT 767 Rheinstrasse 75 768 Darmstadt 64295 769 Germany 771 Email: henk.birkholz@sit.fraunhofer.de 772 Carsten Bormann 773 Universitaet Bremen TZI 774 Postfach 330440 775 Bremen D-28359 776 Germany 778 Phone: +49-421-218-63921 779 Email: cabo@tzi.org 781 Max Pritikin 782 Cisco 784 Email: pritikin@cisco.com 786 Robert Moskowitz 787 Huawei 788 Oak Park, MI 48237 790 Email: rgm@labs.htt-consult.com