idnits 2.17.1 draft-ietf-tls-cached-info-21.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 (December 21, 2015) is 3039 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 391, but not defined -- Looks like a reference, but probably isn't: '0' on line 621 -- Looks like a reference, but probably isn't: '3' on line 601 -- Looks like a reference, but probably isn't: '1' on line 624 -- Looks like a reference, but probably isn't: '4' on line 625 -- Looks like a reference, but probably isn't: '2' on line 649 ** 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: June 23, 2016 ARM Ltd. 6 December 21, 2015 8 Transport Layer Security (TLS) Cached Information Extension 9 draft-ietf-tls-cached-info-21.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 June 23, 2016. 41 Copyright Notice 43 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . 11 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 10.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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^8-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 There are no specific requirements for the use of specific hash 171 algorithms but for practical reason it is useful to re-use algorithms 172 already available with TLS ciphersuites to avoid additional code and 173 to keep the collision probably low. 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 MUST be computed as follows: 298 1. Compute the SHA-256 [RFC6234] hash of the input data. The input 299 data depends on the cached info type. This document defines two 300 cached info types, described in Section 4.1 and in Section 4.2. 301 Note that the computed hash only covers the input data structure 302 (and not any type and length information of the record layer). 303 Appendix A shows an example. 305 2. Truncate the output of the SHA-256 hash. When a hash value is 306 truncated to 32 bits, the leftmost 32 bits (that is, the most 307 significant 32 bits in network byte order) from the binary 308 representation of the hash value MUST be used as the truncated 309 value. An example of a 256-bit hash output truncated to 32 bits 310 is shown in Figure 3. 312 256-bit hash: 313 0x265357902fe1b7e2a04b897c6025d7a2265357902fe1b7e2a04b897c6025d7a2 315 32-bit truncated hash: 316 0x26535790 318 Figure 3: Truncated Hash Example. 320 The purpose of the fingerprint provided by the client is to help the 321 server select the correct information. For example, in case of the 322 certificate message the fingerprint identifies the server certificate 323 (and the corresponding private key) for use for with the rest of the 324 handshake. Servers may have more than one certificate and therefore 325 a hash needs to be long enough to keep the probably of hash 326 collisions low. On the other hand, the cached info design aims to 327 reduce the amount of data being exchanged. The security of the 328 handshake depends on the private key and not on the size of the 329 fingerprint. Hence, the fingerprint is a way to prevent the server 330 from accidentally selecting the wrong information. If an attacker 331 injects an incorrect fingerprint then two outcomes are possible: (1) 332 The fingerprint does not relate to any cached state and the server 333 has to fall back to a full exchange. (2) If the attacker manages to 334 inject a fingerprint that refers to data the client has not cached 335 then the exchange will fail later when the client continues with the 336 handshake and aims to verify the digital signature. The signature 337 verification will fail since the public key cached by the client will 338 not correspond to the private key that was used by server to sign the 339 message. 341 6. Example 343 In the regular, full TLS handshake exchange, shown in Figure 4, the 344 TLS server provides its certificate in the Certificate payload to the 345 client, see step (1). This allows the client to store the 346 certificate for future use. After some time the TLS client again 347 interacts with the same TLS server and makes use of the TLS cached 348 info extension, as shown in Figure 5. The TLS client indicates 349 support for this specification via the "cached_info" extension, see 350 step (2), and indicates that it has stored the certificate from the 351 earlier exchange (by indicating the 'cert' type). With step (3) the 352 TLS server acknowledges the supports of the 'cert' type and by 353 including the value in the server hello informs the client that the 354 content of the certificate payload contains the fingerprint of the 355 certificate instead of the RFC 5246-defined payload of the 356 certificate message in step (4). 358 ClientHello -> 359 <- ServerHello 360 Certificate* // (1) 361 ServerKeyExchange* 362 CertificateRequest* 363 ServerHelloDone 365 Certificate* 366 ClientKeyExchange 367 CertificateVerify* 368 [ChangeCipherSpec] 369 Finished -> 371 <- [ChangeCipherSpec] 372 Finished 374 Application Data <-------> Application Data 376 Figure 4: Example Message Exchange: Initial (full) Exchange. 378 ClientHello 379 cached_info=(cert) -> // (2) 380 <- ServerHello 381 cached_info=(cert) (3) 382 Certificate (4) 383 ServerKeyExchange* 384 ServerHelloDone 386 ClientKeyExchange 387 CertificateVerify* 388 [ChangeCipherSpec] 389 Finished -> 391 <- [ChangeCipherSpec] 392 Finished 394 Application Data <-------> Application Data 396 Figure 5: Example Message Exchange: TLS Cached Extension Usage. 398 7. Security Considerations 400 This specification defines a mechanism to reference stored state 401 using a fingerprint. Sending a fingerprint of cached information in 402 an unencrypted handshake, as the client and server hello is, may 403 allow an attacker or observer to correlate independent TLS exchanges. 404 While some information elements used in this specification, such as 405 server certificates, are public objects and usually do not contain 406 sensitive information, other not yet defined types may. Those who 407 implement and deploy this specification should therefore make an 408 informed decision whether the cached information is inline with their 409 security and privacy goals. In case of concerns, it is advised to 410 avoid sending the fingerprint of the data objects in clear. 412 The use of the cached info extension allows the server to send 413 significantly smaller TLS messages. Consequently, these omitted 414 parts of the messages are not included in the transcript of the 415 handshake in the TLS Finish message. However, since the client and 416 the server communicate the hash values of the cached data in the 417 initial handshake messages the fingerprints are included in the TLS 418 Finish message. 420 Clients MUST ensure that they only cache information from legitimate 421 sources. For example, when the client populates the cache from a TLS 422 exchange then it must only cache information after the successful 423 completion of a TLS exchange to ensure that an attacker does not 424 inject incorrect information into the cache. Failure to do so allows 425 for man-in-the-middle attacks. 427 Security considerations for the fingerprint calculation are discussed 428 in Section 5. 430 8. IANA Considerations 432 8.1. New Entry to the TLS ExtensionType Registry 434 IANA is requested to add an entry to the existing TLS ExtensionType 435 registry, defined in [RFC5246], for cached_info(TBD) defined in this 436 document. 438 8.2. New Registry for CachedInformationType 440 IANA is requested to establish a registry for TLS 441 CachedInformationType values. The first entries in the registry are 443 o cert(1) 445 o cert_req(2) 447 The policy for adding new values to this registry, following the 448 terminology defined in [RFC5226], is as follows: 450 o 0-63 (decimal): Standards Action 452 o 64-223 (decimal): Specification Required 453 o 224-255 (decimal): reserved for Private Use 455 9. Acknowledgments 457 We would like to thank the following persons for your detailed 458 document reviews: 460 o Paul Wouters and Nikos Mavrogiannopoulos (December 2011) 462 o Rob Stradling (February 2012) 464 o Ondrej Mikle (March 2012) 466 o Ilari Liusvaara, Adam Langley, and Eric Rescorla (July 2014) 468 o Sean Turner (August 2014) 470 o Martin Thomson (August 2015) 472 o Jouni Korhonen (November 2015) 474 o Matt Miller (December 2015) 476 We would also to thank Martin Thomson, Karthikeyan Bhargavan, Sankalp 477 Bagaria and Eric Rescorla for their feedback regarding the 478 fingerprint calculation. 480 Finally, we would like to thank the TLS working group chairs, Sean 481 Turner and Joe Salowey, as well as the responsible security area 482 director, Stephen Farrell, for their support and their reviews. 484 10. References 486 10.1. Normative References 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 490 RFC2119, March 1997, 491 . 493 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 494 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 495 RFC5246, August 2008, 496 . 498 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 499 Extensions: Extension Definitions", RFC 6066, DOI 500 10.17487/RFC6066, January 2011, 501 . 503 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 504 (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 505 10.17487/RFC6234, May 2011, 506 . 508 10.2. Informative References 510 [ASN.1-Dump] 511 Gutmann, P., "ASN.1 Object Dump Program", February 2013, 512 . 514 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 515 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 516 DOI 10.17487/RFC5226, May 2008, 517 . 519 [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object 520 Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, 521 . 523 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 524 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 525 Transport Layer Security (TLS) and Datagram Transport 526 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 527 June 2014, . 529 Appendix A. Example 531 Consider a certificate containing an NIST P256 elliptic curve public 532 key displayed using Peter Gutmann's ASN.1 decoder [ASN.1-Dump] in 533 Figure 6. 535 0 556: SEQUENCE { 536 4 434: SEQUENCE { 537 8 3: [0] { 538 10 1: INTEGER 2 539 : } 540 13 1: INTEGER 13 541 16 10: SEQUENCE { 542 18 8: OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2) 543 : } 544 28 62: SEQUENCE { 545 30 11: SET { 546 32 9: SEQUENCE { 547 34 3: OBJECT IDENTIFIER countryName (2 5 4 6) 548 39 2: PrintableString 'NL' 549 : } 550 : } 551 43 17: SET { 552 45 15: SEQUENCE { 553 47 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 554 52 8: PrintableString 'PolarSSL' 555 : } 556 : } 557 62 28: SET { 558 64 26: SEQUENCE { 559 66 3: OBJECT IDENTIFIER commonName (2 5 4 3) 560 71 19: PrintableString 'Polarssl Test EC CA' 561 : } 562 : } 563 : } 564 92 30: SEQUENCE { 565 94 13: UTCTime 24/09/2013 15:52:04 GMT 566 109 13: UTCTime 22/09/2023 15:52:04 GMT 567 : } 568 124 65: SEQUENCE { 569 126 11: SET { 570 128 9: SEQUENCE { 571 130 3: OBJECT IDENTIFIER countryName (2 5 4 6) 572 135 2: PrintableString 'NL' 573 : } 574 : } 575 139 17: SET { 576 141 15: SEQUENCE { 577 143 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 578 148 8: PrintableString 'PolarSSL' 579 : } 580 : } 581 158 31: SET { 582 160 29: SEQUENCE { 583 162 3: OBJECT IDENTIFIER commonName (2 5 4 3) 584 167 22: PrintableString 'PolarSSL Test Client 2' 585 : } 586 : } 587 : } 588 191 89: SEQUENCE { 589 193 19: SEQUENCE { 590 195 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 591 204 8: OBJECT IDENTIFIER prime256v1 (1 2 840 10045 3 1 7) 592 : } 594 214 66: BIT STRING 595 : 04 57 E5 AE B1 73 DF D3 AC BB 93 B8 81 FF 12 AE 596 : EE E6 53 AC CE 55 53 F6 34 0E CC 2E E3 63 25 0B 597 : DF 98 E2 F3 5C 60 36 96 C0 D5 18 14 70 E5 7F 9F 598 : D5 4B 45 18 E5 B0 6C D5 5C F8 96 8F 87 70 A3 E4 599 : C7 600 : } 601 282 157: [3] { 602 285 154: SEQUENCE { 603 288 9: SEQUENCE { 604 290 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 605 295 2: OCTET STRING, encapsulates { 606 297 0: SEQUENCE {} 607 : } 608 : } 609 299 29: SEQUENCE { 610 301 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 611 306 22: OCTET STRING, encapsulates { 612 308 20: OCTET STRING 613 : 7A 00 5F 86 64 FC E0 5D E5 11 10 3B B2 E6 3B C4 614 : 26 3F CF E2 615 : } 616 : } 617 330 110: SEQUENCE { 618 332 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35) 619 337 103: OCTET STRING, encapsulates { 620 339 101: SEQUENCE { 621 341 20: [0] 622 : 9D 6D 20 24 49 01 3F 2B CB 78 B5 19 BC 7E 24 C9 623 : DB FB 36 7C 624 363 66: [1] { 625 365 64: [4] { 626 367 62: SEQUENCE { 627 369 11: SET { 628 371 9: SEQUENCE { 629 373 3: OBJECT IDENTIFIER countryName (2 5 4 6) 630 378 2: PrintableString 'NL' 631 : } 632 : } 633 382 17: SET { 634 384 15: SEQUENCE { 635 386 3: OBJECT IDENTIFIER organizationName 636 : (2 5 4 10) 637 391 8: PrintableString 'PolarSSL' 638 : } 639 : } 640 401 28: SET { 641 403 26: SEQUENCE { 642 405 3: OBJECT IDENTIFIER commonName (2 5 4 3) 643 410 19: PrintableString 'Polarssl Test EC CA' 644 : } 645 : } 646 : } 647 : } 648 : } 649 431 9: [2] 00 C1 43 E2 7E 62 43 CC E8 650 : } 651 : } 652 : } 653 : } 654 : } 655 : } 656 442 10: SEQUENCE { 657 444 8: OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2) 658 : } 659 454 104: BIT STRING, encapsulates { 660 457 101: SEQUENCE { 661 459 48: INTEGER 662 : 4A 65 0D 7B 20 83 A2 99 B9 A8 0F FC 8D EE 8F 3D 663 : BB 70 4C 96 03 AC 8E 78 70 DD F2 0E A0 B2 16 CB 664 : 65 8E 1A C9 3F 2C 61 7E F8 3C EF AD 1C EE 36 20 665 509 49: INTEGER 666 : 00 9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA 667 : 54 2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC 668 : 42 49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57 669 : 45 670 : } 671 : } 672 : } 674 Figure 6: ASN.1-based Certificate: Example. 676 To include the certificate shown in Figure 6 in a TLS/DTLS 677 Certificate message it is prepended with a message header. This 678 Certificate message header in our example is 0b 00 02 36 00 02 33 00 679 02 00 02 30, which indicates: 681 Message Type: 0b -- 1 byte type field indicating a Certificate 682 message 684 Length: 00 02 36 -- 3 byte length field indicating a 566 bytes 685 payload 687 Certificates Length: 00 02 33 -- 3 byte length field indicating 563 688 bytes for the entire certificates_list structure, which may 689 contain multiple certificates. In our example only one 690 certificate is included. 692 Certificate Length: 00 02 30 -- 3 byte length field indicating 560 693 bytes of the actual certificate following immediately afterwards. 694 In our example, this is the certificate content with 30 82 02 .... 695 9E 57 45 shown in Figure 7. 697 The hex encoding of the ASN.1 encoded certificate payload shown in 698 Figure 6 leads to the following encoding. 700 30 82 02 2C 30 82 01 B2 A0 03 02 01 02 02 01 0D 701 30 0A 06 08 2A 86 48 CE 3D 04 03 02 30 3E 31 0B 702 30 09 06 03 55 04 06 13 02 4E 4C 31 11 30 0F 06 703 03 55 04 0A 13 08 50 6F 6C 61 72 53 53 4C 31 1C 704 30 1A 06 03 55 04 03 13 13 50 6F 6C 61 72 73 73 705 6C 20 54 65 73 74 20 45 43 20 43 41 30 1E 17 0D 706 31 33 30 39 32 34 31 35 35 32 30 34 5A 17 0D 32 707 33 30 39 32 32 31 35 35 32 30 34 5A 30 41 31 0B 708 30 09 06 03 55 04 06 13 02 4E 4C 31 11 30 0F 06 709 03 55 04 0A 13 08 50 6F 6C 61 72 53 53 4C 31 1F 710 30 1D 06 03 55 04 03 13 16 50 6F 6C 61 72 53 53 711 4C 20 54 65 73 74 20 43 6C 69 65 6E 74 20 32 30 712 59 30 13 06 07 2A 86 48 CE 3D 02 01 06 08 2A 86 713 48 CE 3D 03 01 07 03 42 00 04 57 E5 AE B1 73 DF 714 D3 AC BB 93 B8 81 FF 12 AE EE E6 53 AC CE 55 53 715 F6 34 0E CC 2E E3 63 25 0B DF 98 E2 F3 5C 60 36 716 96 C0 D5 18 14 70 E5 7F 9F D5 4B 45 18 E5 B0 6C 717 D5 5C F8 96 8F 87 70 A3 E4 C7 A3 81 9D 30 81 9A 718 30 09 06 03 55 1D 13 04 02 30 00 30 1D 06 03 55 719 1D 0E 04 16 04 14 7A 00 5F 86 64 FC E0 5D E5 11 720 10 3B B2 E6 3B C4 26 3F CF E2 30 6E 06 03 55 1D 721 23 04 67 30 65 80 14 9D 6D 20 24 49 01 3F 2B CB 722 78 B5 19 BC 7E 24 C9 DB FB 36 7C A1 42 A4 40 30 723 3E 31 0B 30 09 06 03 55 04 06 13 02 4E 4C 31 11 724 30 0F 06 03 55 04 0A 13 08 50 6F 6C 61 72 53 53 725 4C 31 1C 30 1A 06 03 55 04 03 13 13 50 6F 6C 61 726 72 73 73 6C 20 54 65 73 74 20 45 43 20 43 41 82 727 09 00 C1 43 E2 7E 62 43 CC E8 30 0A 06 08 2A 86 728 48 CE 3D 04 03 02 03 68 00 30 65 02 30 4A 65 0D 729 7B 20 83 A2 99 B9 A8 0F FC 8D EE 8F 3D BB 70 4C 730 96 03 AC 8E 78 70 DD F2 0E A0 B2 16 CB 65 8E 1A 731 C9 3F 2C 61 7E F8 3C EF AD 1C EE 36 20 02 31 00 732 9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA 54 733 2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC 42 734 49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57 45 736 Figure 7: Hex Encoding of the Example Certificate. 738 Applying the SHA-256 hash function to the Certificate message, which 739 is starts with 0b 00 02 and ends with 9E 57 45, produces 740 0x086eefb4859adfe977defac494fff6b73033b4ce1f86b8f2a9fc0c6bf98605af. 741 Subsequently, this output is truncated to 32 bits, which leads to a 742 fingerpint of 0x086eefb4. 744 Authors' Addresses 746 Stefan Santesson 747 3xA Security AB 748 Scheelev. 17 749 Lund 223 70 750 Sweden 752 Email: sts@aaa-sec.com 754 Hannes Tschofenig 755 ARM Ltd. 756 Hall in Tirol 6060 757 Austria 759 Email: Hannes.tschofenig@gmx.net 760 URI: http://www.tschofenig.priv.at