idnits 2.17.1 draft-ietf-tls-cached-info-22.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 (January 26, 2016) is 2984 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) -- Looks like a reference, but probably isn't: '4' on line 626 == Missing Reference: 'ChangeCipherSpec' is mentioned on line 390, but not defined -- Looks like a reference, but probably isn't: '0' on line 622 -- Looks like a reference, but probably isn't: '3' on line 602 -- Looks like a reference, but probably isn't: '1' on line 625 -- Looks like a reference, but probably isn't: '2' on line 650 ** 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: July 29, 2016 ARM Ltd. 6 January 26, 2016 8 Transport Layer Security (TLS) Cached Information Extension 9 draft-ietf-tls-cached-info-22.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 July 29, 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 . . . . . . . . . . . . . . . . . . . . . . . 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[4]; 138 case server: 139 CachedInformationType type; 140 }; 141 } CachedObject; 143 struct { 144 CachedObject cached_info<1..255>; 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 hash algorithms 168 can also be added by registering a new type. For practical reasons 169 we recommend to re-use hash algorithms already available with TLS 170 ciphersuites to avoid additional code and to keep the collision 171 probably low new hash algorithms MUST NOT have a collision resistance 172 worse than SHA-256 when truncated to 4 bytes. 174 4. Exchange Specification 176 Clients supporting this extension MAY include the "cached_info" 177 extension in the (extended) client hello. If the client includes the 178 extension then it MUST contain one or more CachedObject attributes. 180 A server supporting this extension MAY include the "cached_info" 181 extension in the (extended) server hello. By returning the 182 "cached_info" extension the server indicates that it supports the 183 cached info types. For each indicated cached info type the server 184 MUST alter the transmission of respective payloads, according to the 185 rules outlined with each type. If the server includes the extension 186 it MUST only include CachedObjects of a type also supported by the 187 client (as expressed in the client hello). For example, if a client 188 indicates support for 'cert' and 'cert_req' then the server cannot 189 respond with a "cached_info" attribute containing support for ('foo- 190 bar'). 192 Since the client includes a fingerprint of information it cached (for 193 each indicated type) the server is able to determine whether cached 194 information is stale. If the server supports this specification and 195 notices a mismatch between the data cached by the client and its own 196 information then the server MUST include the information in full and 197 MUST NOT list the respective type in the "cached_info" extension. 199 Note: If a server is part of a hosting environment then the client 200 may have cached multiple data items for a single server. To allow 201 the client to select the appropriate information from the cache it is 202 RECOMMENDED that the client utilizes the Server Name Indication 203 extension [RFC6066]. 205 Following a successful exchange of the "cached_info" extension in the 206 client and server hello, the server alters sending the corresponding 207 handshake message. How information is altered from the handshake 208 messages is defined in Section 4.1, and in Section 4.2 for the types 209 defined in this specification. 211 Appendix A shows an example hash calculation and Section 6 shows an 212 example protocol exchange. 214 4.1. Server Certificate Message 216 When a ClientHello message contains the "cached_info" extension with 217 a type set to 'cert' then the server MAY send the Certificate message 218 shown in Figure 1 under the following conditions: 220 o The server software implements the "cached_info" extension defined 221 in this specification. 223 o The 'cert' cached info extension is enabled (for example, a policy 224 allows the use of this extension). 226 o The server compared the value in the hash_value field of the 227 client-provided "cached_info" extension with the fingerprint of 228 the Certificate message it normally sends to clients. This check 229 ensures that the information cached by the client is current. The 230 procedure for calculating the fingerprint is described in 231 Section 5. 233 The original Certificate handshake message syntax is defined in 234 [RFC5246] and has been extended with [RFC7250]. RFC 7250 allows the 235 certificate payload to contain only the SubjectPublicKeyInfo instead 236 of the full information typically found in a certificate. Hence, 237 when this specification is used in combination with [RFC7250] and the 238 negotiated certificate type is a raw public key then the TLS server 239 omits sending a Certificate payload that contains an ASN.1 240 Certificate structure with the included SubjectPublicKeyInfo rather 241 than the full certificate chain. As such, this extension is 242 compatible with the raw public key extension defined in RFC 7250. 243 Note: We assume that the server implementation is able to select the 244 appropriate certificate or SubjectPublicKeyInfo from the received 245 hash value. If the SNI extension is used by the client then the 246 server has additional information to guide the selection of the 247 appropriate cached info. 249 When the cached info specification is used then a modified version of 250 the Certificate message is exchanged. The modified structure is 251 shown in Figure 1. 253 struct { 254 opaque hash_value[4]; 255 } Certificate; 257 Figure 1: Cached Info Certificate Message. 259 4.2. CertificateRequest Message 261 When a fingerprint for an object of type 'cert_req' is provided in 262 the client hello, the server MAY send the CertificateRequest message 263 shown in Figure 2 message under the following conditions: 265 o The server software implements the "cached_info" extension defined 266 in this specification. 268 o The 'cert_req' cached info extension is enabled (for example, a 269 policy allows the use of this extension). 271 o The server compared the value in the hash_value field of the 272 client-provided "cached_info" extension with the fingerprint of 273 the CertificateRequest message it normally sends to clients. This 274 check ensures that the information cached by the client is 275 current. The procedure for calculating the fingerprint is 276 described in Section 5. 278 o The server wants to request a certificate from the client. 280 The original CertificateRequest handshake message syntax is defined 281 in [RFC5246]. The modified structure of the CertificateRequest 282 message is shown in Figure 2. 284 struct { 285 opaque hash_value[4]; 286 } CertificateRequest; 288 Figure 2: Cached Info CertificateRequest Message. 290 The CertificateRequest payload is the input parameter to the 291 fingerprint calculation described in Section 5. 293 5. Fingerprint Calculation 295 The fingerprint MUST be computed as follows: 297 1. Compute the SHA-256 [RFC6234] hash of the input data. The input 298 data depends on the cached info type. This document defines two 299 cached info types, described in Section 4.1 and in Section 4.2. 300 Note that the computed hash only covers the input data structure 301 (and not any type and length information of the record layer). 302 Appendix A shows an example. 304 2. Truncate the output of the SHA-256 hash. When a hash value is 305 truncated to 32 bits, the leftmost 32 bits (that is, the most 306 significant 32 bits in network byte order) from the binary 307 representation of the hash value MUST be used as the truncated 308 value. An example of a 256-bit hash output truncated to 32 bits 309 is shown in Figure 3. 311 256-bit hash: 312 0x265357902fe1b7e2a04b897c6025d7a2265357902fe1b7e2a04b897c6025d7a2 314 32-bit truncated hash: 315 0x26535790 317 Figure 3: Truncated Hash Example. 319 The purpose of the fingerprint provided by the client is to help the 320 server select the correct information. For example, in case of the 321 certificate message the fingerprint identifies the server certificate 322 (and the corresponding private key) for use for with the rest of the 323 handshake. Servers may have more than one certificate and therefore 324 a hash needs to be long enough to keep the probably of hash 325 collisions low. On the other hand, the cached info design aims to 326 reduce the amount of data being exchanged. The security of the 327 handshake depends on the private key and not on the size of the 328 fingerprint. Hence, the fingerprint is a way to prevent the server 329 from accidentally selecting the wrong information. If an attacker 330 injects an incorrect fingerprint then two outcomes are possible: (1) 331 The fingerprint does not relate to any cached state and the server 332 has to fall back to a full exchange. (2) If the attacker manages to 333 inject a fingerprint that refers to data the client has not cached 334 then the exchange will fail later when the client continues with the 335 handshake and aims to verify the digital signature. The signature 336 verification will fail since the public key cached by the client will 337 not correspond to the private key that was used by server to sign the 338 message. 340 6. Example 342 In the regular, full TLS handshake exchange, shown in Figure 4, the 343 TLS server provides its certificate in the Certificate payload to the 344 client, see step (1). This allows the client to store the 345 certificate for future use. After some time the TLS client again 346 interacts with the same TLS server and makes use of the TLS cached 347 info extension, as shown in Figure 5. The TLS client indicates 348 support for this specification via the "cached_info" extension, see 349 step (2), and indicates that it has stored the certificate from the 350 earlier exchange (by indicating the 'cert' type). With step (3) the 351 TLS server acknowledges the supports of the 'cert' type and by 352 including the value in the server hello informs the client that the 353 content of the certificate payload contains the fingerprint of the 354 certificate instead of the RFC 5246-defined payload of the 355 certificate message in step (4). 357 ClientHello -> 358 <- ServerHello 359 Certificate* // (1) 360 ServerKeyExchange* 361 CertificateRequest* 362 ServerHelloDone 364 Certificate* 365 ClientKeyExchange 366 CertificateVerify* 367 [ChangeCipherSpec] 368 Finished -> 370 <- [ChangeCipherSpec] 371 Finished 373 Application Data <-------> Application Data 375 Figure 4: Example Message Exchange: Initial (full) Exchange. 377 ClientHello 378 cached_info=(cert) -> // (2) 379 <- ServerHello 380 cached_info=(cert) (3) 381 Certificate (4) 382 ServerKeyExchange* 383 ServerHelloDone 385 ClientKeyExchange 386 CertificateVerify* 387 [ChangeCipherSpec] 388 Finished -> 390 <- [ChangeCipherSpec] 391 Finished 393 Application Data <-------> Application Data 395 Figure 5: Example Message Exchange: TLS Cached Extension Usage. 397 7. Security Considerations 399 This specification defines a mechanism to reference stored state 400 using a fingerprint. Sending a fingerprint of cached information in 401 an unencrypted handshake, as the client and server hello is, may 402 allow an attacker or observer to correlate independent TLS exchanges. 403 While some information elements used in this specification, such as 404 server certificates, are public objects and usually do not contain 405 sensitive information, other not yet defined types may. Those who 406 implement and deploy this specification should therefore make an 407 informed decision whether the cached information is inline with their 408 security and privacy goals. In case of concerns, it is advised to 409 avoid sending the fingerprint of the data objects in clear. 411 The use of the cached info extension allows the server to send 412 significantly smaller TLS messages. Consequently, these omitted 413 parts of the messages are not included in the transcript of the 414 handshake in the TLS Finish message. However, since the client and 415 the server communicate the hash values of the cached data in the 416 initial handshake messages the fingerprints are included in the TLS 417 Finish message. 419 Clients MUST ensure that they only cache information from legitimate 420 sources. For example, when the client populates the cache from a TLS 421 exchange then it must only cache information after the successful 422 completion of a TLS exchange to ensure that an attacker does not 423 inject incorrect information into the cache. Failure to do so allows 424 for man-in-the-middle attacks. 426 Security considerations for the fingerprint calculation are discussed 427 in Section 5. 429 8. IANA Considerations 431 8.1. New Entry to the TLS ExtensionType Registry 433 IANA is requested to add an entry to the existing TLS ExtensionType 434 registry, defined in [RFC5246], for cached_info(TBD) defined in this 435 document. 437 8.2. New Registry for CachedInformationType 439 IANA is requested to establish a registry for TLS 440 CachedInformationType values. The first entries in the registry are 442 o cert(1) 444 o cert_req(2) 446 The policy for adding new values to this registry, following the 447 terminology defined in [RFC5226], is as follows: 449 o 0-63 (decimal): Standards Action 451 o 64-223 (decimal): Specification Required 452 o 224-255 (decimal): reserved for Private Use 454 9. Acknowledgments 456 We would like to thank the following persons for your detailed 457 document reviews: 459 o Paul Wouters and Nikos Mavrogiannopoulos (December 2011) 461 o Rob Stradling (February 2012) 463 o Ondrej Mikle (March 2012) 465 o Ilari Liusvaara, Adam Langley, and Eric Rescorla (July 2014) 467 o Sean Turner (August 2014) 469 o Martin Thomson (August 2015) 471 o Jouni Korhonen (November 2015) 473 o Matt Miller (December 2015) 475 o Dave Garrett (December 2015) 477 We would also to thank Martin Thomson, Karthikeyan Bhargavan, Sankalp 478 Bagaria and Eric Rescorla for their feedback regarding the 479 fingerprint calculation. 481 Finally, we would like to thank the TLS working group chairs, Sean 482 Turner and Joe Salowey, as well as the responsible security area 483 director, Stephen Farrell, for their support and their reviews. 485 10. References 487 10.1. Normative References 489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 491 RFC2119, March 1997, 492 . 494 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 495 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 496 RFC5246, August 2008, 497 . 499 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 500 Extensions: Extension Definitions", RFC 6066, DOI 501 10.17487/RFC6066, January 2011, 502 . 504 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 505 (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 506 10.17487/RFC6234, May 2011, 507 . 509 10.2. Informative References 511 [ASN.1-Dump] 512 Gutmann, P., "ASN.1 Object Dump Program", February 2013, 513 . 515 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 516 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 517 DOI 10.17487/RFC5226, May 2008, 518 . 520 [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object 521 Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, 522 . 524 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 525 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 526 Transport Layer Security (TLS) and Datagram Transport 527 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 528 June 2014, . 530 Appendix A. Example 532 Consider a certificate containing an NIST P256 elliptic curve public 533 key displayed using Peter Gutmann's ASN.1 decoder [ASN.1-Dump] in 534 Figure 6. 536 0 556: SEQUENCE { 537 4 434: SEQUENCE { 538 8 3: [0] { 539 10 1: INTEGER 2 540 : } 541 13 1: INTEGER 13 542 16 10: SEQUENCE { 543 18 8: OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2) 544 : } 545 28 62: SEQUENCE { 546 30 11: SET { 547 32 9: SEQUENCE { 548 34 3: OBJECT IDENTIFIER countryName (2 5 4 6) 549 39 2: PrintableString 'NL' 550 : } 551 : } 552 43 17: SET { 553 45 15: SEQUENCE { 554 47 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 555 52 8: PrintableString 'PolarSSL' 556 : } 557 : } 558 62 28: SET { 559 64 26: SEQUENCE { 560 66 3: OBJECT IDENTIFIER commonName (2 5 4 3) 561 71 19: PrintableString 'Polarssl Test EC CA' 562 : } 563 : } 564 : } 565 92 30: SEQUENCE { 566 94 13: UTCTime 24/09/2013 15:52:04 GMT 567 109 13: UTCTime 22/09/2023 15:52:04 GMT 568 : } 569 124 65: SEQUENCE { 570 126 11: SET { 571 128 9: SEQUENCE { 572 130 3: OBJECT IDENTIFIER countryName (2 5 4 6) 573 135 2: PrintableString 'NL' 574 : } 575 : } 576 139 17: SET { 577 141 15: SEQUENCE { 578 143 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 579 148 8: PrintableString 'PolarSSL' 580 : } 581 : } 582 158 31: SET { 583 160 29: SEQUENCE { 584 162 3: OBJECT IDENTIFIER commonName (2 5 4 3) 585 167 22: PrintableString 'PolarSSL Test Client 2' 586 : } 587 : } 588 : } 589 191 89: SEQUENCE { 590 193 19: SEQUENCE { 591 195 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 592 204 8: OBJECT IDENTIFIER prime256v1 (1 2 840 10045 3 1 7) 593 : } 595 214 66: BIT STRING 596 : 04 57 E5 AE B1 73 DF D3 AC BB 93 B8 81 FF 12 AE 597 : EE E6 53 AC CE 55 53 F6 34 0E CC 2E E3 63 25 0B 598 : DF 98 E2 F3 5C 60 36 96 C0 D5 18 14 70 E5 7F 9F 599 : D5 4B 45 18 E5 B0 6C D5 5C F8 96 8F 87 70 A3 E4 600 : C7 601 : } 602 282 157: [3] { 603 285 154: SEQUENCE { 604 288 9: SEQUENCE { 605 290 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 606 295 2: OCTET STRING, encapsulates { 607 297 0: SEQUENCE {} 608 : } 609 : } 610 299 29: SEQUENCE { 611 301 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 612 306 22: OCTET STRING, encapsulates { 613 308 20: OCTET STRING 614 : 7A 00 5F 86 64 FC E0 5D E5 11 10 3B B2 E6 3B C4 615 : 26 3F CF E2 616 : } 617 : } 618 330 110: SEQUENCE { 619 332 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35) 620 337 103: OCTET STRING, encapsulates { 621 339 101: SEQUENCE { 622 341 20: [0] 623 : 9D 6D 20 24 49 01 3F 2B CB 78 B5 19 BC 7E 24 C9 624 : DB FB 36 7C 625 363 66: [1] { 626 365 64: [4] { 627 367 62: SEQUENCE { 628 369 11: SET { 629 371 9: SEQUENCE { 630 373 3: OBJECT IDENTIFIER countryName (2 5 4 6) 631 378 2: PrintableString 'NL' 632 : } 633 : } 634 382 17: SET { 635 384 15: SEQUENCE { 636 386 3: OBJECT IDENTIFIER organizationName 637 : (2 5 4 10) 638 391 8: PrintableString 'PolarSSL' 639 : } 640 : } 641 401 28: SET { 642 403 26: SEQUENCE { 643 405 3: OBJECT IDENTIFIER commonName (2 5 4 3) 644 410 19: PrintableString 'Polarssl Test EC CA' 645 : } 646 : } 647 : } 648 : } 649 : } 650 431 9: [2] 00 C1 43 E2 7E 62 43 CC E8 651 : } 652 : } 653 : } 654 : } 655 : } 656 : } 657 442 10: SEQUENCE { 658 444 8: OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2) 659 : } 660 454 104: BIT STRING, encapsulates { 661 457 101: SEQUENCE { 662 459 48: INTEGER 663 : 4A 65 0D 7B 20 83 A2 99 B9 A8 0F FC 8D EE 8F 3D 664 : BB 70 4C 96 03 AC 8E 78 70 DD F2 0E A0 B2 16 CB 665 : 65 8E 1A C9 3F 2C 61 7E F8 3C EF AD 1C EE 36 20 666 509 49: INTEGER 667 : 00 9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA 668 : 54 2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC 669 : 42 49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57 670 : 45 671 : } 672 : } 673 : } 675 Figure 6: ASN.1-based Certificate: Example. 677 To include the certificate shown in Figure 6 in a TLS/DTLS 678 Certificate message it is prepended with a message header. This 679 Certificate message header in our example is 0b 00 02 36 00 02 33 00 680 02 00 02 30, which indicates: 682 Message Type: 0b -- 1 byte type field indicating a Certificate 683 message 685 Length: 00 02 36 -- 3 byte length field indicating a 566 bytes 686 payload 688 Certificates Length: 00 02 33 -- 3 byte length field indicating 563 689 bytes for the entire certificates_list structure, which may 690 contain multiple certificates. In our example only one 691 certificate is included. 693 Certificate Length: 00 02 30 -- 3 byte length field indicating 560 694 bytes of the actual certificate following immediately afterwards. 695 In our example, this is the certificate content with 30 82 02 .... 696 9E 57 45 shown in Figure 7. 698 The hex encoding of the ASN.1 encoded certificate payload shown in 699 Figure 6 leads to the following encoding. 701 30 82 02 2C 30 82 01 B2 A0 03 02 01 02 02 01 0D 702 30 0A 06 08 2A 86 48 CE 3D 04 03 02 30 3E 31 0B 703 30 09 06 03 55 04 06 13 02 4E 4C 31 11 30 0F 06 704 03 55 04 0A 13 08 50 6F 6C 61 72 53 53 4C 31 1C 705 30 1A 06 03 55 04 03 13 13 50 6F 6C 61 72 73 73 706 6C 20 54 65 73 74 20 45 43 20 43 41 30 1E 17 0D 707 31 33 30 39 32 34 31 35 35 32 30 34 5A 17 0D 32 708 33 30 39 32 32 31 35 35 32 30 34 5A 30 41 31 0B 709 30 09 06 03 55 04 06 13 02 4E 4C 31 11 30 0F 06 710 03 55 04 0A 13 08 50 6F 6C 61 72 53 53 4C 31 1F 711 30 1D 06 03 55 04 03 13 16 50 6F 6C 61 72 53 53 712 4C 20 54 65 73 74 20 43 6C 69 65 6E 74 20 32 30 713 59 30 13 06 07 2A 86 48 CE 3D 02 01 06 08 2A 86 714 48 CE 3D 03 01 07 03 42 00 04 57 E5 AE B1 73 DF 715 D3 AC BB 93 B8 81 FF 12 AE EE E6 53 AC CE 55 53 716 F6 34 0E CC 2E E3 63 25 0B DF 98 E2 F3 5C 60 36 717 96 C0 D5 18 14 70 E5 7F 9F D5 4B 45 18 E5 B0 6C 718 D5 5C F8 96 8F 87 70 A3 E4 C7 A3 81 9D 30 81 9A 719 30 09 06 03 55 1D 13 04 02 30 00 30 1D 06 03 55 720 1D 0E 04 16 04 14 7A 00 5F 86 64 FC E0 5D E5 11 721 10 3B B2 E6 3B C4 26 3F CF E2 30 6E 06 03 55 1D 722 23 04 67 30 65 80 14 9D 6D 20 24 49 01 3F 2B CB 723 78 B5 19 BC 7E 24 C9 DB FB 36 7C A1 42 A4 40 30 724 3E 31 0B 30 09 06 03 55 04 06 13 02 4E 4C 31 11 725 30 0F 06 03 55 04 0A 13 08 50 6F 6C 61 72 53 53 726 4C 31 1C 30 1A 06 03 55 04 03 13 13 50 6F 6C 61 727 72 73 73 6C 20 54 65 73 74 20 45 43 20 43 41 82 728 09 00 C1 43 E2 7E 62 43 CC E8 30 0A 06 08 2A 86 729 48 CE 3D 04 03 02 03 68 00 30 65 02 30 4A 65 0D 730 7B 20 83 A2 99 B9 A8 0F FC 8D EE 8F 3D BB 70 4C 731 96 03 AC 8E 78 70 DD F2 0E A0 B2 16 CB 65 8E 1A 732 C9 3F 2C 61 7E F8 3C EF AD 1C EE 36 20 02 31 00 733 9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA 54 734 2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC 42 735 49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57 45 737 Figure 7: Hex Encoding of the Example Certificate. 739 Applying the SHA-256 hash function to the Certificate message, which 740 is starts with 0b 00 02 and ends with 9E 57 45, produces 741 0x086eefb4859adfe977defac494fff6b73033b4ce1f86b8f2a9fc0c6bf98605af. 742 Subsequently, this output is truncated to 32 bits, which leads to a 743 fingerprint of 0x086eefb4. 745 Authors' Addresses 747 Stefan Santesson 748 3xA Security AB 749 Scheelev. 17 750 Lund 223 70 751 Sweden 753 Email: sts@aaa-sec.com 755 Hannes Tschofenig 756 ARM Ltd. 757 Hall in Tirol 6060 758 Austria 760 Email: Hannes.tschofenig@gmx.net 761 URI: http://www.tschofenig.priv.at