idnits 2.17.00 (12 Aug 2021) /tmp/idnits27250/draft-ietf-tls-oob-pubkey-10.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 : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2013) is 3136 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: '1' on line 455 -- Looks like a reference, but probably isn't: '2' on line 447 -- Looks like a reference, but probably isn't: '3' on line 459 -- Looks like a reference, but probably isn't: '4' on line 448 -- Looks like a reference, but probably isn't: '5' on line 461 -- Looks like a reference, but probably isn't: '6' on line 464 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. 'TLS-Certificate-Types-Registry' == Outdated reference: draft-ietf-core-coap has been published as RFC 7252 == Outdated reference: draft-ietf-tls-cached-info has been published as RFC 7924 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS P. Wouters, Ed. 3 Internet-Draft Red Hat 4 Intended status: Standards Track H. Tschofenig, Ed. 5 Expires: April 22, 2014 Nokia Solutions and Networks 6 J. Gilmore 8 S. Weiler 9 SPARTA, Inc. 10 T. Kivinen 11 AuthenTec 12 October 19, 2013 14 Using Raw Public Keys in Transport Layer Security (TLS) and Datagram 15 Transport Layer Security (DTLS) 16 draft-ietf-tls-oob-pubkey-10.txt 18 Abstract 20 This document specifies a new certificate type and two TLS extensions 21 for exchanging raw public keys in Transport Layer Security (TLS) and 22 Datagram Transport Layer Security (DTLS) for use with out-of-band 23 public key validation. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 22, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Structure of the Raw Public Key Extension . . . . . . . . . . 4 62 4. TLS Client and Server Handshake Behavior . . . . . . . . . . 6 63 4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 7 64 4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 7 65 4.3. Client Authentication . . . . . . . . . . . . . . . . . . 8 66 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.1. TLS Server uses Raw Public Key . . . . . . . . . . . . . 8 68 5.2. TLS Client and Server use Raw Public Keys . . . . . . . . 9 69 5.3. Combined Usage of Raw Public Keys and X.509 Certificate . 10 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 75 9.2. Informative References . . . . . . . . . . . . . . . . . 14 76 Appendix A. Example Encoding . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 Traditionally, TLS client and server public keys are obtained in PKIX 82 containers in-band as part of the TLS handshake procedure and are 83 validated using trust anchors based on a PKIX certification authority 84 (CA) [RFC5280]. This method can add a complicated trust relationship 85 that is difficult to validate. Examples of such complexity can be 86 seen in [Defeating-SSL]. 88 Alternative methods are available that allow a TLS clients/servers to 89 obtain the TLS servers/client public key: 91 o TLS clients can obtain the TLS server public key from a DNSSEC 92 secured resource records using DANE [RFC6698]. 94 o The TLS client or server public key is obtained from a certificate 95 chain via a Lightweight Directory Access Protocol (LDAP) [RFC4511] 96 server or web page. 98 o The TLS client and server public key is provisioned into the 99 operating system firmware image, and updated via software updates. 100 For example: 102 Some smart objects use the UDP-based Constrained Application 103 Protocol (CoAP) [I-D.ietf-core-coap] to interact with a Web server 104 to upload sensor data at a regular intervals, such as temperature 105 readings. CoAP [I-D.ietf-core-coap] can utilize DTLS for securing 106 the client-to-server communication. As part of the manufacturing 107 process, the embedded device may be configured with the address 108 and the public key of a dedicated CoAP server, as well as a public 109 /private key pair for the client itself. 111 This document introduces the use of raw public keys in TLS/DTLS. Raw 112 public key thereby means that only a sub-set of the information found 113 in typical certificates is utilized, namely the SubjectPublicKeyInfo 114 structure of a PKIX certificates that carries the parameters 115 necessary to describe the public key. Other parameters also found in 116 a PKIX certificate are omitted. A consequence of omitting various 117 certificate related structures is that the resulting raw public key 118 is fairly small (compared to the original certificate) and does not 119 require codepaths for the ASN.1 parser, for certificate path 120 validation and other PKIX related processing tasks. To further 121 reduce the size of the exchanged information this specification can 122 be combined with the TLS Cached Info extension 123 [I-D.ietf-tls-cached-info], which enables TLS endpoints to just 124 exchange fingerprints of their public keys (rather than the full 125 public keys). 127 The mechanism defined herein only provides authentication when an 128 out-of-band mechanism is also used to bind the public key to the 129 entity presenting the key. 131 This document is structured as follows: Section 3 defines the 132 structure of the two new TLS extensions "client_certificate_type" and 133 "server_certificate_type", which can be used as part of an extended 134 TLS handshake when raw public keys are to be used. Section 4 defines 135 the behavior of the TLS client and the TLS server. Example exchanges 136 are described in Section 5. Finally, in Section 7 this document also 137 registers a new value to the IANA certificate types registry for the 138 support of raw public keys. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 We use the terms 'TLS server' and 'server' as well as 'TLS client' 147 and 'client' interchangable. 149 3. Structure of the Raw Public Key Extension 151 This section defines the two TLS extensions 'client_certificate_type' 152 and 'server_certificate_type', which can be used as part of an 153 extended TLS handshake when raw public keys are used. Section 4 154 defines the behavior of the TLS client and the TLS server using this 155 extension. 157 This specification reuses the SubjectPublicKeyInfo structure to 158 encode the raw public key and to convey that information within the 159 TLS handshake the Certificate payload is utilized as a container, as 160 shown in Figure 1. The shown Certificate structure is an adaptation 161 of its original form [RFC5246]. 163 opaque ASN.1Cert<1..2^24-1>; 165 struct { 166 select(certificate_type){ 168 // certificate type defined in this document. 169 case RawPublicKey: 170 opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>; 172 // X.509 certificate defined in RFC 5246 173 case X.509: 174 ASN.1Cert certificate_list<0..2^24-1>; 176 // Additional certificate type based on TLS 177 // Certificate Type Registry 178 }; 179 } Certificate; 181 Figure 1: Certificate Payload as a Container for the Raw Public Key. 183 The SubjectPublicKeyInfo structure is defined in Section 4.1 of RFC 184 5280 [RFC5280] and does not only contain the raw keys, such as the 185 public exponent and the modulus of an RSA public key, but also an 186 algorithm identifier. The algorithm identifier can also include 187 parameters. The structure, as shown in Figure 2, is represented in a 188 DER encoded ASN.1 format [X.690] and therefore contains length 189 information as well. An example is provided in Appendix A. 191 SubjectPublicKeyInfo ::= SEQUENCE { 192 algorithm AlgorithmIdentifier, 193 subjectPublicKey BIT STRING } 195 AlgorithmIdentifier ::= SEQUENCE { 196 algorithm OBJECT IDENTIFIER, 197 parameters ANY DEFINED BY algorithm OPTIONAL } 199 Figure 2: SubjectPublicKeyInfo ASN.1 Structure. 201 The algorithm identifiers are Object Identifiers (OIDs). RFC 3279 202 [RFC3279] and [RFC5480], for example, define the following OIDs shown 203 in Figure 3. Note that this list is not exhaustive and more OIDs may 204 be defined in future RFCs. RFC 5480 also defines a number of OIDs. 206 Key Type | Document | OID 207 -----------------------+----------------------------+------------------- 208 RSA | Section 2.3.1 of RFC 3279 | 1.2.840.113549.1.1 209 .......................|............................|................... 210 Digital Signature | | 211 Algorithm (DSA) | Section 2.3.2 of RFC 3279 | 1.2.840.10040.4.1 212 .......................|............................|................... 213 Elliptic Curve | | 214 Digital Signature | | 215 Algorithm (ECDSA) | Section 2 of RFC 5480 | 1.2.840.10045.2.1 216 -----------------------+----------------------------+------------------- 218 Figure 3: Example Algorithm Object Identifiers. 220 The extension format for extended client hellos and extended server, 221 via the "extension_data" field, is used to carry the 222 ClientCertTypeExtension and the ServerCertTypeExtension structures. 223 These two structures are shown in Figure 4. The CertificateType 224 structure is an enum with values taken from the 'TLS Certificate 225 Type' registry [TLS-Certificate-Types-Registry]. 227 struct { 228 select(ClientOrServerExtension) 229 case client: 230 CertificateType client_certificate_types<1..2^8-1>; 231 case server: 232 CertificateType client_certificate_type; 233 } 234 } ClientCertTypeExtension; 235 struct { 236 select(ClientOrServerExtension) 237 case client: 238 CertificateType server_certificate_types<1..2^8-1>; 239 case server: 240 CertificateType server_certificate_type; 241 } 242 } ServerCertTypeExtension; 244 Figure 4: CertTypeExtension Structure. 246 4. TLS Client and Server Handshake Behavior 248 This specification extends the ClientHello and the ServerHello 249 messages, according to the extension procedures defined in [RFC5246]. 250 It does not extend or modify any other TLS message. 252 Note: No new cipher suites are required to use raw public keys. All 253 existing cipher suites that support a key exchange method compatible 254 with the defined extension can be used. 256 The high-level message exchange in Figure 5 shows the 257 'client_certificate_type' and 'server_certificate_type' extensions 258 added to the client and server hello messages. 260 client_hello, 261 client_certificate_type, 262 server_certificate_type -> 264 <- server_hello, 265 client_certificate_type, 266 server_certificate_type, 267 certificate, 268 server_key_exchange, 269 certificate_request, 270 server_hello_done 271 certificate, 272 client_key_exchange, 273 certificate_verify, 274 change_cipher_spec, 275 finished -> 277 <- change_cipher_spec, 278 finished 280 Application Data <-------> Application Data 281 Figure 5: Basic Raw Public Key TLS Exchange. 283 4.1. Client Hello 285 In order to indicate the support of raw public keys, clients include 286 the 'client_certificate_type' and/or the 'server_certificate_type' 287 extensions in an extended client hello message. The hello extension 288 mechanism is described in Section 7.4.1.4 of TLS 1.2 [RFC5246]. 290 The 'client_certificate_type' sent in the client hello indicates the 291 certificate types the client is able to provide to the server, when 292 requested using a certificate_request message. 294 The 'server_certificate_type' in the client hello indicates the types 295 of certificates the client is able to process when provided by the 296 server in a subsequent certificate payload. 298 The 'client_certificate_type' and 'server_certificate_type' sent in 299 the client hello may carry a list of supported certificate types, 300 sorted by client preference. It is a list in the case where the 301 client supports multiple certificate types. 303 The TLS client MUST omit the 'client_certificate_type' extension in 304 the client hello if it does not possess a client certificate or is 305 not configured to use one with the given TLS server. The TLS client 306 MUST omit the 'server_certificate_type' extension in the client hello 307 if it is unable to process any certificate types from the server 308 (which is a situation that should not occur in normal circumstances). 310 4.2. Server Hello 312 If the server receives a client hello that contains the 313 'client_certificate_type' and 'server_certificate_type' extensions 314 and chooses a cipher suite then three outcomes are possible: 316 1. The server does not support the extension defined in this 317 document. In this case the server returns the server hello 318 without the extensions defined in this document. 320 2. The server supports the extension defined in this document but it 321 does not have a certificate type in common with the client. Then 322 the server terminates the session with a fatal alert of type 323 "unsupported_certificate". 325 3. The server supports the extensions defined in this document and 326 has at least one certificate type in common with the client. In 327 this case the processing rules described below are followed. 329 If the client hello indicates support of raw public keys in the 330 'client_certificate_type' extension and the server chooses to use raw 331 public keys then the TLS server MUST place the SubjectPublicKeyInfo 332 structure into the Certificate payload. 334 If the TLS server also requests a certificate from the client (via 335 the certificate_request message) it MUST include the 336 'client_certificate_type' extension with a value chosen from the list 337 of client-supported certificates types (as provided in the 338 'client_certificate_type' of the client hello). 340 If the server does not send a certificate_request payload (for 341 example, because client authentication happens at the application 342 layer or no client authentication is required) or none of the 343 certificates supported by the client (as indicated in the 344 'server_certificate_type' in the client hello) match the server- 345 supported certificate types then the 'server_certificate_type' 346 payload in the server hello is omitted. 348 4.3. Client Authentication 350 Authentication of the TLS client to the TLS server is supported only 351 through authentication of the received client SubjectPublicKeyInfo 352 via an out-of-band method. 354 5. Examples 356 This section illustrates a number of possible usage scenarios. 358 5.1. TLS Server uses Raw Public Key 360 This section shows an example where the TLS client indicates its 361 ability to receive and validate raw public keys from the server. In 362 our example the client is quite restricted since it is unable to 363 process other certificate types sent by the server. It also does not 364 have credentials (at the TLS layer) it could send to the server and 365 therefore omits the 'client_certificate_type' extension. Hence, the 366 client only populates the 'server_certificate_type' extension with 367 the raw public key type, as shown in [1]. 369 When the TLS server receives the client hello it processes the 370 extension. Since it has a raw public key it indicates in [2] that it 371 had chosen to place the SubjectPublicKeyInfo structure into the 372 Certificate payload [3]. 374 The client uses this raw public key in the TLS handshake together 375 with an out-of-band validation technique, such as DANE, to verify it. 377 client_hello, 378 server_certificate_type=(RawPublicKey) // [1] 379 -> 380 <- server_hello, 381 server_certificate_type=(RawPublicKey), // [2] 382 certificate, // [3] 383 server_key_exchange, 384 server_hello_done 386 client_key_exchange, 387 change_cipher_spec, 388 finished -> 390 <- change_cipher_spec, 391 finished 393 Application Data <-------> Application Data 395 Figure 6: Example with Raw Public Key provided by the TLS Server. 397 5.2. TLS Client and Server use Raw Public Keys 399 This section shows an example where the TLS client as well as the TLS 400 server use raw public keys. This is a use case envisioned for smart 401 object networking. The TLS client in this case is an embedded device 402 that is configured with a raw public key for use with TLS and is also 403 able to process raw public keys sent by the server. Therefore, it 404 indicates these capabilities in [1]. As in the previously shown 405 example the server fulfills the client's request, indicates this via 406 the "RawPublicKey" value in the server_certificate_type payload, and 407 provides a raw public key into the Certificate payload back to the 408 client (see [3]). The TLS server, however, demands client 409 authentication and therefore a certificate_request is added [4]. The 410 certificate_type payload in [2] indicates that the TLS server accepts 411 raw public keys. The TLS client, who has a raw public key pre- 412 provisioned, returns it in the Certificate payload [5] to the server. 414 client_hello, 415 client_certificate_type=(RawPublicKey) // [1] 416 server_certificate_type=(RawPublicKey) // [1] 417 -> 418 <- server_hello, 419 server_certificate_type=(RawPublicKey)//[2] 420 certificate, // [3] 421 client_certificate_type=(RawPublicKey)//[4] 422 certificate_request, // [4] 423 server_key_exchange, 424 server_hello_done 426 certificate, // [5] 427 client_key_exchange, 428 change_cipher_spec, 429 finished -> 431 <- change_cipher_spec, 432 finished 434 Application Data <-------> Application Data 436 Figure 7: Example with Raw Public Key provided by the TLS Server and 437 the Client. 439 5.3. Combined Usage of Raw Public Keys and X.509 Certificate 441 This section shows an example combining raw public keys and X.509 442 certificates. The client uses a raw public key for client 443 authentication but the server provides an X.509 certificate. This 444 exchange starts with the client indicating its ability to process 445 X.509 certificates provided by the server, and the ability to send 446 raw public keys (see [1]). The server provides the X.509 certificate 447 in [3] with the indication present in [2]. For client authentication 448 the server indicates in [4] that it selected the raw public key 449 format and requests a certificate from the client in [5]. The TLS 450 client provides a raw public key in [6] after receiving and 451 processing the TLS server hello message. 453 client_hello, 454 server_certificate_type=(X.509) 455 client_certificate_type=(RawPublicKey) // [1] 456 -> 457 <- server_hello, 458 server_certificate_type=(X.509)//[2] 459 certificate, // [3] 460 client_certificate_type=(RawPublicKey)//[4] 461 certificate_request, // [5] 462 server_key_exchange, 463 server_hello_done 464 certificate, // [6] 465 client_key_exchange, 466 change_cipher_spec, 467 finished -> 468 <- change_cipher_spec, 469 finished 471 Application Data <-------> Application Data 473 Figure 8: Hybrid Certificate Example. 475 6. Security Considerations 477 The transmission of raw public keys, as described in this document, 478 provides benefits by lowering the over-the-air transmission overhead 479 since raw public keys are quite naturally smaller than an entire 480 certificate. There are also advantages from a code size point of 481 view for parsing and processing these keys. The cryptographic 482 procedures for associating the public key with the possession of a 483 private key also follows standard procedures. 485 The main security challenge is, however, how to associate the public 486 key with a specific entity. Without a secure binding between 487 identity and key, the protocol will be vulnerable to masquerade and 488 man-in-the-middle attacks. This document assumes that such binding 489 can be made out-of-band and we list a few examples in Section 1. 490 DANE [RFC6698] offers one such approach. In order to address these 491 vulnerabilities, specifications that make use of the extension MUST 492 specify how the identity and public key are bound. In addition to 493 ensuring the binding is done out-of-band an implementation also needs 494 to check the status of that binding. 496 If public keys are obtained using DANE, these public keys are 497 authenticated via DNSSEC. Pre-configured keys is another out of 498 band method for authenticating raw public keys. While pre- 499 configured keys are not suitable for a generic Web-based 500 e-commerce environment such keys are a reasonable approach for 501 many smart object deployments where there is a close relationship 502 between the software running on the device and the server-side 503 communication endpoint. Regardless of the chosen mechanism for 504 out-of-band public key validation an assessment of the most 505 suitable approach has to be made prior to the start of a 506 deployment to ensure the security of the system. 508 A downgrading attack is another possibility for an adversary to gain 509 advantages. Thereby, an attacker might try to influence the 510 handshake exchange to make the parties select different certificate 511 types than they would normally choose. 513 For this attack, an attacker must actively change one or more 514 handshake messages. If this occurs, the client and server will 515 compute different values for the handshake message hashes. As a 516 result, the parties will not accept each others' Finished messages. 517 Without the master_secret, the attacker cannot repair the Finished 518 messages, so the attack will be discovered. 520 7. IANA Considerations 522 IANA is asked to register a new value in the "TLS Certificate Types" 523 registry of Transport Layer Security (TLS) Extensions 524 [TLS-Certificate-Types-Registry], as follows: 526 Value: 2 527 Description: Raw Public Key 528 Reference: [[THIS RFC]] 530 This document asks IANA to allocate two new TLS extensions, 531 "client_certificate_type" and "server_certificate_type", from the TLS 532 ExtensionType registry defined in [RFC5246]. These extensions are 533 used in both the client hello message and the server hello message. 534 The new extension type is used for certificate type negotiation. The 535 values carried in these extensions are taken from the TLS Certificate 536 Types registry [TLS-Certificate-Types-Registry]. 538 8. Acknowledgements 540 The feedback from the TLS working group meeting at IETF#81 has 541 substantially shaped the document and we would like to thank the 542 meeting participants for their input. The support for hashes of 543 public keys has been moved to [I-D.ietf-tls-cached-info] after the 544 discussions at the IETF#82 meeting. 546 We would like to thank the following persons for their review 547 comments: Martin Rex, Bill Frantz, Zach Shelby, Carsten Bormann, 548 Cullen Jennings, Rene Struik, Alper Yegin, Jim Schaad, Barry Leiba, 549 Paul Hoffman, Robert Cragie, Nikos Mavrogiannopoulos, Phil Hunt, John 550 Bradley, Klaus Hartke, Stefan Jucker, Kovatsch Matthias, Daniel Kahn 551 Gillmor, Peter Sylvester, Hauke Mehrtens, Alexey Melnikov, and James 552 Manger. Nikos Mavrogiannopoulos contributed the design for re-using 553 the certificate type registry. Barry Leiba contributed guidance for 554 the IANA consideration text. Stefan Jucker, Kovatsch Matthias, and 555 Klaus Hartke provided implementation feedback regarding the 556 SubjectPublicKeyInfo structure. 558 Christer Holmberg provided the General Area (Gen-Art) review, Yaron 559 Sheffer provided the Security Directorate (SecDir) review, Bert 560 Greevenbosch provided the Applications Area Directorate review, and 561 Linda Dunbar provided the Operations Directorate review. 563 We would like to thank our TLS working group chairs, Eric Rescorla 564 and Joe Salowey, for their guidance and support. Finally, we would 565 like to thank Sean Turner, who is the responsible security area 566 director for this work for his review comments and suggestions. 568 9. References 570 9.1. Normative References 572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 573 Requirement Levels", BCP 14, RFC 2119, March 1997. 575 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 576 Identifiers for the Internet X.509 Public Key 577 Infrastructure Certificate and Certificate Revocation List 578 (CRL) Profile", RFC 3279, April 2002. 580 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 581 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 583 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 584 Housley, R., and W. Polk, "Internet X.509 Public Key 585 Infrastructure Certificate and Certificate Revocation List 586 (CRL) Profile", RFC 5280, May 2008. 588 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 589 "Elliptic Curve Cryptography Subject Public Key 590 Information", RFC 5480, March 2009. 592 [TLS-Certificate-Types-Registry] 593 , "TLS Certificate Types Registry", February 2013, . 597 [X.690] ITU, "ITU-T Recommendation X.690 (2002) | ISO/IEC 598 8825-1:2002, Information technology - ASN.1 encoding 599 rules: Specification of Basic Encoding Rules (BER), 600 Canonical Encoding Rules (CER) and Distinguished Encoding 601 Rules (DER)", 2002. 603 9.2. Informative References 605 [ASN.1-Dump] 606 Gutmann, P., "ASN.1 Object Dump Program", February 2013, 607 . 609 [Defeating-SSL] 610 Marlinspike, M., "New Tricks for Defeating SSL in 611 Practice", February 2009, . 615 [I-D.ietf-core-coap] 616 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 617 Application Protocol (CoAP)", draft-ietf-core-coap-18 618 (work in progress), June 2013. 620 [I-D.ietf-tls-cached-info] 621 Santesson, S. and H. Tschofenig, "Transport Layer Security 622 (TLS) Cached Information Extension", draft-ietf-tls- 623 cached-info-15 (work in progress), October 2013. 625 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 626 (LDAP): The Protocol", RFC 4511, June 2006. 628 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 629 of Named Entities (DANE) Transport Layer Security (TLS) 630 Protocol: TLSA", RFC 6698, August 2012. 632 Appendix A. Example Encoding 634 The following example hex sequence describes a SubjectPublicKeyInfo 635 structure inside the certificate payload: 637 0 1 2 3 4 5 6 7 8 9 638 ---+------+-----+-----+-----+-----+-----+-----+-----+-----+----- 639 1 | 0x30, 0x81, 0x9f, 0x30, 0x0d, 0x06, 0x09, 0x2a, 0x86, 0x48, 640 2 | 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x01, 0x05, 0x00, 0x03, 0x81, 641 3 | 0x8d, 0x00, 0x30, 0x81, 0x89, 0x02, 0x81, 0x81, 0x00, 0xcd, 642 4 | 0xfd, 0x89, 0x48, 0xbe, 0x36, 0xb9, 0x95, 0x76, 0xd4, 0x13, 643 5 | 0x30, 0x0e, 0xbf, 0xb2, 0xed, 0x67, 0x0a, 0xc0, 0x16, 0x3f, 644 6 | 0x51, 0x09, 0x9d, 0x29, 0x2f, 0xb2, 0x6d, 0x3f, 0x3e, 0x6c, 645 7 | 0x2f, 0x90, 0x80, 0xa1, 0x71, 0xdf, 0xbe, 0x38, 0xc5, 0xcb, 646 8 | 0xa9, 0x9a, 0x40, 0x14, 0x90, 0x0a, 0xf9, 0xb7, 0x07, 0x0b, 647 9 | 0xe1, 0xda, 0xe7, 0x09, 0xbf, 0x0d, 0x57, 0x41, 0x86, 0x60, 648 10 | 0xa1, 0xc1, 0x27, 0x91, 0x5b, 0x0a, 0x98, 0x46, 0x1b, 0xf6, 649 11 | 0xa2, 0x84, 0xf8, 0x65, 0xc7, 0xce, 0x2d, 0x96, 0x17, 0xaa, 650 12 | 0x91, 0xf8, 0x61, 0x04, 0x50, 0x70, 0xeb, 0xb4, 0x43, 0xb7, 651 13 | 0xdc, 0x9a, 0xcc, 0x31, 0x01, 0x14, 0xd4, 0xcd, 0xcc, 0xc2, 652 14 | 0x37, 0x6d, 0x69, 0x82, 0xd6, 0xc6, 0xc4, 0xbe, 0xf2, 0x34, 653 15 | 0xa5, 0xc9, 0xa6, 0x19, 0x53, 0x32, 0x7a, 0x86, 0x0e, 0x91, 654 16 | 0x82, 0x0f, 0xa1, 0x42, 0x54, 0xaa, 0x01, 0x02, 0x03, 0x01, 655 17 | 0x00, 0x01 657 Figure 9: Example SubjectPublicKeyInfo Structure Byte Sequence. 659 We used Peter Gutmann's ASN.1 decoder [ASN.1-Dump] to turn the above- 660 shown byte-sequence into an ASN.1 structure, as shown in of the 661 Figure 10. 663 Offset Length Description 664 ------------------------------------------------------------------- 665 0 3+159: SEQUENCE { 666 3 2+13: SEQUENCE { 667 5 2+9: OBJECT IDENTIFIER Value (1 2 840 113549 1 1 1) 668 : PKCS #1, rsaEncryption 669 16 2+0: NULL 670 : } 671 18 3+141: BIT STRING, encapsulates { 672 22 3+137: SEQUENCE { 673 25 3+129: INTEGER Value (1024 bit) 674 157 2+3: INTEGER Value (65537) 675 : } 676 : } 677 : } 679 Figure 10: Decoding of Example SubjectPublicKeyInfo Structure. 681 Authors' Addresses 683 Paul Wouters (editor) 684 Red Hat 686 Email: paul@nohats.ca 687 Hannes Tschofenig (editor) 688 Nokia Solutions and Networks 689 Linnoitustie 6 690 Espoo 02600 691 Finland 693 Phone: +358 (50) 4871445 694 Email: Hannes.Tschofenig@gmx.net 695 URI: http://www.tschofenig.priv.at 697 John Gilmore 698 PO Box 170608 699 San Francisco, California 94117 700 USA 702 Phone: +1 415 221 6524 703 Email: gnu@toad.com 704 URI: https://www.toad.com/ 706 Samuel Weiler 707 SPARTA, Inc. 708 7110 Samuel Morse Drive 709 Columbia, Maryland 21046 710 US 712 Email: weiler@tislabs.com 714 Tero Kivinen 715 AuthenTec 716 Eerikinkatu 28 717 HELSINKI FI-00180 718 FI 720 Email: kivinen@iki.fi