| CoRE Working Group | H. Birkholz |
| Internet-Draft | Fraunhofer SIT |
| Intended status: Informational | C. Bormann |
| Expires: January 7, 2020 | Universität Bremen TZI |
| M. Pritikin | |
| Cisco | |
| R. Moskowitz | |
| Huawei | |
| July 06, 2019 |
Concise Identities
draft-birkholz-core-coid-02
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.
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 7, 2020.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include 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.
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 - in general, a public-key certificate - can be conveyed to other system entities in order to prove or authenticate 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.
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.
This document uses terminology from [RFC8392] and therefore also [RFC7519], as well as from [RFC8152]. Specifically, we note:
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.)
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
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].
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]).
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]).
Optional: identifies the recipients that the CoID is intended for ([RFC8392] Section 3.1.4, cf. Section 4.1.4 in [RFC7519]).
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]).
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]).
Optional: the creation time of the CoID ([RFC8392] Section 3.1.6, cf. Section 4.1.6 in [RFC7519]).
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).
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).
As highlighted above, the base definition of the representation of the “sub claim” is already covered by [RFC8392] and [RFC7519].
If claim sets need to be made about multiple subjects, the favored approach in CoID is to create multiple CoIDs, one each per subject.
In certain cases, the subject of a CoID needs to be an X.500 Distinguished Name in its full glory. These are sequences of relative names, where each relative name has a relative name type and a (text string) value.
dn-subject = [*(relativenametype, relativenamevalue)]
(RFC 5280 does not appear to specify how many DN components must be in a DN, so this uses a zero or more quantity.)
Any RelativeDistinguishedName values that are SETs of more than one AttributeTypeAndValue are translated into a sequence of pairs of the nametype used and each of the namevalues, lexicographically sorted.
To be able to map these to CBOR, we define labels for the relative name types listed in Section 4.1.2.4 of [RFC5280]:
(Note that unusual relative name types could be represented as OIDs; this would probably best be done by reviving the currently dormant [I-D.bormann-cbor-tags-oid].)
relativenametype = &( country: 1 organization: 2 organizational-unit: 3 distinguished-name-qualifier: 4 state-or-province-name: 5 common-name: 6 serial-number: 7 locality: 8 title: 9 surname: 10 given-name: 11 initials: 12 pseudonym: 13 generation-qualifier: 14 )
The relative name values for these types are always expressed as CBOR text strings, i.e., in UTF-8:
relativenamevalue = text
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 (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.
(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].)
This document makes no requests of IANA
To illustrate the purpose and intent of Identity Documents, typically, terms, such as certificates, certificate chains/paths and trust anchors, are used. To provide more context and for the convenience of the reader, three sources of definitions are highlighted in this section.
Following the terminology highlighted above, Concise Identities are signed CBOR Web Tokens that compose public-key Identity Documents based on asymmetric key pairs, potentially including additional assertions: claims that are secondary data items.
In the context of certification paths, the “last certificate” in the certification path is the Identity Document that resides on the system component, which presents its Identity Document to relying partyies in order to be authenticated. The “first certificate” in the certification path resides on the trust anchor.
In order to be able to rely on the trust put into the Identity Document presented to relying parties, these have to put trust into two assumptions first:
In summary, a path of trust relationships between a system component’s Identity Document and a trusted authority’s Identity Document is required to enable transitive trust in the system component that presents the Identity Document.
COSE MUST be used to sign this CoID template flavor.
“signatureAlgorithm” and “signature” are not part of the CoID map but of the COSE envelope.
CoID = { version: uint .range 1..3 ; (8)
issuer: text, ; iss(1)
subject: text / bytes, ; sub(2)
notAfter: uint, ; exp(4)
notBefore: uint ; nbf(5)
serialNumber: uint,; (7)
subjectPublicKeyInfo: [ algorithm: COSE-Algorithm-Value,
subjectPublicKey: bytes,
], ;(9)
? extensions: [ + [ extension-id: uint / registeredID,
extension-value: any,
? criticality: bool,
]
], ;(0)
}
COSE-Algorithm-Value = uint .size 0..2 / nint .size 0..2
registeredID = [ + uint ] ; OID
extensions = 0
issuer = 1
subject = 2
notAfter = 4
notBefore = 5
serialNumber = 7
version = 8
subjectPublicKeyInfo = 9
This section illustrates the context and background of Secure Device Identifiers.
IEEE 802.1AR Secure Device Identifier are a specific subset of X.509 Identity Documents that are intended to “authenticate a device’s identity”, where the corresponding Identity Document is “cryptographically bound to that device”. In this context, “cryptographically bound” means that the Identity Document is “constructed using cryptographic operations to combine a secret with other arbitrary data objects such that it may be proven that the result could only be created by an entity having knowledge of the secret.”
While the intent of using X.509 Identity Documents as Device Identifiers starts to blur the line between authentication and authorization, the specification of IEEE 802.1AR Identity Documents provides a meaningful subset of assertions that can be used to identify one or more system components. The following CDDL data definition maps the semantics of an RFC 5280 Public Key Infrastructure Certificate Profile, which provides the basis for the Secure Device Identifier semantics. Both are mapped to a CWT representation.
In order to provide consistent semantics for the claims as defined below, understanding the distinction of IDevIDs (mandatory representation capabilities) and LDevIDs (recommended representation capabilities) is of the essence.
Both flavors of Secure Device Identifiers share most of their assertion semantics (claim sets).
IDevIDs are the initially Secure Device Identifiers that “are normally created during manufacturing or initial provisioning” and are “installed on the device by the manufacturer”. IDevIDs are intended to be globally unique and to be stored in a way that protects it from modification (typically, a shielded location). It is important to note that a potential segregation of a manufacturer into separate supply chain/tree entities is not covered by the 802.1AR specification.
LDevIDs are the local significant Secure Device Identifiers that are intended to be “unique in the local administrative domain in which the device is used”. In essence, LDevIDs “can be created at any time [after IDevID provisioning], in accordance with local policies”. An “LDevID is bound to the device in a way that makes it infeasible for it to be forged or transferred to a device with a different IDevID without knowledge of the private key used to effect the cryptographic binding”.
The exposition iof IDevID Identity Documents enables global unique identification of a system component. To mitigate the obvious privacy LDevIDs may also be used as the sole identifier (by disabling the IDevID) to assure the privacy of the user of a DevID and the equipment in which it is installed.
COSE MUST be used to sign this DevID flavor, if represented via CoID.
“signature” and “signatureValue” are not part of the CoID map but of the COSE envelope.
“AlgorithmIdentifier” and corresponding “algorithm” and “parameters” should be part of the COSE envelope.
CoDeID = { version: 3, ;(8)
serialNumber: uint,(7)
issuer: text, ; iss(1)
notAfter: uint, ; exp(4)
notBefore: uint ; nbf(5)
subject: text / URI, ; sub(2)
subjectPublicKeyInfo: [ algorithm: COSE-Algorithm-Value,
subjectPublicKey: bytes,
], ;(9)
signatureAlgorithm: COSE-Algorithm-Value ; 802.1ar-2018 states
; this must be identical
; to cose sig-alg (rm?)
authorityKeyidentifier: bytes, ; all, non-critical,
? subjectKeyIdentifier; bytes, ; only intermediates, non-critical
? keyUsage : [ bitmask: bytes .size 1,
? criticality: bool,
]
? subjectAltName: text / iPAddress / registeredID,
? HardwareModuleName: [ hwType: registeredID,
hwSerialNum: bytes,
],
? extensions: [ + [ extension-id: uint,
extension-value: any,
? criticality: bool,
],
}
COSE-Algorithm-Value = uint .size 0..2 / nint .size 0..2
iPAddress = bytes .size 4 / bytes .size 16
registeredID = [ + uint ] ; OID
extensions = 0
issuer = 1
subject = 2
notAfter = 4
notBefore = 5
serialNumber = 7
version = 8
subjectPublicKeyInfo = 9
signatureAlgorithm = 10
authorityKeyidentifier = 11
subjectKeyIdentifier = 12
keyUsage = 13 ; could move to COSE header?
subjectAltName = 14
HardwareModuleName = 15
Additional well-defined sets of characteristics can be bound to Identity Documents [RFC5280] or Secure Device Identifiers [IEEE-802.1AR]. CDDL specifications to define these can be found in the corresponding appendices above and the Profile for X.509 Internet Attribute Certificates is defined in [RFC5755].
Essentially, various existing CWT specializations, such as the Entity Attestation Tokens [I-D.ietf-rats-eat] and the Platform Security Architecture Tokens [I-D.tschofenig-rats-psa-token] already compose a type of Attribute Certificates today. In order to bridge the gap between these already existing Concise Attribute Documents and binding them to traditional X.509 Identity Documents (pub-key certificates), a sub claim referencing the corresponding Identity Document has to be included in the signed CBOR Web Token (flavor). The mechanics of how to handle the corresponding key material is also defined in [RFC5755] (and this document will elaborate on these in future versions).
With respect to Concise Identity Documents the dn-subject claim should be used. If a Concise Attribute Certificate has to refer to a traditional ASN.1 encoded X.509 Identity document the subject claim should be used. This procedure provides a migration path from ASN.1 encoded Identity documents [RFC5280] to CBOR encoded Concise Identity documents that allows to bind Concise Attribute Documents, such as EAT or PSA Tokens to both kinds of certificates. In an ideal scenario CBOR encoding in the form of [RFC8392] is used both for Concise Identity Documents and Concise Attribute Documents. The alternate uses of subject claims or dn-subject claims addresses the fact that the vast majority of constrained node devices still use an ASN.1 encoding and simplified interoperability between CBOR encoded and ASN.1 encoded documents is still of essence today.
Notes and previous content that will be pruned in next versions.
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 protocols, (D)TLS handshakes and similar are not in scope of this document.
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.]
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.
Covered by cti claim.
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.
Covered by iss claim.
Covered by COSE kid in signature, if needed.
Covered by nbf claim.
Covered by exp claim.
For Secured Device identifiers, this claim is typically left out.
Covered by cnf claim.
In COSE_Sign1 envelope.
In COSE_Sign1 envelope.
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.
Used in certificate chaining. Can be mapped to COSE kid of the issuer.
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]).
Usage information for a key claim that is included in the signed claims. Can be mapped to COSE key_ops [TBD: Explain details].
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.
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.
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
Items and Content that was already discarded.
(See “sub”).
Extensions are handled by adding CWT claims to the CWT.
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.)
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.
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].>