idnits 2.17.1 draft-schaad-cose-x509-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 22, 2016) is 2710 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7049' is defined on line 227, but no explicit reference was found in the text == Unused Reference: 'I-D.greevenbosch-appsawg-cbor-cddl' is defined on line 233, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-cose-msg-23 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-09 == Outdated reference: A later version (-12) exists of draft-ietf-lamps-rfc5751-bis-02 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schaad 3 Internet-Draft August Cellars 4 Intended status: Informational November 22, 2016 5 Expires: May 26, 2017 7 CBOR Encoded Message Syntax (COSE): Headers for carrying and referencing 8 X.509 certificates 9 draft-schaad-cose-x509-00 11 Abstract 13 This document defines the headers and usage for referring to and 14 transporting X.509 certificates in the CBOR Encoded Message (COSE) 15 Syntax. 17 Contributing to this document 19 The source for this draft is being maintained in GitHub. Suggested 20 changes should be submitted as pull requests at . Instructions are on that page as well. Editorial 22 changes can be managed in GitHub, but any substantial issues need to 23 be discussed on the COSE mailing list. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 26, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 2 61 2. X.509 COSE Headers . . . . . . . . . . . . . . . . . . . . . 3 62 3. Hash Algorithm Identifiers . . . . . . . . . . . . . . . . . 5 63 3.1. SHA-2 256-bit Hash . . . . . . . . . . . . . . . . . . . 5 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. COSE Header Parameter Registry . . . . . . . . . . . . . 5 66 4.2. COSE Algorithm Registry . . . . . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 70 6.2. Informative References . . . . . . . . . . . . . . . . . 5 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 In the process of writing RFCXXXX [I-D.ietf-cose-msg] discussions 76 where held on the question of X.509 certificates [RFC5280] and if 77 there were needed. At the time there were no use cases presented 78 that appeared to hve a sufficient set of support to include these 79 headers. Since that time a number of cases where X.509 certificate 80 support is necessary have been defined. This document provides a set 81 of headers that will allow applications to transport and refer to 82 X.509 certificates in a consistent manner. 84 1.1. Requirements Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 88 "OPTIONAL" in this document are to be interpreted as described in 89 [RFC2119]. 91 When the words appear in lower case, their natural language meaning 92 is used. 94 2. X.509 COSE Headers 96 The use of X.509 certificates allows for an existing trust 97 infrastructure to be used with COSE. 99 When the header parameters defined in this section are placed in a 100 COSE_Signature or COSE_Sign0 object, they identify the key that was 101 used for generating signature. 103 When the header parameters defined in this section are placed in a 104 COSE_recipient structure, they identify the key that was used by the 105 sender when used with static-static key agreement algorithms. 107 Certificates obtained from any of these methods MUST still be 108 validated according to the PKIX rules in [RFC5280]. This includes 109 matching against the trust anchors configured for the application. 110 This applies certificates of a chain length of one as well as longer 111 chains. 113 The header parameters defined in this document are: 115 x5c: This header parameter allows for a single or a bag of X.509 116 certificates to be carried in the message. 118 * If a single certificate is conveyed, it is placed in a CBOR 119 bstr. 121 * If multiple certificates are conveyed, a CBOR array is used 122 where: 124 + The first element is a boolean value set to true if the 125 certificates are arranged such that a each certificate is 126 issued by the next certficate. In otherwords a chain of 127 certificates is presented. The chain of certificates does 128 not need to be complete and normally SHOULD omit the trust 129 anchor certificate. If the first element is set to false, 130 then the certificates are not ordered and can include 131 certificates that are not needed to create a certificate 132 chain from the end-entity certificate. This allows for a 133 certificate with a key exchange algorithm to be carried in a 134 signed message. 136 + The second element is the end-entity certificate. This is 137 true regardless of wheither the certificates are ordered or 138 not. This permits the application to identify which 139 certificate is the end-entity certificate without a second 140 header attribute. 142 + Elements three through the last are certificates. 144 x5t: This header parameter provides the ability to identify an X.509 145 certificate by a hash value. The parameter is an array of two 146 elements. The first element is an algorithm identifier which is a 147 signed integer, an unsigned integer or a string containing the 148 hash algorithm identifier. The second element is a binary string 149 containing the hash value. 150 For interoperability, applications which use this header parameter 151 MUST support the hash algorithm 'sha256', but can use other hash 152 algorithms. 154 x5u: This header parameter provides the ability to identify an X.509 155 certificate by a URL. The referenced resource can be any of the 156 following media types: 158 * application/pkix-cert [RFC2585] 160 * application/pkcs7-mime; smime-type="certs-only" 161 [I-D.ietf-lamps-rfc5751-bis] 163 * Should we support a PEM type? I cannot find a registered media 164 type for one 165 The URL provided MUST provide integrity protection. For example, 166 an HTTP GET request to retrieve a certificate MUST use TLS 167 [RFC5246]. If the certificate does not chain to an existing trust 168 anchor, the identity of the server MUST be configured as trusted 169 to provide new trust anchors. This will normally be the situation 170 when self-signed certificates are used. 172 +------+-------+---------------+------------------------------------+ 173 | name | label | value type | description | 174 +------+-------+---------------+------------------------------------+ 175 | x5t | TBD1 | COSE_CertHash | Hash of an X.509 certificate | 176 | | | | | 177 | x5u | TBD2 | uri | URL pointing to an X.509 | 178 | | | | certificate | 179 | | | | | 180 | x5c | TBD3 | COSE_X509 | Collection of X.509 certificates | 181 +------+-------+---------------+------------------------------------+ 183 Table 1: X.509 COSE Headers 185 COSE_X509 = bstr / [ ordered: bool, certs: +bstr ] 186 COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ] 188 3. Hash Algorithm Identifiers 190 3.1. SHA-2 256-bit Hash 192 Define an algorithm identifier for SHA-256. 194 4. IANA Considerations 196 4.1. COSE Header Parameter Registry 198 Put in the registrations. 200 4.2. COSE Algorithm Registry 202 Put in the registrations. 204 5. Security Considerations 206 There are security considerations: 208 6. References 210 6.1. Normative References 212 [I-D.ietf-cose-msg] 213 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 214 draft-ietf-cose-msg-23 (work in progress), October 2016. 216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 217 Requirement Levels", BCP 14, RFC 2119, 218 DOI 10.17487/RFC2119, March 1997, 219 . 221 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 222 Housley, R., and W. Polk, "Internet X.509 Public Key 223 Infrastructure Certificate and Certificate Revocation List 224 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 225 . 227 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 228 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 229 October 2013, . 231 6.2. Informative References 233 [I-D.greevenbosch-appsawg-cbor-cddl] 234 Vigano, C. and H. Birkholz, "CBOR data definition language 235 (CDDL): a notational convention to express CBOR data 236 structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work 237 in progress), September 2016. 239 [I-D.ietf-lamps-rfc5751-bis] 240 Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 241 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 242 Message Specification", draft-ietf-lamps-rfc5751-bis-02 243 (work in progress), October 2016. 245 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 246 Infrastructure Operational Protocols: FTP and HTTP", 247 RFC 2585, DOI 10.17487/RFC2585, May 1999, 248 . 250 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 251 (TLS) Protocol Version 1.2", RFC 5246, 252 DOI 10.17487/RFC5246, August 2008, 253 . 255 Author's Address 257 Jim Schaad 258 August Cellars 260 Email: ietf@augustcellars.com