idnits 2.17.1 draft-ietf-tls-cached-info-23.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 11, 2016) is 2907 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 379, but not defined -- Looks like a reference, but probably isn't: '0' on line 608 -- Looks like a reference, but probably isn't: '3' on line 588 -- Looks like a reference, but probably isn't: '1' on line 611 -- Looks like a reference, but probably isn't: '4' on line 612 -- Looks like a reference, but probably isn't: '2' on line 636 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 6234 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS S. Santesson 3 Internet-Draft 3xA Security AB 4 Intended status: Standards Track H. Tschofenig 5 Expires: November 12, 2016 ARM Ltd. 6 May 11, 2016 8 Transport Layer Security (TLS) Cached Information Extension 9 draft-ietf-tls-cached-info-23.txt 11 Abstract 13 Transport Layer Security (TLS) handshakes often include fairly static 14 information, such as the server certificate and a list of trusted 15 certification authorities (CAs). This information can be of 16 considerable size, particularly if the server certificate is bundled 17 with a complete certificate chain (i.e., the certificates of 18 intermediate CAs up to the root CA). 20 This document defines an extension that allows a TLS client to inform 21 a server of cached information, allowing the server to omit already 22 available information. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 12, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Cached Information Extension . . . . . . . . . . . . . . . . 3 61 4. Exchange Specification . . . . . . . . . . . . . . . . . . . 5 62 4.1. Server Certificate Message . . . . . . . . . . . . . . . 5 63 4.2. CertificateRequest Message . . . . . . . . . . . . . . . 6 64 5. Fingerprint Calculation . . . . . . . . . . . . . . . . . . . 7 65 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 8.1. New Entry to the TLS ExtensionType Registry . . . . . . . 10 69 8.2. New Registry for CachedInformationType . . . . . . . . . 10 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 10.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 77 1. Introduction 79 Reducing the amount of information exchanged during a Transport Layer 80 Security handshake to a minimum helps to improve performance in 81 environments where devices are connected to a network with a low 82 bandwidth, and lossy radio technology. With Internet of Things such 83 environments exist, for example, when devices use IEEE 802.15.4 or 84 Bluetooth Smart. For more information about the challenges with 85 smart object deployments please see [RFC6574]. 87 This specification defines a TLS extension that allows a client and a 88 server to exclude transmission information cached in an earlier TLS 89 handshake. 91 A typical example exchange may therefore look as follows. First, the 92 client and the server executes the full TLS handshake. The client 93 then caches the certificate provided by the server. When the TLS 94 client connects to the TLS server some time in the future, without 95 using session resumption, it then attaches the cached_info extension 96 defined in this document to the client hello message to indicate that 97 it had cached the certificate, and it provides the fingerprint of it. 98 If the server's certificate has not changed then the TLS server does 99 not need to send its certificate and the corresponding certificate 100 chain again. In case information has changed, which can be seen from 101 the fingerprint provided by the client, the certificate payload is 102 transmitted to the client to allow the client to update the cache. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 This document refers to the TLS protocol but the description is 111 equally applicable to DTLS as well. 113 3. Cached Information Extension 115 This document defines a new extension type (cached_info(TBD)), which 116 is used in client hello and server hello messages. The extension 117 type is specified as follows. 119 enum { 120 cached_info(TBD), (65535) 121 } ExtensionType; 123 The extension_data field of this extension, when included in the 124 client hello, MUST contain the CachedInformation structure. The 125 client MAY send multiple CachedObjects of the same 126 CachedInformationType. This may, for example, be the case when the 127 client has cached multiple certificates from a server. 129 enum { 130 cert(1), cert_req(2) (255) 131 } CachedInformationType; 133 struct { 134 select (type) { 135 case client: 136 CachedInformationType type; 137 opaque hash_value<1..255>; 138 case server: 139 CachedInformationType type; 140 } body; 141 } CachedObject; 143 struct { 144 CachedObject cached_info<1..2^16-1>; 145 } CachedInformation; 147 This document defines the following two types: 149 'cert' Type for not sending the complete Server Certificate Message: 151 With the type field set to 'cert', the client MUST include the 152 fingerprint of the Certificate message in the hash_value field. 153 For this type the fingerprint MUST be calculated using the 154 procedure described in Section 5 with the Certificate message as 155 input data. 157 'cert_req' Type for not sending the complete CertificateRequest 158 Message: 160 With the type set to 'cert_req', the client MUST include the 161 fingerprint of the CertificateRequest message in the hash_value 162 field. For this type the fingerprint MUST be calculated using the 163 procedure described in Section 5 with the CertificateRequest 164 message as input data. 166 New cached info types can be added following the policy described in 167 the IANA considerations section, see Section 8. New message digest 168 algorithms for use with these types can also be added by registering 169 a new type that makes use of the updated message digest algorithm. 170 For practical reasons we recommend to re-use hash algorithms already 171 available with TLS ciphersuites to avoid additional code and to keep 172 the collision probably low new hash algorithms MUST NOT have a 173 collision resistance worse than SHA-256. 175 4. Exchange Specification 177 Clients supporting this extension MAY include the "cached_info" 178 extension in the (extended) client hello. If the client includes the 179 extension then it MUST contain one or more CachedObject attributes. 181 A server supporting this extension MAY include the "cached_info" 182 extension in the (extended) server hello. By returning the 183 "cached_info" extension the server indicates that it supports the 184 cached info types. For each indicated cached info type the server 185 MUST alter the transmission of respective payloads, according to the 186 rules outlined with each type. If the server includes the extension 187 it MUST only include CachedObjects of a type also supported by the 188 client (as expressed in the client hello). For example, if a client 189 indicates support for 'cert' and 'cert_req' then the server cannot 190 respond with a "cached_info" attribute containing support for ('foo- 191 bar'). 193 Since the client includes a fingerprint of information it cached (for 194 each indicated type) the server is able to determine whether cached 195 information is stale. If the server supports this specification and 196 notices a mismatch between the data cached by the client and its own 197 information then the server MUST include the information in full and 198 MUST NOT list the respective type in the "cached_info" extension. 200 Note: If a server is part of a hosting environment then the client 201 may have cached multiple data items for a single server. To allow 202 the client to select the appropriate information from the cache it is 203 RECOMMENDED that the client utilizes the Server Name Indication 204 extension [RFC6066]. 206 Following a successful exchange of the "cached_info" extension in the 207 client and server hello, the server alters sending the corresponding 208 handshake message. How information is altered from the handshake 209 messages is defined in Section 4.1, and in Section 4.2 for the types 210 defined in this specification. 212 Appendix A shows an example hash calculation and Section 6 shows an 213 example protocol exchange. 215 4.1. Server Certificate Message 217 When a ClientHello message contains the "cached_info" extension with 218 a type set to 'cert' then the server MAY send the Certificate message 219 shown in Figure 1 under the following conditions: 221 o The server software implements the "cached_info" extension defined 222 in this specification. 224 o The 'cert' cached info extension is enabled (for example, a policy 225 allows the use of this extension). 227 o The server compared the value in the hash_value field of the 228 client-provided "cached_info" extension with the fingerprint of 229 the Certificate message it normally sends to clients. This check 230 ensures that the information cached by the client is current. The 231 procedure for calculating the fingerprint is described in 232 Section 5. 234 The original Certificate handshake message syntax is defined in 235 [RFC5246] and has been extended with [RFC7250]. RFC 7250 allows the 236 certificate payload to contain only the SubjectPublicKeyInfo instead 237 of the full information typically found in a certificate. Hence, 238 when this specification is used in combination with [RFC7250] and the 239 negotiated certificate type is a raw public key then the TLS server 240 omits sending a Certificate payload that contains an ASN.1 241 Certificate structure with the included SubjectPublicKeyInfo rather 242 than the full certificate chain. As such, this extension is 243 compatible with the raw public key extension defined in RFC 7250. 244 Note: We assume that the server implementation is able to select the 245 appropriate certificate or SubjectPublicKeyInfo from the received 246 hash value. If the SNI extension is used by the client then the 247 server has additional information to guide the selection of the 248 appropriate cached info. 250 When the cached info specification is used then a modified version of 251 the Certificate message is exchanged. The modified structure is 252 shown in Figure 1. 254 struct { 255 opaque hash_value<1..255>; 256 } Certificate; 258 Figure 1: Cached Info Certificate Message. 260 4.2. CertificateRequest Message 262 When a fingerprint for an object of type 'cert_req' is provided in 263 the client hello, the server MAY send the CertificateRequest message 264 shown in Figure 2 message under the following conditions: 266 o The server software implements the "cached_info" extension defined 267 in this specification. 269 o The 'cert_req' cached info extension is enabled (for example, a 270 policy allows the use of this extension). 272 o The server compared the value in the hash_value field of the 273 client-provided "cached_info" extension with the fingerprint of 274 the CertificateRequest message it normally sends to clients. This 275 check ensures that the information cached by the client is 276 current. The procedure for calculating the fingerprint is 277 described in Section 5. 279 o The server wants to request a certificate from the client. 281 The original CertificateRequest handshake message syntax is defined 282 in [RFC5246]. The modified structure of the CertificateRequest 283 message is shown in Figure 2. 285 struct { 286 opaque hash_value<1..255>; 287 } CertificateRequest; 289 Figure 2: Cached Info CertificateRequest Message. 291 The CertificateRequest payload is the input parameter to the 292 fingerprint calculation described in Section 5. 294 5. Fingerprint Calculation 296 The fingerprint for the two cached info objects defined in this 297 document MUST be computed as follows: 299 1. Compute the SHA-256 [RFC6234] hash of the input data. The input 300 data depends on the cached info type. This document defines two 301 cached info types, described in Section 4.1 and in Section 4.2. 302 Note that the computed hash only covers the input data structure 303 (and not any type and length information of the record layer). 304 Appendix A shows an example. 306 2. Use the output of the SHA-256 hash. 308 The purpose of the fingerprint provided by the client is to help the 309 server select the correct information. For example, in case of the 310 certificate message the fingerprint identifies the server certificate 311 (and the corresponding private key) for use for with the rest of the 312 handshake. Servers may have more than one certificate and therefore 313 a hash needs to be long enough to keep the probably of hash 314 collisions low. On the other hand, the cached info design aims to 315 reduce the amount of data being exchanged. The security of the 316 handshake depends on the private key and not on the size of the 317 fingerprint. Hence, the fingerprint is a way to prevent the server 318 from accidentally selecting the wrong information. If an attacker 319 injects an incorrect fingerprint then two outcomes are possible: (1) 320 The fingerprint does not relate to any cached state and the server 321 has to fall back to a full exchange. (2) If the attacker manages to 322 inject a fingerprint that refers to data the client has not cached 323 then the exchange will fail later when the client continues with the 324 handshake and aims to verify the digital signature. The signature 325 verification will fail since the public key cached by the client will 326 not correspond to the private key that was used by server to sign the 327 message. 329 6. Example 331 In the regular, full TLS handshake exchange, shown in Figure 3, the 332 TLS server provides its certificate in the Certificate payload to the 333 client, see step (1). This allows the client to store the 334 certificate for future use. After some time the TLS client again 335 interacts with the same TLS server and makes use of the TLS cached 336 info extension, as shown in Figure 4. The TLS client indicates 337 support for this specification via the "cached_info" extension, see 338 step (2), and indicates that it has stored the certificate from the 339 earlier exchange (by indicating the 'cert' type). With step (3) the 340 TLS server acknowledges the supports of the 'cert' type and by 341 including the value in the server hello informs the client that the 342 content of the certificate payload contains the fingerprint of the 343 certificate instead of the RFC 5246-defined payload of the 344 certificate message in step (4). 346 ClientHello -> 347 <- ServerHello 348 Certificate* // (1) 349 ServerKeyExchange* 350 CertificateRequest* 351 ServerHelloDone 353 Certificate* 354 ClientKeyExchange 355 CertificateVerify* 356 [ChangeCipherSpec] 357 Finished -> 359 <- [ChangeCipherSpec] 360 Finished 362 Application Data <-------> Application Data 364 Figure 3: Example Message Exchange: Initial (full) Exchange. 366 ClientHello 367 cached_info=(cert) -> // (2) 368 <- ServerHello 369 cached_info=(cert) (3) 370 Certificate (4) 371 ServerKeyExchange* 372 ServerHelloDone 374 ClientKeyExchange 375 CertificateVerify* 376 [ChangeCipherSpec] 377 Finished -> 379 <- [ChangeCipherSpec] 380 Finished 382 Application Data <-------> Application Data 384 Figure 4: Example Message Exchange: TLS Cached Extension Usage. 386 7. Security Considerations 388 This specification defines a mechanism to reference stored state 389 using a fingerprint. Sending a fingerprint of cached information in 390 an unencrypted handshake, as the client and server hello is, may 391 allow an attacker or observer to correlate independent TLS exchanges. 392 While some information elements used in this specification, such as 393 server certificates, are public objects and usually do not contain 394 sensitive information, other not yet defined types may. Those who 395 implement and deploy this specification should therefore make an 396 informed decision whether the cached information is inline with their 397 security and privacy goals. In case of concerns, it is advised to 398 avoid sending the fingerprint of the data objects in clear. 400 The use of the cached info extension allows the server to send 401 significantly smaller TLS messages. Consequently, these omitted 402 parts of the messages are not included in the transcript of the 403 handshake in the TLS Finish message. However, since the client and 404 the server communicate the hash values of the cached data in the 405 initial handshake messages the fingerprints are included in the TLS 406 Finish message. 408 Clients MUST ensure that they only cache information from legitimate 409 sources. For example, when the client populates the cache from a TLS 410 exchange then it must only cache information after the successful 411 completion of a TLS exchange to ensure that an attacker does not 412 inject incorrect information into the cache. Failure to do so allows 413 for man-in-the-middle attacks. 415 Security considerations for the fingerprint calculation are discussed 416 in Section 5. 418 8. IANA Considerations 420 8.1. New Entry to the TLS ExtensionType Registry 422 IANA is requested to add an entry to the existing TLS ExtensionType 423 registry, defined in [RFC5246], for cached_info(TBD) defined in this 424 document. 426 8.2. New Registry for CachedInformationType 428 IANA is requested to establish a registry for TLS 429 CachedInformationType values. The first entries in the registry are 431 o cert(1) 433 o cert_req(2) 435 The policy for adding new values to this registry, following the 436 terminology defined in [RFC5226], is as follows: 438 o 0-63 (decimal): Standards Action 440 o 64-223 (decimal): Specification Required 442 o 224-255 (decimal): reserved for Private Use 444 9. Acknowledgments 446 We would like to thank the following persons for your detailed 447 document reviews: 449 o Paul Wouters and Nikos Mavrogiannopoulos (December 2011) 451 o Rob Stradling (February 2012) 453 o Ondrej Mikle (March 2012) 455 o Ilari Liusvaara, Adam Langley, and Eric Rescorla (July 2014) 457 o Sean Turner (August 2014) 459 o Martin Thomson (August 2015) 461 o Jouni Korhonen (November 2015) 462 o Matt Miller (December 2015) 464 We would also to thank Martin Thomson, Karthikeyan Bhargavan, Sankalp 465 Bagaria and Eric Rescorla for their feedback regarding the 466 fingerprint calculation. 468 Finally, we would like to thank the TLS working group chairs, Sean 469 Turner and Joe Salowey, as well as the responsible security area 470 director, Stephen Farrell, for their support and their reviews. 472 10. References 474 10.1. Normative References 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 478 RFC2119, March 1997, 479 . 481 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 482 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 483 RFC5246, August 2008, 484 . 486 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 487 Extensions: Extension Definitions", RFC 6066, DOI 488 10.17487/RFC6066, January 2011, 489 . 491 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 492 (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 493 10.17487/RFC6234, May 2011, 494 . 496 10.2. Informative References 498 [ASN.1-Dump] 499 Gutmann, P., "ASN.1 Object Dump Program", February 2013, 500 . 502 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 503 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 504 DOI 10.17487/RFC5226, May 2008, 505 . 507 [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object 508 Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, 509 . 511 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 512 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 513 Transport Layer Security (TLS) and Datagram Transport 514 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 515 June 2014, . 517 Appendix A. Example 519 Consider a certificate containing an NIST P256 elliptic curve public 520 key displayed using Peter Gutmann's ASN.1 decoder [ASN.1-Dump] in 521 Figure 5. 523 0 556: SEQUENCE { 524 4 434: SEQUENCE { 525 8 3: [0] { 526 10 1: INTEGER 2 527 : } 528 13 1: INTEGER 13 529 16 10: SEQUENCE { 530 18 8: OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2) 531 : } 532 28 62: SEQUENCE { 533 30 11: SET { 534 32 9: SEQUENCE { 535 34 3: OBJECT IDENTIFIER countryName (2 5 4 6) 536 39 2: PrintableString 'NL' 537 : } 538 : } 539 43 17: SET { 540 45 15: SEQUENCE { 541 47 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 542 52 8: PrintableString 'PolarSSL' 543 : } 544 : } 545 62 28: SET { 546 64 26: SEQUENCE { 547 66 3: OBJECT IDENTIFIER commonName (2 5 4 3) 548 71 19: PrintableString 'Polarssl Test EC CA' 549 : } 550 : } 551 : } 552 92 30: SEQUENCE { 553 94 13: UTCTime 24/09/2013 15:52:04 GMT 554 109 13: UTCTime 22/09/2023 15:52:04 GMT 555 : } 556 124 65: SEQUENCE { 557 126 11: SET { 558 128 9: SEQUENCE { 559 130 3: OBJECT IDENTIFIER countryName (2 5 4 6) 560 135 2: PrintableString 'NL' 561 : } 562 : } 563 139 17: SET { 564 141 15: SEQUENCE { 565 143 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 566 148 8: PrintableString 'PolarSSL' 567 : } 568 : } 569 158 31: SET { 570 160 29: SEQUENCE { 571 162 3: OBJECT IDENTIFIER commonName (2 5 4 3) 572 167 22: PrintableString 'PolarSSL Test Client 2' 573 : } 574 : } 575 : } 576 191 89: SEQUENCE { 577 193 19: SEQUENCE { 578 195 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 579 204 8: OBJECT IDENTIFIER prime256v1 (1 2 840 10045 3 1 7) 580 : } 581 214 66: BIT STRING 582 : 04 57 E5 AE B1 73 DF D3 AC BB 93 B8 81 FF 12 AE 583 : EE E6 53 AC CE 55 53 F6 34 0E CC 2E E3 63 25 0B 584 : DF 98 E2 F3 5C 60 36 96 C0 D5 18 14 70 E5 7F 9F 585 : D5 4B 45 18 E5 B0 6C D5 5C F8 96 8F 87 70 A3 E4 586 : C7 587 : } 588 282 157: [3] { 589 285 154: SEQUENCE { 590 288 9: SEQUENCE { 591 290 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 592 295 2: OCTET STRING, encapsulates { 593 297 0: SEQUENCE {} 594 : } 595 : } 596 299 29: SEQUENCE { 597 301 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 598 306 22: OCTET STRING, encapsulates { 599 308 20: OCTET STRING 600 : 7A 00 5F 86 64 FC E0 5D E5 11 10 3B B2 E6 3B C4 601 : 26 3F CF E2 602 : } 603 : } 604 330 110: SEQUENCE { 605 332 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35) 606 337 103: OCTET STRING, encapsulates { 607 339 101: SEQUENCE { 608 341 20: [0] 609 : 9D 6D 20 24 49 01 3F 2B CB 78 B5 19 BC 7E 24 610 : C9 DB FB 36 7C 611 363 66: [1] { 612 365 64: [4] { 613 367 62: SEQUENCE { 614 369 11: SET { 615 371 9: SEQUENCE { 616 373 3: OBJECT IDENTIFIER countryName (2 5 4 6) 617 378 2: PrintableString 'NL' 618 : } 619 : } 620 382 17: SET { 621 384 15: SEQUENCE { 622 386 3: OBJECT IDENTIFIER organizationName 623 : (2 5 4 10) 624 391 8: PrintableString 'PolarSSL' 625 : } 626 : } 627 401 28: SET { 628 403 26: SEQUENCE { 629 405 3: OBJECT IDENTIFIER commonName (2 5 4 3) 630 410 19: PrintableString 'Polarssl Test EC CA' 631 : } 632 : } 633 : } 634 : } 635 : } 636 431 9: [2] 00 C1 43 E2 7E 62 43 CC E8 637 : } 638 : } 639 : } 640 : } 641 : } 642 : } 643 442 10: SEQUENCE { 644 444 8: OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2) 645 : } 646 454 104: BIT STRING, encapsulates { 647 457 101: SEQUENCE { 648 459 48: INTEGER 649 : 4A 65 0D 7B 20 83 A2 99 B9 A8 0F FC 8D EE 8F 3D 650 : BB 70 4C 96 03 AC 8E 78 70 DD F2 0E A0 B2 16 CB 651 : 65 8E 1A C9 3F 2C 61 7E F8 3C EF AD 1C EE 36 20 652 509 49: INTEGER 653 : 00 9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA 654 : 54 2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC 655 : 42 49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57 656 : 45 657 : } 658 : } 659 : } 661 Figure 5: ASN.1-based Certificate: Example. 663 To include the certificate shown in Figure 5 in a TLS/DTLS 664 Certificate message it is prepended with a message header. This 665 Certificate message header in our example is 0b 00 02 36 00 02 33 00 666 02 00 02 30, which indicates: 668 Message Type: 0b -- 1 byte type field indicating a Certificate 669 message 671 Length: 00 02 36 -- 3 byte length field indicating a 566 bytes 672 payload 674 Certificates Length: 00 02 33 -- 3 byte length field indicating 563 675 bytes for the entire certificates_list structure, which may 676 contain multiple certificates. In our example only one 677 certificate is included. 679 Certificate Length: 00 02 30 -- 3 byte length field indicating 560 680 bytes of the actual certificate following immediately afterwards. 681 In our example, this is the certificate content with 30 82 02 .... 682 9E 57 45 shown in Figure 6. 684 The hex encoding of the ASN.1 encoded certificate payload shown in 685 Figure 5 leads to the following encoding. 687 30 82 02 2C 30 82 01 B2 A0 03 02 01 02 02 01 0D 688 30 0A 06 08 2A 86 48 CE 3D 04 03 02 30 3E 31 0B 689 30 09 06 03 55 04 06 13 02 4E 4C 31 11 30 0F 06 690 03 55 04 0A 13 08 50 6F 6C 61 72 53 53 4C 31 1C 691 30 1A 06 03 55 04 03 13 13 50 6F 6C 61 72 73 73 692 6C 20 54 65 73 74 20 45 43 20 43 41 30 1E 17 0D 693 31 33 30 39 32 34 31 35 35 32 30 34 5A 17 0D 32 694 33 30 39 32 32 31 35 35 32 30 34 5A 30 41 31 0B 695 30 09 06 03 55 04 06 13 02 4E 4C 31 11 30 0F 06 696 03 55 04 0A 13 08 50 6F 6C 61 72 53 53 4C 31 1F 697 30 1D 06 03 55 04 03 13 16 50 6F 6C 61 72 53 53 698 4C 20 54 65 73 74 20 43 6C 69 65 6E 74 20 32 30 699 59 30 13 06 07 2A 86 48 CE 3D 02 01 06 08 2A 86 700 48 CE 3D 03 01 07 03 42 00 04 57 E5 AE B1 73 DF 701 D3 AC BB 93 B8 81 FF 12 AE EE E6 53 AC CE 55 53 702 F6 34 0E CC 2E E3 63 25 0B DF 98 E2 F3 5C 60 36 703 96 C0 D5 18 14 70 E5 7F 9F D5 4B 45 18 E5 B0 6C 704 D5 5C F8 96 8F 87 70 A3 E4 C7 A3 81 9D 30 81 9A 705 30 09 06 03 55 1D 13 04 02 30 00 30 1D 06 03 55 706 1D 0E 04 16 04 14 7A 00 5F 86 64 FC E0 5D E5 11 707 10 3B B2 E6 3B C4 26 3F CF E2 30 6E 06 03 55 1D 708 23 04 67 30 65 80 14 9D 6D 20 24 49 01 3F 2B CB 709 78 B5 19 BC 7E 24 C9 DB FB 36 7C A1 42 A4 40 30 710 3E 31 0B 30 09 06 03 55 04 06 13 02 4E 4C 31 11 711 30 0F 06 03 55 04 0A 13 08 50 6F 6C 61 72 53 53 712 4C 31 1C 30 1A 06 03 55 04 03 13 13 50 6F 6C 61 713 72 73 73 6C 20 54 65 73 74 20 45 43 20 43 41 82 714 09 00 C1 43 E2 7E 62 43 CC E8 30 0A 06 08 2A 86 715 48 CE 3D 04 03 02 03 68 00 30 65 02 30 4A 65 0D 716 7B 20 83 A2 99 B9 A8 0F FC 8D EE 8F 3D BB 70 4C 717 96 03 AC 8E 78 70 DD F2 0E A0 B2 16 CB 65 8E 1A 718 C9 3F 2C 61 7E F8 3C EF AD 1C EE 36 20 02 31 00 719 9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA 54 720 2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC 42 721 49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57 45 723 Figure 6: Hex Encoding of the Example Certificate. 725 Applying the SHA-256 hash function to the Certificate message, which 726 is starts with 0b 00 02 and ends with 9E 57 45, produces 727 0x086eefb4859adfe977defac494fff6b73033b4ce1f86b8f2a9fc0c6bf98605af. 729 Authors' Addresses 730 Stefan Santesson 731 3xA Security AB 732 Scheelev. 17 733 Lund 223 70 734 Sweden 736 Email: sts@aaa-sec.com 738 Hannes Tschofenig 739 ARM Ltd. 740 Hall in Tirol 6060 741 Austria 743 Email: Hannes.tschofenig@gmx.net 744 URI: http://www.tschofenig.priv.at