< draft-birkholz-core-coid-01.txt   draft-birkholz-core-coid-02.txt >
CoRE Working Group H. Birkholz CoRE Working Group H. Birkholz
Internet-Draft Fraunhofer SIT Internet-Draft Fraunhofer SIT
Intended status: Informational C. Bormann Intended status: Informational C. Bormann
Expires: July 6, 2019 Universitaet Bremen TZI Expires: January 7, 2020 Universitaet Bremen TZI
M. Pritikin M. Pritikin
Cisco Cisco
R. Moskowitz R. Moskowitz
Huawei Huawei
January 02, 2019 July 06, 2019
Concise Identities Concise Identities
draft-birkholz-core-coid-01 draft-birkholz-core-coid-02
Abstract Abstract
There is an increased demand of trustworthy claim sets -- a set of There is an increased demand of trustworthy claim sets -- a set of
system entity characteristics tied to an entity via signatures -- in system entity characteristics tied to an entity via signatures -- in
order to provide information. Claim sets represented via CBOR Web order to provide information. Claim sets represented via CBOR Web
Tokens (CWT) can compose a variety of evidence suitable for Tokens (CWT) can compose a variety of evidence suitable for
constrained-node networks and to support secure device automation. constrained-node networks and to support secure device automation.
This document focuses on sets of identifiers and attributes that are This document focuses on sets of identifiers and attributes that are
tied to a system entity and are typically used to compose identities tied to a system entity and are typically used to compose identities
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 6, 2019. This Internet-Draft will expire on January 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Claims in a Concise Identity . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Claims in a Concise Identity . . . . . . . . . . . . . . . . 5
2.1. iss: CWT issuer . . . . . . . . . . . . . . . . . . . . . 5 2.1. iss: CWT issuer . . . . . . . . . . . . . . . . . . . . . 5
2.2. sub: CWT subject . . . . . . . . . . . . . . . . . . . . 5 2.2. sub: CWT subject . . . . . . . . . . . . . . . . . . . . 5
2.3. aud: CWT audience . . . . . . . . . . . . . . . . . . . . 5 2.3. aud: CWT audience . . . . . . . . . . . . . . . . . . . . 5
2.4. exp: CWT expiration time . . . . . . . . . . . . . . . . 5 2.4. exp: CWT expiration time . . . . . . . . . . . . . . . . 5
2.5. nbf: CWT start of validity . . . . . . . . . . . . . . . 5 2.5. nbf: CWT start of validity . . . . . . . . . . . . . . . 6
2.6. iat: CWT time of issue . . . . . . . . . . . . . . . . . 5 2.6. iat: CWT time of issue . . . . . . . . . . . . . . . . . 6
2.7. cti: CWT ID . . . . . . . . . . . . . . . . . . . . . . . 6 2.7. cti: CWT ID . . . . . . . . . . . . . . . . . . . . . . . 6
2.8. cnf: CWT proof-of-possession key claim . . . . . . . . . 6 2.8. cnf: CWT proof-of-possession key claim . . . . . . . . . 6
3. Signature Envelope . . . . . . . . . . . . . . . . . . . . . 6 3. The Essential Qualities of the Subject Claim . . . . . . . . 6
4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 6 4. Signature Envelope . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Common Terminology on Identity Documents . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 9
A.1. Terms Specified in IEEE 802.1AR . . . . . . . . . . . . . 8 Appendix A. Common Terminology on Identity Documents . . . . . . 10
A.2. Terms Specified in RFC 4949 . . . . . . . . . . . . . . . 8 A.1. Terms Specified in IEEE 802.1AR . . . . . . . . . . . . . 10
A.3. Terms specified in ISO/IEC 9594-8:2017 . . . . . . . . . 8 A.2. Terms Specified in RFC 4949 . . . . . . . . . . . . . . . 10
Appendix B. Concise Identities and Trust Relationships . . . . . 9 A.3. Terms specified in ISO/IEC 9594-8:2017 . . . . . . . . . 11
Appendix B. Concise Identities and Trust Relationships . . . . . 11
Appendix C. Concise Identity (CoID) CDDL Data Definition based Appendix C. Concise Identity (CoID) CDDL Data Definition based
on RFC 5280 . . . . . . . . . . . . . . . . . . . . 10 on RFC 5280 . . . . . . . . . . . . . . . . . . . . 12
Appendix D. Concise Secure Device Identifier (CoDeID) based on Appendix D. Concise Secure Device Identifier (CoDeID) based on
IEEE 802.1AR-2018 . . . . . . . . . . . . . . . . . 10 IEEE 802.1AR-2018 . . . . . . . . . . . . . . . . . 12
D.1. The Intended Use of DevIDs . . . . . . . . . . . . . . . 10 D.1. The Intended Use of DevIDs . . . . . . . . . . . . . . . 13
D.2. DevID Flavors . . . . . . . . . . . . . . . . . . . . . . 11 D.2. DevID Flavors . . . . . . . . . . . . . . . . . . . . . . 13
D.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 12 D.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 14
D.4. Concise DevID CDDL data definition (sans COSE header) . . 12 D.4. Concise DevID CDDL data definition (sans COSE header) . . 14
Appendix E. Attic . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix E. Concise Attribute Documents . . . . . . . . . . . . 16
E.1. Examples of claims taken from IEEE 802.1AR identifiers . 14 Appendix F. Attic . . . . . . . . . . . . . . . . . . . . . . . 16
E.1.1. 7.2.1 version . . . . . . . . . . . . . . . . . . . . 14 F.1. Examples of claims taken from IEEE 802.1AR identifiers . 16
E.1.2. 7.2.2 serialNumber . . . . . . . . . . . . . . . . . 14 F.1.1. 7.2.1 version . . . . . . . . . . . . . . . . . . . . 17
E.1.3. 7.2.3 signature . . . . . . . . . . . . . . . . . . . 14 F.1.2. 7.2.2 serialNumber . . . . . . . . . . . . . . . . . 17
E.1.4. 7.2.4 issuer Name . . . . . . . . . . . . . . . . . . 15 F.1.3. 7.2.3 signature . . . . . . . . . . . . . . . . . . . 17
E.1.5. 7.2.5 authoritykeyidentifier . . . . . . . . . . . . 15 F.1.4. 7.2.4 issuer Name . . . . . . . . . . . . . . . . . . 17
E.1.6. 7.2.7.1 notBefore . . . . . . . . . . . . . . . . . . 15 F.1.5. 7.2.5 authoritykeyidentifier . . . . . . . . . . . . 17
E.1.7. 7.2.7.2 notAfter . . . . . . . . . . . . . . . . . . 15 F.1.6. 7.2.7.1 notBefore . . . . . . . . . . . . . . . . . . 17
E.1.8. 7.2.8 subject . . . . . . . . . . . . . . . . . . . . 15 F.1.7. 7.2.7.2 notAfter . . . . . . . . . . . . . . . . . . 18
E.1.9. 7.2.10 subjectPublicKeyInfo . . . . . . . . . . . . . 15 F.1.8. 7.2.10 subjectPublicKeyInfo . . . . . . . . . . . . . 18
E.1.10. 7.2.11 signatureAlgorithm . . . . . . . . . . . . . . 15 F.1.9. 7.2.11 signatureAlgorithm . . . . . . . . . . . . . . 18
E.1.11. 7.2.12 signatureValue . . . . . . . . . . . . . . . . 15 F.1.10. 7.2.12 signatureValue . . . . . . . . . . . . . . . . 18
E.2. Examples of claims taken from X.509 certificates . . . . 16 F.2. Examples of claims taken from X.509 certificates . . . . 18
E.2.1. 2.5.29.35 - Authority Key Identifier . . . . . . . . 16 F.2.1. 2.5.29.35 - Authority Key Identifier . . . . . . . . 18
E.2.2. 2.5.29.14 - Subject Key Identifier . . . . . . . . . 16 F.2.2. 2.5.29.14 - Subject Key Identifier . . . . . . . . . 18
E.2.3. 2.5.29.15 - Key Usage . . . . . . . . . . . . . . . . 16 F.2.3. 2.5.29.15 - Key Usage . . . . . . . . . . . . . . . . 18
E.2.4. 2.5.29.37 - Extended key usage . . . . . . . . . . . 16 F.2.4. 2.5.29.37 - Extended key usage . . . . . . . . . . . 19
E.2.5. 1.3.6.1.5.5.7.1.1 - Authority Information Access . . 16 F.2.5. 1.3.6.1.5.5.7.1.1 - Authority Information Access . . 19
E.2.6. 1.3.6.1.4.1.311.20.2 - Certificate Template Name F.2.6. 1.3.6.1.4.1.311.20.2 - Certificate Template Name
Domain Controller (Microsoft) . . . . . . . . . . . . 16 Domain Controller (Microsoft) . . . . . . . . . . . . 19
Appendix F. Graveyard . . . . . . . . . . . . . . . . . . . . . 16 Appendix G. Graveyard . . . . . . . . . . . . . . . . . . . . . 19
F.1. 7.2.9 subjectAltName . . . . . . . . . . . . . . . . . . 17 G.1. 7.2.9 subjectAltName . . . . . . . . . . . . . . . . . . 19
F.2. 7.2.13 extensions . . . . . . . . . . . . . . . . . . . . 17 G.2. 7.2.13 extensions . . . . . . . . . . . . . . . . . . . . 19
F.3. 2.5.29.31 - CRL Distribution Points . . . . . . . . . . . 17 G.3. 2.5.29.31 - CRL Distribution Points . . . . . . . . . . . 19
F.4. 2.5.29.17 - Subject Alternative Name . . . . . . . . . . 17 G.4. 2.5.29.17 - Subject Alternative Name . . . . . . . . . . 19
F.5. 2.5.29.19 - Basic Constraints . . . . . . . . . . . . . . 17 G.5. 2.5.29.19 - Basic Constraints . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
X.509 certificates [RFC5280] and Secure Device Identifier X.509 certificates [RFC5280] and Secure Device Identifier
[IEEE-802.1AR] are ASN.1 encoded Identity Documents and intended to [IEEE-802.1AR] are ASN.1 encoded Identity Documents and intended to
be tied to a system entity uniquely identified via these Identity be tied to a system entity uniquely identified via these Identity
Documents. An Identity Document - in general, a public-key Documents. An Identity Document - in general, a public-key
certificate - can be conveyed to other system entities in order to certificate - can be conveyed to other system entities in order to
prove or authenticate the identity of the owner of the Identity prove or authenticate the identity of the owner of the Identity
Document. Trust in the proof can be established by mutual trust of Document. Trust in the proof can be established by mutual trust of
skipping to change at page 4, line 28 skipping to change at page 4, line 30
The present version of this document is a strawman that attempts to The present version of this document is a strawman that attempts to
indicate the direction the work is intended to take. Not all indicate the direction the work is intended to take. Not all
inspirations this version takes from X.509 maybe need to be taken. inspirations this version takes from X.509 maybe need to be taken.
1.1. Terminology 1.1. Terminology
This document uses terminology from [RFC8392] and therefore also This document uses terminology from [RFC8392] and therefore also
[RFC7519], as well as from [RFC8152]. Specifically, we note: [RFC7519], as well as from [RFC8152]. Specifically, we note:
Assertion: Assertion: A statement made by an entity without accompanying
evidence of its validity [X.1252].
Claim: A piece of information asserted about a subject. A claim is 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 represented as a name/value pair consisting of a Claim Name and a
Claim Value. Claim Value.
Claims are grouped into claims sets (represented here by a CWT), 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 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 bit different from idiomatic English usage, where a claim would stand
on its own. on its own.
(Note that the current version of this draft is not very explicit (Note that the current version of this draft is not very explicit
about the relationship of identities and identifiers. To be done in about the relationship of identities and identifiers. To be done in
next version.) next version.)
1.2. Requirements Language
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.
2. Claims in a Concise Identity 2. Claims in a Concise Identity
A Concise Identity (CoID) is a CBOR Web Token [RFC8392] with certain 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 claims present. It can be signed in a number of ways, including a
COSE_Sign1 data object [RFC8152]. COSE_Sign1 data object [RFC8152].
2.1. iss: CWT issuer 2.1. iss: CWT issuer
Optional: identifies the principal that is the claimant for the 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 claims in the CoID ([RFC8392] Section 3.1.1, cf. Section 4.1.1 in
skipping to change at page 6, line 21 skipping to change at page 6, line 31
to be either coordinated between issuers or based on sufficient to be either coordinated between issuers or based on sufficient
randomness (e.g., 112 bits or more). randomness (e.g., 112 bits or more).
2.8. cnf: CWT proof-of-possession key claim 2.8. cnf: CWT proof-of-possession key claim
The "cnf" claim identifies the key that can be used by the subject The "cnf" claim identifies the key that can be used by the subject
for proof-of-possession and provides parameters to identify the CWT for proof-of-possession and provides parameters to identify the CWT
Confirmation Method ([I-D.ietf-ace-cwt-proof-of-possession] Confirmation Method ([I-D.ietf-ace-cwt-proof-of-possession]
Section 3.1). Section 3.1).
3. Signature Envelope 3. The Essential Qualities of the Subject Claim
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
4. Signature Envelope
The signature envelope [TBD: need not actually be envelope, may be The signature envelope [TBD: need not actually be envelope, may be
detached, too] carries additional information, e.g., the signature, detached, too] carries additional information, e.g., the signature,
as well as the identification of the signature algorithm employed as well as the identification of the signature algorithm employed
(COSE: alg). Additional information may pertain to the signature (as (COSE: alg). Additional information may pertain to the signature (as
opposed to the claims being signed), e.g., a key id (COSE: kid) may opposed to the claims being signed), e.g., a key id (COSE: kid) may
be given in the header of the signature. be given in the header of the signature.
4. Processing Rules 5. Processing Rules
(TBD: This should contain some discussion of the processing rules (TBD: This should contain some discussion of the processing rules
that apply for CoIDs. Some of this will just be pointers to that apply for CoIDs. Some of this will just be pointers to
[I-D.ietf-oauth-jwt-bcp].) [I-D.ietf-oauth-jwt-bcp].)
5. IANA Considerations 6. IANA Considerations
This document makes no requests of IANA This document makes no requests of IANA
6. Security Considerations 7. Security Considerations
7. References 8. References
7.1. Normative References 8.1. Normative References
[I-D.ietf-ace-cwt-proof-of-possession] [I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
possession-05 (work in progress), November 2018. possession-06 (work in progress), February 2019.
[I-D.ietf-oauth-jwt-bcp] [I-D.ietf-oauth-jwt-bcp]
Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", draft-ietf-oauth-jwt-bcp-04 (work in Current Practices", draft-ietf-oauth-jwt-bcp-06 (work in
progress), November 2018. progress), June 2019.
[I-D.ietf-rats-eat]
Mandyam, G., Lundblade, L., Ballesteros, M., and J.
O'Donoghue, "The Entity Attestation Token (EAT)", draft-
ietf-rats-eat-01 (work in progress), July 2019.
[I-D.tschofenig-rats-psa-token]
Tschofenig, H., Frost, S., Brossard, M., and A. Shaw,
"Arm's Platform Security Architecture (PSA) Attestation
Token", draft-tschofenig-rats-psa-token-01 (work in
progress), April 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet
Attribute Certificate Profile for Authorization",
RFC 5755, DOI 10.17487/RFC5755, January 2010,
<https://www.rfc-editor.org/info/rfc5755>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>. May 2018, <https://www.rfc-editor.org/info/rfc8392>.
7.2. Informative References [X.1252] "ITU-T X.1252 (04/2010)", n.d..
8.2. Informative References
[I-D.bormann-cbor-tags-oid]
Bormann, C. and S. Leonard, "Concise Binary Object
Representation (CBOR) Tags and Techniques for Object
Identifiers, UUIDs, Enumerations, Binary Entities, Regular
Expressions, and Sets", draft-bormann-cbor-tags-oid-06
(work in progress), March 2017.
[IEEE-802.1AR] [IEEE-802.1AR]
"IEEE Standard for Local and Metropolitan Area Networks - "ISO/IEC/IEEE International Standard for Information
Secure Device Identity", IEEE standard, technology -- Telecommunications and information exchange
DOI 10.1109/ieeestd.2018.8423794, n.d.. 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", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
skipping to change at page 14, line 4 skipping to change at page 16, line 4
notBefore = 5 notBefore = 5
serialNumber = 7 serialNumber = 7
version = 8 version = 8
subjectPublicKeyInfo = 9 subjectPublicKeyInfo = 9
signatureAlgorithm = 10 signatureAlgorithm = 10
authorityKeyidentifier = 11 authorityKeyidentifier = 11
subjectKeyIdentifier = 12 subjectKeyIdentifier = 12
keyUsage = 13 ; could move to COSE header? keyUsage = 13 ; could move to COSE header?
subjectAltName = 14 subjectAltName = 14
HardwareModuleName = 15 HardwareModuleName = 15
Appendix E. Attic Appendix E. Concise Attribute Documents
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.
Appendix F. Attic
Notes and previous content that will be pruned in next versions. Notes and previous content that will be pruned in next versions.
E.1. Examples of claims taken from IEEE 802.1AR identifiers F.1. Examples of claims taken from IEEE 802.1AR identifiers
This appendix briefly discusses common fields in a X.509 certificate This appendix briefly discusses common fields in a X.509 certificate
or an IEEE 802.1AR Secure Device Identifier and relates them to or an IEEE 802.1AR Secure Device Identifier and relates them to
claims in a CoID. claims in a CoID.
The original purpose of X.509 was only to sign the association The original purpose of X.509 was only to sign the association
between a name and a public key. In principle, if something else between a name and a public key. In principle, if something else
needs to be signed as well, CMS [RFC5652] is required. This needs to be signed as well, CMS [RFC5652] is required. This
principle has not been strictly upheld over time; this is principle has not been strictly upheld over time; this is
demonstrated by the growth of various extensions to X.509 demonstrated by the growth of various extensions to X.509
certificates that might or might not be interpreted to carry various certificates that might or might not be interpreted to carry various
additional claims. additional claims.
This document details only the claim sets for CBOR Web Tokens that This document details only the claim sets for CBOR Web Tokens that
are necessary for authentication. The plausible integration or are necessary for authentication. The plausible integration or
replacement of ASN.1 formats in enrollment procotols, [D]TLS replacement of ASN.1 formats in enrollment protocols, (D)TLS
handshakes and similar are not in scope of this document. handshakes and similar are not in scope of this document.
Subsections in this appendix are marked by the ASN.1 Object Subsections in this appendix are marked by the ASN.1 Object
Identifier (OID) typically used for the X.509 item. [TODO: Make this Identifier (OID) typically used for the X.509 item. [TODO: Make this
true; there are still some section numbers.] true; there are still some section numbers.]
E.1.1. 7.2.1 version F.1.1. 7.2.1 version
The version field is typically not employed usefully in an X.509 The version field is typically not employed usefully in an X.509
certificate, except possibly in legacy applications that accept certificate, except possibly in legacy applications that accept
original (pre-v3) X.509 certificates. original (pre-v3) X.509 certificates.
Generally, the point of versioning is to deliberately inhibit Generally, the point of versioning is to deliberately inhibit
interoperability (due to semantic meaning changes). CoIDs do not interoperability (due to semantic meaning changes). CoIDs do not
employ versioning. Where future work requires semantic changes, employ versioning. Where future work requires semantic changes,
these will be expressed by making alternate kinds of claims. these will be expressed by making alternate kinds of claims.
E.1.2. 7.2.2 serialNumber F.1.2. 7.2.2 serialNumber
Covered by cti claim. Covered by cti claim.
E.1.3. 7.2.3 signature F.1.3. 7.2.3 signature
The signature, as well as the identification of the signature The signature, as well as the identification of the signature
algorithm, are provided by the COSE container (e.g., COSE_Sign1) used algorithm, are provided by the COSE container (e.g., COSE_Sign1) used
to sign the CoID's CWT. to sign the CoID's CWT.
E.1.4. 7.2.4 issuer Name F.1.4. 7.2.4 issuer Name
Covered by iss claim. Covered by iss claim.
E.1.5. 7.2.5 authoritykeyidentifier F.1.5. 7.2.5 authoritykeyidentifier
Covered by COSE kid in signature, if needed. Covered by COSE kid in signature, if needed.
E.1.6. 7.2.7.1 notBefore F.1.6. 7.2.7.1 notBefore
Covered by nbf claim. Covered by nbf claim.
E.1.7. 7.2.7.2 notAfter F.1.7. 7.2.7.2 notAfter
Covered by exp claim. Covered by exp claim.
For Secured Device identifiers, this claim is typically left out. For Secured Device identifiers, this claim is typically left out.
o get a new one whenver you think you need it ("normal path") o get a new one whenver you think you need it ("normal path")
o nonced ocsp? might benefit from a more lightweight freshness o nonced ocsp? might benefit from a more lightweight freshness
verification of existing signed assertion - exploration required! verification of existing signed assertion - exploration required!
o (first party only verfiable freshness may be cheaper than third- o (first party only verfiable freshness may be cheaper than third-
party verifiable?) party verifiable?)
E.1.8. 7.2.8 subject F.1.8. 7.2.10 subjectPublicKeyInfo
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.
E.1.9. 7.2.10 subjectPublicKeyInfo
Covered by cnf claim. Covered by cnf claim.
E.1.10. 7.2.11 signatureAlgorithm F.1.9. 7.2.11 signatureAlgorithm
In COSE_Sign1 envelope. In COSE_Sign1 envelope.
E.1.11. 7.2.12 signatureValue F.1.10. 7.2.12 signatureValue
In COSE_Sign1 envelope. In COSE_Sign1 envelope.
E.2. Examples of claims taken from X.509 certificates F.2. Examples of claims taken from X.509 certificates
Most claims in X.509 certificates take the form of certificate Most claims in X.509 certificates take the form of certificate
extensions. This section reviews a few common (and maybe not so extensions. This section reviews a few common (and maybe not so
common) certificate extensions and assesses their usefulness in common) certificate extensions and assesses their usefulness in
signed claim sets. signed claim sets.
E.2.1. 2.5.29.35 - Authority Key Identifier F.2.1. 2.5.29.35 - Authority Key Identifier
Used in certificate chaining. Can be mapped to COSE "kid" of the Used in certificate chaining. Can be mapped to COSE "kid" of the
issuer. issuer.
E.2.2. 2.5.29.14 - Subject Key Identifier F.2.2. 2.5.29.14 - Subject Key Identifier
Used in certificate chaining. Can be mapped to COSE "kid" in the 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]). "cnf" (see Section 3.4 of [I-D.ietf-ace-cwt-proof-of-possession]).
E.2.3. 2.5.29.15 - Key Usage F.2.3. 2.5.29.15 - Key Usage
Usage information for a key claim that is included in the signed Usage information for a key claim that is included in the signed
claims. Can be mapped to COSE "key_ops" [TBD: Explain details]. claims. Can be mapped to COSE "key_ops" [TBD: Explain details].
E.2.4. 2.5.29.37 - Extended key usage F.2.4. 2.5.29.37 - Extended key usage
Can include additional usage information such as 1.3.6.1.5.5.7.3.1 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 for TLS server certificates or 1.3.6.1.5.5.7.3.2 for TLS client
certificates. certificates.
E.2.5. 1.3.6.1.5.5.7.1.1 - Authority Information Access F.2.5. 1.3.6.1.5.5.7.1.1 - Authority Information Access
More information about the signer. May include a pointer to signers 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 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. the form of a URI to their certificate.
E.2.6. 1.3.6.1.4.1.311.20.2 - Certificate Template Name Domain F.2.6. 1.3.6.1.4.1.311.20.2 - Certificate Template Name Domain
Controller (Microsoft) Controller (Microsoft)
This is an example for many ill-defined extensions that are on some This is an example for many ill-defined extensions that are on some
arcs of the OID space somewhere. arcs of the OID space somewhere.
E.g., the UCS-2 string (ASN.1 BMPString) "IPSECIntermediateOffline" E.g., the UCS-2 string (ASN.1 BMPString) "IPSECIntermediateOffline"
Appendix F. Graveyard Appendix G. Graveyard
Items and Content that was already discarded. Items and Content that was already discarded.
F.1. 7.2.9 subjectAltName G.1. 7.2.9 subjectAltName
(See "sub"). (See "sub").
F.2. 7.2.13 extensions G.2. 7.2.13 extensions
Extensions are handled by adding CWT claims to the CWT. Extensions are handled by adding CWT claims to the CWT.
F.3. 2.5.29.31 - CRL Distribution Points G.3. 2.5.29.31 - CRL Distribution Points
Usually URIs of places where a CRL germane to the certificate can be Usually URIs of places where a CRL germane to the certificate can be
obtained. Other forms of validating claim sets may be more obtained. Other forms of validating claim sets may be more
appropriate than CRLs for the applications envisaged here. appropriate than CRLs for the applications envisaged here.
(Might be replaced by a more general freshness verification approach (Might be replaced by a more general freshness verification approach
later. For example one could define a generic "is this valid" later. For example one could define a generic "is this valid"
request to an authority.) request to an authority.)
F.4. 2.5.29.17 - Subject Alternative Name G.4. 2.5.29.17 - Subject Alternative Name
Additional names for the Subject. Additional names for the Subject.
These may be an "OtherName", i.e. a mistery blob "defined by" an 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 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). such as URIs (which may, then, turn out not to be really URIs).
Naming subjects obviously is a major issue that needs attention. Naming subjects obviously is a major issue that needs attention.
F.5. 2.5.29.19 - Basic Constraints G.5. 2.5.29.19 - Basic Constraints
Can identify the key claim as that for a CA, and can limit the length 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. of a certificate path. Empty in all the examples analyzed.
Any application space can define new fields / claims as appropriate Any application space can define new fields / claims as appropriate
and use them. There is no need for the underlying structure to and use them. There is no need for the underlying structure to
define an additional extension method for this. Instead, they can define an additional extension method for this. Instead, they can
use the registry as defined in Section 9.1 of [RFC8392].> use the registry as defined in Section 9.1 of [RFC8392].>
Acknowledgements Acknowledgements
 End of changes. 49 change blocks. 
102 lines changed or deleted 226 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/