idnits 2.17.1 draft-birkholz-core-coid-00.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 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 01, 2018) is 2126 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-03 == Outdated reference: A later version (-07) exists of draft-ietf-oauth-jwt-bcp-03 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 1 error (**), 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: January 2, 2019 Universitaet Bremen TZI 6 M. Pritikin 7 Cisco 8 R. Moskowitz 9 Huawei 10 July 01, 2018 12 Concise Identities 13 draft-birkholz-core-coid-00 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 2, 2019. 44 Copyright Notice 46 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . 5 71 2.8. cnf: CWT proof-of-possession key claim . . . . . . . . . 5 72 3. Signature Envelope . . . . . . . . . . . . . . . . . . . . . 5 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. Examples of claims taken from IEEE 802.1AR 80 identifiers . . . . . . . . . . . . . . . . . . . . 7 81 A.1. 7.2.1 version . . . . . . . . . . . . . . . . . . . . . . 8 82 A.2. 7.2.2 serialNumber . . . . . . . . . . . . . . . . . . . 8 83 A.3. 7.2.3 signature . . . . . . . . . . . . . . . . . . . . . 8 84 A.4. 7.2.4 issuer Name . . . . . . . . . . . . . . . . . . . . 8 85 A.5. 7.2.5 authoritykeyidentifier . . . . . . . . . . . . . . 8 86 A.6. 7.2.7.1 notBefore . . . . . . . . . . . . . . . . . . . . 8 87 A.7. 7.2.7.2 notAfter . . . . . . . . . . . . . . . . . . . . 8 88 A.8. 7.2.8 subject . . . . . . . . . . . . . . . . . . . . . . 9 89 A.9. 7.2.10 subjectPublicKeyInfo . . . . . . . . . . . . . . . 9 90 A.10. 7.2.11 signatureAlgorithm . . . . . . . . . . . . . . . . 9 91 A.11. 7.2.12 signatureValue . . . . . . . . . . . . . . . . . . 9 92 Appendix B. Examples of claims taken from X.509 certificates . . 9 93 B.1. 2.5.29.35 - Authority Key Identifier . . . . . . . . . . 9 94 B.2. 2.5.29.14 - Subject Key Identifier . . . . . . . . . . . 9 95 B.3. 2.5.29.15 - Key Usage . . . . . . . . . . . . . . . . . . 9 96 B.4. 2.5.29.37 - Extended key usage . . . . . . . . . . . . . 10 97 B.5. 1.3.6.1.5.5.7.1.1 - Authority Information Access . . . . 10 98 B.6. 1.3.6.1.4.1.311.20.2 - Certificate Template Name Domain 99 Controller (Microsoft) . . . . . . . . . . . . . . . . . 10 100 Appendix C. Graveyard . . . . . . . . . . . . . . . . . . . . . 10 101 C.1. 7.2.9 subjectAltName . . . . . . . . . . . . . . . . . . 10 102 C.2. 7.2.13 extensions . . . . . . . . . . . . . . . . . . . . 10 103 C.3. 2.5.29.31 - CRL Distribution Points . . . . . . . . . . . 10 104 C.4. 2.5.29.17 - Subject Alternative Name . . . . . . . . . . 10 105 C.5. 2.5.29.19 - Basic Constraints . . . . . . . . . . . . . . 11 106 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 109 1. Introduction 111 X.509 certificates [RFC5280] and Secure Device Identifier 112 [IEEE-802.1AR] are ASN.1 encoded identity documents and intended to 113 be tied to a system entity uniquely identified via these identity 114 documents. An identity document - a certificate - can be conveyed to 115 other system entities in order to prove the identity of the owner of 116 the identity document. Trust in the proof can be established by 117 mutual trust of the provider and assessor of the identity in a third 118 party verification (TVP) provided, for example, by a certificate 119 authority (CA) or its subsidiaries (sub CA). 121 The evidence a certificate comprises is typically composed of a set 122 of claims that is signed using secret keys issued by a (sub) CA. The 123 core set of claims included in a certificate - its attributes - are 124 well defined in the X.509v3 specifications and IEEE 802.1AR. 126 This document summarizes the core set of attributes and provides a 127 corresponding list of claims using concise integer labels to be used 128 in claim sets for CBOR Web Tokens (CWT) [RFC8392]. A resulting 129 Concise Identity (CoID) is able to represent a signed set of claims 130 that composes an Identity as defined in [RFC4949]. 132 The objective of using CWT as a basis for the signed claim sets 133 defined in this document is to gain more flexibility and at the same 134 time more rigorously defined semantics for the signed claim sets. In 135 addition, the benefits of using CBOR, COSE, and the corresponding CWT 136 structure accrue, including more compact encoding and a simpler 137 implementation in contrast to classical ASN.1 (DER/BER/PEM) 138 structures and the X.509 complexity and uncertainty that has accreted 139 since X.509 was released 29 years ago. One area where both the 140 compactness and the definiteness are highly desirable is in 141 Constrained-Node Networks [RFC7228], which may also make use of the 142 Constrained Application Protocol (CoAP, [RFC7252]); however, the area 143 of application of Concise Identities is not limited to constrained- 144 node networks. 146 The present version of this document is a strawman that attempts to 147 indicate the direction the work is intended to take. Not all 148 inspirations this version takes from X.509 maybe need to be taken. 150 1.1. Terminology 152 This document uses terminology from [RFC8392] and therefore also 153 [RFC7519], as well as from [RFC8152]. Specifically, we note: 155 Claim: A piece of information asserted about a subject. A claim is 156 represented as a name/value pair consisting of a Claim Name and a 157 Claim Value. 159 Claims are grouped into claims sets (represented here by a CWT), 160 which need to be interpreted as a whole. Note that this usage is a 161 bit different from idiomatic English usage, where a claim would stand 162 on its own. 164 (Note that the current version of this draft is not very explicit 165 about the relationship of identities and identifiers. To be done in 166 next version.) 168 2. Claims in a Concise Identity 170 A Concise Identity (CoID) is a CBOR Web Token [RFC8392] with certain 171 claims present. It can be signed in a number of ways, including a 172 COSE_Sign1 data object [RFC8152]. 174 2.1. iss: CWT issuer 176 Optional: identifies the principal that is the claimant for the 177 claims in the CoID ([RFC8392] Section 3.1.1, cf. Section 4.1.1 in 178 [RFC7519]). 180 o Note that this is a StringOrURI (if it contains a ":" it needs to 181 be a URI) 183 o For the "string" case (no ":"), there is no way to extract 184 meaningful components from the string 186 o Make it a URI if it needs to be structured (not for routine 187 retrieval, unless specified so by an application) 189 o If this URI looks like an HTTP or HTTPS URI then something 190 retrievable by humans should exist there. 192 o Alternatively, some arithmetic can be applied to the URI (extract 193 origin, add /.well-known/...) to find relevant information. 195 2.2. sub: CWT subject 197 Optional: identifies the principal that is the subject for the claims 198 in the CoID ([RFC8392] Section 3.1.2, cf. Section 4.1.2 in 199 [RFC7519]). 201 2.3. aud: CWT audience 203 Optional: identifies the recipients that the CoID is intended for 204 ([RFC8392] Section 3.1.4, cf. Section 4.1.4 in [RFC7519]). 206 2.4. exp: CWT expiration time 208 Optional: the time on or after which the CoID must no longer be 209 accepted for processing ([RFC8392] Section 3.1.4, cf. Section 4.1.4 210 in [RFC7519]). 212 2.5. nbf: CWT start of validity 214 Optional: the time before which the CoID must not be accepted for 215 processing ([RFC8392] Section 3.1.5, cf. Section 4.1.5 in [RFC7519]). 217 2.6. iat: CWT time of issue 219 Optional: the creation time of the CoID ([RFC8392] Section 3.1.6, cf. 220 Section 4.1.6 in [RFC7519]). 222 2.7. cti: CWT ID 224 The "cti" (CWT ID) claim provides a unique identifier for the CoID 225 ([RFC8392] Section 3.1.7, cf. "jti" in Section 4.1.7 in [RFC7519]). 227 CWT IDs are intended to be unique within an application, so they need 228 to be either coordinated between issuers or based on sufficient 229 randomness (e.g., 112 bits or more). 231 2.8. cnf: CWT proof-of-possession key claim 233 The "cnf" claim identifies the key that can be used by the subject 234 for proof-of-possession and provides parameters to identify the CWT 235 Confirmation Method ([I-D.ietf-ace-cwt-proof-of-possession] 236 Section 3.1). 238 3. Signature Envelope 240 The signature envelope [TBD: need not actually be envelope, may be 241 detached, too] carries additional information, e.g., the signature, 242 as well as the identification of the signature algorithm employed 243 (COSE: alg). Additional information may pertain to the signature (as 244 opposed to the claims being signed), e.g., a key id (COSE: kid) may 245 be given in the header of the signature. 247 4. Processing Rules 249 (TBD: This should contain some discussion of the processing rules 250 that apply for CoIDs. Some of this will just be pointers to 251 [I-D.ietf-oauth-jwt-bcp].) 253 5. IANA Considerations 255 This document makes no requests of IANA 257 6. Security Considerations 259 7. References 261 7.1. Normative References 263 [I-D.ietf-ace-cwt-proof-of-possession] 264 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 265 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 266 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 267 possession-03 (work in progress), June 2018. 269 [I-D.ietf-oauth-jwt-bcp] 270 Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best 271 Current Practices", draft-ietf-oauth-jwt-bcp-03 (work in 272 progress), May 2018. 274 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 275 Housley, R., and W. Polk, "Internet X.509 Public Key 276 Infrastructure Certificate and Certificate Revocation List 277 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 278 . 280 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 281 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 282 . 284 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 285 RFC 8152, DOI 10.17487/RFC8152, July 2017, 286 . 288 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 289 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 290 May 2018, . 292 7.2. Informative References 294 [IEEE-802.1AR] 295 "ISO/IEC/IEEE International Standard for Information 296 technology -- Telecommunications and information exchange 297 between systems -- Local and metropolitan area networks -- 298 Part 1AR: Secure device identity", IEEE standard, 299 DOI 10.1109/ieeestd.2014.6739984, n.d.. 301 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 302 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 303 . 305 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 306 RFC 5652, DOI 10.17487/RFC5652, September 2009, 307 . 309 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 310 Constrained-Node Networks", RFC 7228, 311 DOI 10.17487/RFC7228, May 2014, 312 . 314 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 315 Application Protocol (CoAP)", RFC 7252, 316 DOI 10.17487/RFC7252, June 2014, 317 . 319 Appendix A. Examples of claims taken from IEEE 802.1AR identifiers 321 This appendix briefly discusses common fields in a X.509 certificate 322 or an IEEE 802.1AR Secure Device Identifier and relates them to 323 claims in a CoID. 325 The original purpose of X.509 was only to sign the association 326 between a name and a public key. In principle, if something else 327 needs to be signed as well, CMS [RFC5652] is required. This 328 principle has not been strictly upheld over time; this is 329 demonstrated by the growth of various extensions to X.509 330 certificates that might or might not be interpreted to carry various 331 additional claims. 333 This document details only the claim sets for CBOR Web Tokens that 334 are necessary for authentication. The plausible integration or 335 replacement of ASN.1 formats in enrollment procotols, [D]TLS 336 handshakes and similar are not in scope of this document. 338 Subsections in this appendix are marked by the ASN.1 Object 339 Identifier (OID) typically used for the X.509 item. [TODO: Make this 340 true; there are still some section numbers.] 342 A.1. 7.2.1 version 344 The version field is typically not employed usefully in an X.509 345 certificate, except possibly in legacy applications that accept 346 original (pre-v3) X.509 certificates. 348 Generally, the point of versioning is to deliberately inhibit 349 interoperability (due to semantic meaning changes). CoIDs do not 350 employ versioning. Where future work requires semantic changes, 351 these will be expressed by making alternate kinds of claims. 353 A.2. 7.2.2 serialNumber 355 Covered by cti claim. 357 A.3. 7.2.3 signature 359 The signature, as well as the identification of the signature 360 algorithm, are provided by the COSE container (e.g., COSE_Sign1) used 361 to sign the CoID's CWT. 363 A.4. 7.2.4 issuer Name 365 Covered by iss claim. 367 A.5. 7.2.5 authoritykeyidentifier 369 Covered by COSE kid in signature, if needed. 371 A.6. 7.2.7.1 notBefore 373 Covered by nbf claim. 375 A.7. 7.2.7.2 notAfter 377 Covered by exp claim. 379 For Secured Device identifiers, this claim is typically left out. 381 o get a new one whenver you think you need it ("normal path") 383 o nonced ocsp? might benefit from a more lightweight freshness 384 verification of existing signed assertion - exploration required! 386 o (first party only verfiable freshness may be cheaper than third- 387 party verifiable?) 389 A.8. 7.2.8 subject 391 Covered by sub claim. 393 Note that if claim sets need to be made about multiple subjects, the 394 favored approach in CoID is to create multiple CoIDs, one each per 395 subject. 397 A.9. 7.2.10 subjectPublicKeyInfo 399 Covered by cnf claim. 401 A.10. 7.2.11 signatureAlgorithm 403 In COSE_Sign1 envelope. 405 A.11. 7.2.12 signatureValue 407 In COSE_Sign1 envelope. 409 Appendix B. Examples of claims taken from X.509 certificates 411 Most claims in X.509 certificates take the form of certificate 412 extensions. This section reviews a few common (and maybe not so 413 common) certificate extensions and assesses their usefulness in 414 signed claim sets. 416 B.1. 2.5.29.35 - Authority Key Identifier 418 Used in certificate chaining. Can be mapped to COSE "kid" of the 419 issuer. 421 B.2. 2.5.29.14 - Subject Key Identifier 423 Used in certificate chaining. Can be mapped to COSE "kid" in the 424 "cnf" (see Section 3.4 of [I-D.ietf-ace-cwt-proof-of-possession]). 426 B.3. 2.5.29.15 - Key Usage 428 Usage information for a key claim that is included in the signed 429 claims. Can be mapped to COSE "key_ops" [TBD: Explain details]. 431 B.4. 2.5.29.37 - Extended key usage 433 Can include additional usage information such as 1.3.6.1.5.5.7.3.1 434 for TLS server certificates or 1.3.6.1.5.5.7.3.2 for TLS client 435 certificates. 437 B.5. 1.3.6.1.5.5.7.1.1 - Authority Information Access 439 More information about the signer. May include a pointer to signers 440 higher up in the certificate chain (1.3.6.1.5.5.7.48.2), typically in 441 the form of a URI to their certificate. 443 B.6. 1.3.6.1.4.1.311.20.2 - Certificate Template Name Domain Controller 444 (Microsoft) 446 This is an example for many ill-defined extensions that are on some 447 arcs of the OID space somewhere. 449 E.g., the UCS-2 string (ASN.1 BMPString) "IPSECIntermediateOffline" 451 Appendix C. Graveyard 453 C.1. 7.2.9 subjectAltName 455 (See "sub"). 457 C.2. 7.2.13 extensions 459 Extensions are handled by adding CWT claims to the CWT. 461 C.3. 2.5.29.31 - CRL Distribution Points 463 Usually URIs of places where a CRL germane to the certificate can be 464 obtained. Other forms of validating claim sets may be more 465 appropriate than CRLs for the applications envisaged here. 467 (Might be replaced by a more general freshness verification approach 468 later. For example one could define a generic "is this valid" 469 request to an authority.) 471 C.4. 2.5.29.17 - Subject Alternative Name 473 Additional names for the Subject. 475 These may be an "OtherName", i.e. a mistery blob "defined by" an 476 ASN.1 OID such as 1.3.6.1.4.1.9.21.2.3, or one out of a few formats 477 such as URIs (which may, then, turn out not to be really URIs). 478 Naming subjects obviously is a major issue that needs attention. 480 C.5. 2.5.29.19 - Basic Constraints 482 Can identify the key claim as that for a CA, and can limit the length 483 of a certificate path. Empty in all the examples analyzed. 485 Any application space can define new fields / claims as appropriate 486 and use them. There is no need for the underlying structure to 487 define an additional extension method for this. Instead, they can 488 use the registry as defined in Section 9.1 of [RFC8392].> 490 Acknowledgements 492 Authors' Addresses 494 Henk Birkholz 495 Fraunhofer SIT 496 Rheinstrasse 75 497 Darmstadt 64295 498 Germany 500 Email: henk.birkholz@sit.fraunhofer.de 502 Carsten Bormann 503 Universitaet Bremen TZI 504 Postfach 330440 505 Bremen D-28359 506 Germany 508 Phone: +49-421-218-63921 509 Email: cabo@tzi.org 511 Max Pritikin 512 Cisco 514 Email: pritikin@cisco.com 516 Robert Moskowitz 517 Huawei 518 Oak Park, MI 48237 520 Email: rgm@labs.htt-consult.com