CoRE Working Group H. Birkholz Internet-Draft Fraunhofer SIT Intended status: Informational C. Bormann Expires: January 2, 2019 Universitaet Bremen TZI M. Pritikin Cisco R. Moskowitz Huawei July 01, 2018 Concise Identities draft-birkholz-core-coid-00 Abstract There is an increased demand of trustworthy claim sets -- a set of system entity characteristics tied to an entity via signatures -- in order to provide information. Claim sets represented via CBOR Web Tokens (CWT) can compose a variety of evidence suitable for constrained-node networks and to support secure device automation. This document focuses on sets of identifiers and attributes that are tied to a system entity and are typically used to compose identities appropriate for Constrained RESTful Environment (CoRE) authentication needs. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 2, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Birkholz, et al. Expires January 2, 2019 [Page 1] Internet-Draft CoID July 2018 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Claims in a Concise Identity . . . . . . . . . . . . . . . . 4 2.1. iss: CWT issuer . . . . . . . . . . . . . . . . . . . . . 4 2.2. sub: CWT subject . . . . . . . . . . . . . . . . . . . . 5 2.3. aud: CWT audience . . . . . . . . . . . . . . . . . . . . 5 2.4. exp: CWT expiration time . . . . . . . . . . . . . . . . 5 2.5. nbf: CWT start of validity . . . . . . . . . . . . . . . 5 2.6. iat: CWT time of issue . . . . . . . . . . . . . . . . . 5 2.7. cti: CWT ID . . . . . . . . . . . . . . . . . . . . . . . 5 2.8. cnf: CWT proof-of-possession key claim . . . . . . . . . 5 3. Signature Envelope . . . . . . . . . . . . . . . . . . . . . 5 4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Appendix A. Examples of claims taken from IEEE 802.1AR identifiers . . . . . . . . . . . . . . . . . . . . 7 A.1. 7.2.1 version . . . . . . . . . . . . . . . . . . . . . . 8 A.2. 7.2.2 serialNumber . . . . . . . . . . . . . . . . . . . 8 A.3. 7.2.3 signature . . . . . . . . . . . . . . . . . . . . . 8 A.4. 7.2.4 issuer Name . . . . . . . . . . . . . . . . . . . . 8 A.5. 7.2.5 authoritykeyidentifier . . . . . . . . . . . . . . 8 A.6. 7.2.7.1 notBefore . . . . . . . . . . . . . . . . . . . . 8 A.7. 7.2.7.2 notAfter . . . . . . . . . . . . . . . . . . . . 8 A.8. 7.2.8 subject . . . . . . . . . . . . . . . . . . . . . . 9 A.9. 7.2.10 subjectPublicKeyInfo . . . . . . . . . . . . . . . 9 A.10. 7.2.11 signatureAlgorithm . . . . . . . . . . . . . . . . 9 A.11. 7.2.12 signatureValue . . . . . . . . . . . . . . . . . . 9 Appendix B. Examples of claims taken from X.509 certificates . . 9 B.1. 2.5.29.35 - Authority Key Identifier . . . . . . . . . . 9 B.2. 2.5.29.14 - Subject Key Identifier . . . . . . . . . . . 9 B.3. 2.5.29.15 - Key Usage . . . . . . . . . . . . . . . . . . 9 B.4. 2.5.29.37 - Extended key usage . . . . . . . . . . . . . 10 Birkholz, et al. Expires January 2, 2019 [Page 2] Internet-Draft CoID July 2018 B.5. 1.3.6.1.5.5.7.1.1 - Authority Information Access . . . . 10 B.6. 1.3.6.1.4.1.311.20.2 - Certificate Template Name Domain Controller (Microsoft) . . . . . . . . . . . . . . . . . 10 Appendix C. Graveyard . . . . . . . . . . . . . . . . . . . . . 10 C.1. 7.2.9 subjectAltName . . . . . . . . . . . . . . . . . . 10 C.2. 7.2.13 extensions . . . . . . . . . . . . . . . . . . . . 10 C.3. 2.5.29.31 - CRL Distribution Points . . . . . . . . . . . 10 C.4. 2.5.29.17 - Subject Alternative Name . . . . . . . . . . 10 C.5. 2.5.29.19 - Basic Constraints . . . . . . . . . . . . . . 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction X.509 certificates [RFC5280] and Secure Device Identifier [IEEE-802.1AR] are ASN.1 encoded identity documents and intended to be tied to a system entity uniquely identified via these identity documents. An identity document - a certificate - can be conveyed to other system entities in order to prove the identity of the owner of the identity document. Trust in the proof can be established by mutual trust of the provider and assessor of the identity in a third party verification (TVP) provided, for example, by a certificate authority (CA) or its subsidiaries (sub CA). The evidence a certificate comprises is typically composed of a set of claims that is signed using secret keys issued by a (sub) CA. The core set of claims included in a certificate - its attributes - are well defined in the X.509v3 specifications and IEEE 802.1AR. This document summarizes the core set of attributes and provides a corresponding list of claims using concise integer labels to be used in claim sets for CBOR Web Tokens (CWT) [RFC8392]. A resulting Concise Identity (CoID) is able to represent a signed set of claims that composes an Identity as defined in [RFC4949]. The objective of using CWT as a basis for the signed claim sets defined in this document is to gain more flexibility and at the same time more rigorously defined semantics for the signed claim sets. In addition, the benefits of using CBOR, COSE, and the corresponding CWT structure accrue, including more compact encoding and a simpler implementation in contrast to classical ASN.1 (DER/BER/PEM) structures and the X.509 complexity and uncertainty that has accreted since X.509 was released 29 years ago. One area where both the compactness and the definiteness are highly desirable is in Constrained-Node Networks [RFC7228], which may also make use of the Constrained Application Protocol (CoAP, [RFC7252]); however, the area of application of Concise Identities is not limited to constrained- node networks. Birkholz, et al. Expires January 2, 2019 [Page 3] Internet-Draft CoID July 2018 The present version of this document is a strawman that attempts to indicate the direction the work is intended to take. Not all inspirations this version takes from X.509 maybe need to be taken. 1.1. Terminology This document uses terminology from [RFC8392] and therefore also [RFC7519], as well as from [RFC8152]. Specifically, we note: Claim: A piece of information asserted about a subject. A claim is represented as a name/value pair consisting of a Claim Name and a Claim Value. Claims are grouped into claims sets (represented here by a CWT), which need to be interpreted as a whole. Note that this usage is a bit different from idiomatic English usage, where a claim would stand on its own. (Note that the current version of this draft is not very explicit about the relationship of identities and identifiers. To be done in next version.) 2. Claims in a Concise Identity A Concise Identity (CoID) is a CBOR Web Token [RFC8392] with certain claims present. It can be signed in a number of ways, including a COSE_Sign1 data object [RFC8152]. 2.1. iss: CWT issuer Optional: identifies the principal that is the claimant for the claims in the CoID ([RFC8392] Section 3.1.1, cf. Section 4.1.1 in [RFC7519]). o Note that this is a StringOrURI (if it contains a ":" it needs to be a URI) o For the "string" case (no ":"), there is no way to extract meaningful components from the string o Make it a URI if it needs to be structured (not for routine retrieval, unless specified so by an application) o If this URI looks like an HTTP or HTTPS URI then something retrievable by humans should exist there. o Alternatively, some arithmetic can be applied to the URI (extract origin, add /.well-known/...) to find relevant information. Birkholz, et al. Expires January 2, 2019 [Page 4] Internet-Draft CoID July 2018 2.2. sub: CWT subject Optional: identifies the principal that is the subject for the claims in the CoID ([RFC8392] Section 3.1.2, cf. Section 4.1.2 in [RFC7519]). 2.3. aud: CWT audience Optional: identifies the recipients that the CoID is intended for ([RFC8392] Section 3.1.4, cf. Section 4.1.4 in [RFC7519]). 2.4. exp: CWT expiration time Optional: the time on or after which the CoID must no longer be accepted for processing ([RFC8392] Section 3.1.4, cf. Section 4.1.4 in [RFC7519]). 2.5. nbf: CWT start of validity Optional: the time before which the CoID must not be accepted for processing ([RFC8392] Section 3.1.5, cf. Section 4.1.5 in [RFC7519]). 2.6. iat: CWT time of issue Optional: the creation time of the CoID ([RFC8392] Section 3.1.6, cf. Section 4.1.6 in [RFC7519]). 2.7. cti: CWT ID The "cti" (CWT ID) claim provides a unique identifier for the CoID ([RFC8392] Section 3.1.7, cf. "jti" in Section 4.1.7 in [RFC7519]). CWT IDs are intended to be unique within an application, so they need to be either coordinated between issuers or based on sufficient randomness (e.g., 112 bits or more). 2.8. cnf: CWT proof-of-possession key claim The "cnf" claim identifies the key that can be used by the subject for proof-of-possession and provides parameters to identify the CWT Confirmation Method ([I-D.ietf-ace-cwt-proof-of-possession] Section 3.1). 3. Signature Envelope The signature envelope [TBD: need not actually be envelope, may be detached, too] carries additional information, e.g., the signature, as well as the identification of the signature algorithm employed Birkholz, et al. Expires January 2, 2019 [Page 5] Internet-Draft CoID July 2018 (COSE: alg). Additional information may pertain to the signature (as opposed to the claims being signed), e.g., a key id (COSE: kid) may be given in the header of the signature. 4. Processing Rules (TBD: This should contain some discussion of the processing rules that apply for CoIDs. Some of this will just be pointers to [I-D.ietf-oauth-jwt-bcp].) 5. IANA Considerations This document makes no requests of IANA 6. Security Considerations 7. References 7.1. Normative References [I-D.ietf-ace-cwt-proof-of-possession] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- possession-03 (work in progress), June 2018. [I-D.ietf-oauth-jwt-bcp] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", draft-ietf-oauth-jwt-bcp-03 (work in progress), May 2018. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . Birkholz, et al. Expires January 2, 2019 [Page 6] Internet-Draft CoID July 2018 7.2. Informative References [IEEE-802.1AR] "ISO/IEC/IEEE International Standard for Information technology -- Telecommunications and information exchange between systems -- Local and metropolitan area networks -- Part 1AR: Secure device identity", IEEE standard, DOI 10.1109/ieeestd.2014.6739984, n.d.. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . Appendix A. Examples of claims taken from IEEE 802.1AR identifiers This appendix briefly discusses common fields in a X.509 certificate or an IEEE 802.1AR Secure Device Identifier and relates them to claims in a CoID. The original purpose of X.509 was only to sign the association between a name and a public key. In principle, if something else needs to be signed as well, CMS [RFC5652] is required. This principle has not been strictly upheld over time; this is demonstrated by the growth of various extensions to X.509 certificates that might or might not be interpreted to carry various additional claims. This document details only the claim sets for CBOR Web Tokens that are necessary for authentication. The plausible integration or replacement of ASN.1 formats in enrollment procotols, [D]TLS handshakes and similar are not in scope of this document. Birkholz, et al. Expires January 2, 2019 [Page 7] Internet-Draft CoID July 2018 Subsections in this appendix are marked by the ASN.1 Object Identifier (OID) typically used for the X.509 item. [TODO: Make this true; there are still some section numbers.] A.1. 7.2.1 version The version field is typically not employed usefully in an X.509 certificate, except possibly in legacy applications that accept original (pre-v3) X.509 certificates. Generally, the point of versioning is to deliberately inhibit interoperability (due to semantic meaning changes). CoIDs do not employ versioning. Where future work requires semantic changes, these will be expressed by making alternate kinds of claims. A.2. 7.2.2 serialNumber Covered by cti claim. A.3. 7.2.3 signature The signature, as well as the identification of the signature algorithm, are provided by the COSE container (e.g., COSE_Sign1) used to sign the CoID's CWT. A.4. 7.2.4 issuer Name Covered by iss claim. A.5. 7.2.5 authoritykeyidentifier Covered by COSE kid in signature, if needed. A.6. 7.2.7.1 notBefore Covered by nbf claim. A.7. 7.2.7.2 notAfter Covered by exp claim. For Secured Device identifiers, this claim is typically left out. o get a new one whenver you think you need it ("normal path") o nonced ocsp? might benefit from a more lightweight freshness verification of existing signed assertion - exploration required! Birkholz, et al. Expires January 2, 2019 [Page 8] Internet-Draft CoID July 2018 o (first party only verfiable freshness may be cheaper than third- party verifiable?) A.8. 7.2.8 subject Covered by sub claim. Note that if claim sets need to be made about multiple subjects, the favored approach in CoID is to create multiple CoIDs, one each per subject. A.9. 7.2.10 subjectPublicKeyInfo Covered by cnf claim. A.10. 7.2.11 signatureAlgorithm In COSE_Sign1 envelope. A.11. 7.2.12 signatureValue In COSE_Sign1 envelope. Appendix B. Examples of claims taken from X.509 certificates Most claims in X.509 certificates take the form of certificate extensions. This section reviews a few common (and maybe not so common) certificate extensions and assesses their usefulness in signed claim sets. B.1. 2.5.29.35 - Authority Key Identifier Used in certificate chaining. Can be mapped to COSE "kid" of the issuer. B.2. 2.5.29.14 - Subject Key Identifier Used in certificate chaining. Can be mapped to COSE "kid" in the "cnf" (see Section 3.4 of [I-D.ietf-ace-cwt-proof-of-possession]). B.3. 2.5.29.15 - Key Usage Usage information for a key claim that is included in the signed claims. Can be mapped to COSE "key_ops" [TBD: Explain details]. Birkholz, et al. Expires January 2, 2019 [Page 9] Internet-Draft CoID July 2018 B.4. 2.5.29.37 - Extended key usage Can include additional usage information such as 1.3.6.1.5.5.7.3.1 for TLS server certificates or 1.3.6.1.5.5.7.3.2 for TLS client certificates. B.5. 1.3.6.1.5.5.7.1.1 - Authority Information Access More information about the signer. May include a pointer to signers higher up in the certificate chain (1.3.6.1.5.5.7.48.2), typically in the form of a URI to their certificate. B.6. 1.3.6.1.4.1.311.20.2 - Certificate Template Name Domain Controller (Microsoft) This is an example for many ill-defined extensions that are on some arcs of the OID space somewhere. E.g., the UCS-2 string (ASN.1 BMPString) "IPSECIntermediateOffline" Appendix C. Graveyard C.1. 7.2.9 subjectAltName (See "sub"). C.2. 7.2.13 extensions Extensions are handled by adding CWT claims to the CWT. C.3. 2.5.29.31 - CRL Distribution Points Usually URIs of places where a CRL germane to the certificate can be obtained. Other forms of validating claim sets may be more appropriate than CRLs for the applications envisaged here. (Might be replaced by a more general freshness verification approach later. For example one could define a generic "is this valid" request to an authority.) C.4. 2.5.29.17 - Subject Alternative Name Additional names for the Subject. These may be an "OtherName", i.e. a mistery blob "defined by" an ASN.1 OID such as 1.3.6.1.4.1.9.21.2.3, or one out of a few formats such as URIs (which may, then, turn out not to be really URIs). Naming subjects obviously is a major issue that needs attention. Birkholz, et al. Expires January 2, 2019 [Page 10] Internet-Draft CoID July 2018 C.5. 2.5.29.19 - Basic Constraints Can identify the key claim as that for a CA, and can limit the length of a certificate path. Empty in all the examples analyzed. Any application space can define new fields / claims as appropriate and use them. There is no need for the underlying structure to define an additional extension method for this. Instead, they can use the registry as defined in Section 9.1 of [RFC8392].> Acknowledgements Authors' Addresses Henk Birkholz Fraunhofer SIT Rheinstrasse 75 Darmstadt 64295 Germany Email: henk.birkholz@sit.fraunhofer.de Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Max Pritikin Cisco Email: pritikin@cisco.com Robert Moskowitz Huawei Oak Park, MI 48237 Email: rgm@labs.htt-consult.com Birkholz, et al. Expires January 2, 2019 [Page 11]