idnits 2.17.1 draft-ietf-tls-oob-pubkey-08.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 (July 16, 2013) is 3930 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 425 -- Looks like a reference, but probably isn't: '2' on line 417 -- Looks like a reference, but probably isn't: '3' on line 429 -- Looks like a reference, but probably isn't: '4' on line 418 -- Looks like a reference, but probably isn't: '5' on line 431 -- Looks like a reference, but probably isn't: '6' on line 434 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. 'TLS-Certificate-Types-Registry' == Outdated reference: A later version (-23) exists of draft-ietf-tls-cached-info-14 Summary: 2 errors (**), 0 flaws (~~), 2 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: January 17, 2014 Nokia Siemens Networks 6 J. Gilmore 8 S. Weiler 9 SPARTA, Inc. 10 T. Kivinen 11 AuthenTec 12 July 16, 2013 14 Out-of-Band Public Key Validation for Transport Layer Security (TLS) 15 draft-ietf-tls-oob-pubkey-08.txt 17 Abstract 19 This document specifies a new certificate type and two TLS 20 extensions, one for the client and one for the server, for exchanging 21 raw public keys in Transport Layer Security (TLS) and Datagram 22 Transport Layer Security (DTLS) for use with out-of-band public key 23 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 January 17, 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. New TLS Extension . . . . . . . . . . . . . . . . . . . . . . 3 62 4. TLS Handshake Extension . . . . . . . . . . . . . . . . . . . 7 63 4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 7 64 4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 7 65 4.3. Certificate Request . . . . . . . . . . . . . . . . . . . 7 66 4.4. Other Handshake Messages . . . . . . . . . . . . . . . . 7 67 4.5. Client authentication . . . . . . . . . . . . . . . . . . 8 68 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 74 9.2. Informative References . . . . . . . . . . . . . . . . . 13 75 Appendix A. Example Encoding . . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 Traditionally, TLS client and server public keys are obtained in PKIX 81 containers in-band using the TLS handshake and validated using trust 82 anchors based on a [PKIX] certification authority (CA). This method 83 can add a complicated trust relationship that is difficult to 84 validate. Examples of such complexity can be seen in 85 [Defeating-SSL]. 87 Alternative methods are available that allow a TLS clients/servers to 88 obtain the TLS servers/client public key: 90 o TLS clients can obtain the TLS server public key from a DNSSEC 91 secured resource records using DANE [RFC6698]. 93 o The TLS client or server public key is obtained from a [PKIX] 94 certificate chain from an Lightweight Directory Access Protocol 95 (LDAP) [LDAP] server or web page. 97 o The TLS client and server public key is provisioned into the 98 operating system firmware image, and updated via software updates. 99 For example: 101 Some smart objects use the UDP-based Constrained Application 102 Protocol (CoAP) [I-D.ietf-core-coap] to interact with a Web server 103 to upload sensor data at a regular intervals, such as temperature 104 readings. CoAP [I-D.ietf-core-coap] can utilize DTLS for securing 105 the client-to-server communication. As part of the manufacturing 106 process, the embedded device may be configured with the address 107 and the public key of a dedicated CoAP server, as well as a public 108 key for the client itself. 110 The mechanism defined herein only provides authentication when an 111 out-of-band mechanism is also used to bind the public key to the 112 entity presenting the key. 114 This document registers a new value to the IANA certificate types 115 registry for the support of raw public keys. It also defines two new 116 TLS extensions, "client_certificate_type" and 117 "server_certificate_type". 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 3. New TLS Extension 127 This section describes the changes to the TLS handshake message 128 contents when raw public keys are to be used. Figure 4 illustrates 129 the exchange of messages as described in the sub-sections below. The 130 client and the server exchange make use of two new TLS extensions, 131 namely 'client_certificate_type' and 'server_certificate_type', and 132 an already available IANA TLS Certificate Type registry 133 [TLS-Certificate-Types-Registry] to indicate their ability and desire 134 to exchange raw public keys. These raw public keys, in the form of a 135 SubjectPublicKeyInfo structure, are then carried inside the 136 Certificate payload. The Certificate and the SubjectPublicKeyInfo 137 structure is shown in Figure 1. 139 opaque ASN.1Cert<1..2^24-1>; 141 struct { 142 select(certificate_type){ 143 // certificate type defined in this document. 144 case RawPublicKey: 145 opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>; 147 // X.509 certificate defined in RFC 5246 148 case X.509: 149 ASN.1Cert certificate_list<0..2^24-1>; 151 // Additional certificate type based on TLS 152 // Certificate Type Registry 153 }; 154 } Certificate; 156 Figure 1: TLS Certificate Structure. 158 The SubjectPublicKeyInfo structure is defined in Section 4.1 of RFC 159 5280 [PKIX] and does not only contain the raw keys, such as the 160 public exponent and the modulus of an RSA public key, but also an 161 algorithm identifier. The algorithm identifier can also include 162 parameters. The structure, as shown in Figure 2, is encoded in an 163 DER encoded ASN.1 format [X.690] and therefore contains length 164 information as well. An example is provided in Appendix A. 166 SubjectPublicKeyInfo ::= SEQUENCE { 167 algorithm AlgorithmIdentifier, 168 subjectPublicKey BIT STRING } 170 AlgorithmIdentifier ::= SEQUENCE { 171 algorithm OBJECT IDENTIFIER, 172 parameters ANY DEFINED BY algorithm OPTIONAL } 174 Figure 2: SubjectPublicKeyInfo ASN.1 Structure. 176 The algorithm identifiers are Object Identifiers (OIDs). RFC 3279 177 [RFC3279] and [RFC5480] define the following OIDs shown in Figure 3. 179 Key Type | Document | OID 180 -----------------------+----------------------------+------------------- 181 RSA | Section 2.3.1 of RFC 3279 | 1.2.840.113549.1.1 182 .......................|............................|................... 183 Digital Signature | | 184 Algorithm (DSS) | Section 2.3.2 of RFC 3279 | 1.2.840.10040.4.1 185 .......................|............................|................... 186 Elliptic Curve | | 187 Digital Signature | | 188 Algorithm (ECDSA) | Section 2.3.5 of RFC 5480 | 1.2.840.10045.2.1 189 -----------------------+----------------------------+------------------- 191 Figure 3: Example Algorithm Object Identifiers. 193 The message exchange in Figure 4 shows the 'client_certificate_type' 194 and 'server_certificate_type' extensions added to the client and 195 server hello messages. 197 client_hello, 198 client_certificate_type 199 server_certificate_type -> 201 <- server_hello, 202 client_certificate_type, 203 server_certificate_type, 204 certificate, 205 server_key_exchange, 206 certificate_request, 207 server_hello_done 208 certificate, 209 client_key_exchange, 210 certificate_verify, 211 change_cipher_spec, 212 finished -> 214 <- change_cipher_spec, 215 finished 217 Application Data <-------> Application Data 219 Figure 4: Basic Raw Public Key TLS Exchange. 221 The semantic of the two extensions is defined as follows: 223 The 'client_certificate_type' and 'server_certificate_type' sent 224 in the client hello, may carry a list of supported certificate 225 types, sorted by client preference. It is a list in the case 226 where the client supports multiple certificate types. These 227 extension MUST be omitted if the client only supports X.509 228 certificates. The 'client_certificate_type' sent in the client 229 hello indicates the certificate types the client is able to 230 provide to the server, when requested using a certificate_request 231 message. The 'server_certificate_type' in the client hello 232 indicates the type of certificates the client is able to process 233 when provided by the server in a subsequent certificate payload. 235 The 'client_certificate_type' returned in the server hello 236 indicates the certificate type found in the attached certificate 237 payload. Only a single value is permitted. The 238 'server_certificate_type' in the server hello indicates the type 239 of certificates the client is requested to provide in a subsequent 240 certificate payload. The value conveyed in the 241 'server_certificate_type' MUST be selected from one of the values 242 provided in the 'server_certificate_type' sent in the client 243 hello. If the server does not send a certificate_request payload 244 or none of the certificates supported by the client (as indicated 245 in the 'server_certificate_type' in the client hello) match the 246 server-supported certificate types the 'server_certificate_type' 247 payload sent in the server hello is omitted. 249 The "extension_data" field of this extension contains the 250 ClientCertTypeExtension or the ServerCertTypeExtension structure, as 251 shown in Figure 5. The CertificateType structure is an enum with 252 with values from TLS Certificate Type Registry. 254 struct { 255 select(ClientOrServerExtension) 256 case client: 257 CertificateType client_certificate_types<1..2^8-1>; 258 case server: 259 CertificateType client_certificate_type; 260 } 261 } ClientCertTypeExtension; 263 struct { 264 select(ClientOrServerExtension) 265 case client: 266 CertificateType server_certificate_types<1..2^8-1>; 267 case server: 268 CertificateType server_certificate_type; 269 } 270 } ServerCertTypeExtension; 272 Figure 5: CertTypeExtension Structure. 274 No new cipher suites are required to use raw public keys. All 275 existing cipher suites that support a key exchange method compatible 276 with the defined extension can be used. 278 4. TLS Handshake Extension 280 4.1. Client Hello 282 In order to indicate the support of out-of-band raw public keys, 283 clients MUST include the 'client_certificate_type' and 284 'server_certificate_type' extensions in an extended client hello 285 message. The hello extension mechanism is described in TLS 1.2 286 [RFC5246]. 288 4.2. Server Hello 290 If the server receives a client hello that contains the 291 'client_certificate_type' and 'server_certificate_type' extensions 292 and chooses a cipher suite then three outcomes are possible: 294 1. The server does not support the extension defined in this 295 document. In this case the server returns the server hello 296 without the extensions defined in this document. 298 2. The server supports the extension defined in this document and 299 has at least one certificate type in common with the client. In 300 this case it returns the 'server_certificate_type' and indicates 301 the selected certificate type value. 303 3. The server supports the extension defined in this document but 304 does not have a certificate type in common with the client. In 305 this case the server terminate the session with a fatal alert of 306 type "unsupported_certificate". 308 If the TLS server also requests a certificate from the client (via 309 the certificate_request) it MUST include the 310 'client_certificate_type' extension with a value chosen from the list 311 of client-supported certificates types (as provided in the 312 'client_certificate_type' of the client hello). 314 If the client hello indicates support of raw public keys in the 315 'client_certificate_type' extension and the server chooses to use raw 316 public keys then the TLS server MUST place the SubjectPublicKeyInfo 317 structure into the Certificate payload. 319 4.3. Certificate Request 321 The semantics of this message remain the same as in the TLS 322 specification. 324 4.4. Other Handshake Messages 325 All the other handshake messages are identical to the TLS 326 specification. 328 4.5. Client authentication 330 Client authentication by the TLS server is supported only through 331 authentication of the received client SubjectPublicKeyInfo via an 332 out-of-band method. 334 5. Examples 336 Figure 6, Figure 7, and Figure 8 illustrate example exchanges. 338 The first example shows an exchange where the TLS client indicates 339 its ability to receive and validate raw public keys from the server. 340 In our example the client is quite restricted since it is unable to 341 process other certificate types sent by the server. It also does not 342 have credentials (at the TLS layer) it could send. The 343 'client_certificate_type' extension indicates this in [1]. When the 344 TLS server receives the client hello it processes the 345 'client_certificate_type' extension. Since it also has a raw public 346 key it indicates in [2] that it had chosen to place the 347 SubjectPublicKeyInfo structure into the Certificate payload [3]. The 348 client uses this raw public key in the TLS handshake and an out-of- 349 band technique, such as DANE, to verify its validity. 351 client_hello, 352 server_certificate_type=(RawPublicKey) -> // [1] 354 <- server_hello, 355 server_certificate_type=(RawPublicKey), // [2] 356 certificate, // [3] 357 server_key_exchange, 358 server_hello_done 360 client_key_exchange, 361 change_cipher_spec, 362 finished -> 364 <- change_cipher_spec, 365 finished 367 Application Data <-------> Application Data 369 Figure 6: Example with Raw Public Key provided by the TLS Server 371 In our second example the TLS client as well as the TLS server use 372 raw public keys. This is a use case envisioned for smart object 373 networking. The TLS client in this case is an embedded device that 374 is configured with a raw public key for use with TLS and is also able 375 to process raw public keys sent by the server. Therefore, it 376 indicates these capabilities in [1]. As in the previously shown 377 example the server fulfills the client's request, indicates this via 378 the "RawPublicKey" value in the server_certificate_type payload, and 379 provides a raw public key into the Certificate payload back to the 380 client (see [3]). The TLS server, however, demands client 381 authentication and therefore a certificate_request is added [4]. The 382 certificate_type payload in [2] indicates that the TLS server accepts 383 raw public keys. The TLS client, who has a raw public key pre- 384 provisioned, returns it in the Certificate payload [5] to the server. 386 client_hello, 387 client_certificate_type=(RawPublicKey) // [1] 388 server_certificate_type=(RawPublicKey) // [1] 389 -> 390 <- server_hello, 391 server_certificate_type=(RawPublicKey)//[2] 392 certificate, // [3] 393 client_certificate_type=(RawPublicKey)//[4] 394 certificate_request, // [4] 395 server_key_exchange, 396 server_hello_done 398 certificate, // [5] 399 client_key_exchange, 400 change_cipher_spec, 401 finished -> 403 <- change_cipher_spec, 404 finished 406 Application Data <-------> Application Data 408 Figure 7: Example with Raw Public Key provided by the TLS Server and 409 the Client 411 In our last example we illustrate a combination of raw public key and 412 X.509 usage. The client uses a raw public key for client 413 authentication but the server provides an X.509 certificate. This 414 exchange starts with the client indicating its ability to process 415 X.509 certificates provided by the server, and the ability to send 416 raw public keys (see [1]). The server provides the X.509 certificate 417 in [3] with the indication present in [2]. For client authentication 418 the server indicates in [4] that it selected the raw public key 419 format and requests a certificate from the client in [5]. The TLS 420 client provides a raw public key in [6] after receiving and 421 processing the TLS server hello message. 423 client_hello, 424 server_certificate_type=(X.509) 425 client_certificate_type=(RawPublicKey) // [1] 426 -> 427 <- server_hello, 428 server_certificate_type=(X.509)//[2] 429 certificate, // [3] 430 client_certificate_type=(RawPublicKey)//[4] 431 certificate_request, // [5] 432 server_key_exchange, 433 server_hello_done 434 certificate, // [6] 435 client_key_exchange, 436 change_cipher_spec, 437 finished -> 439 <- change_cipher_spec, 440 finished 442 Application Data <-------> Application Data 444 Figure 8: Hybrid Certificate Example 446 6. Security Considerations 448 The transmission of raw public keys, as described in this document, 449 provides benefits by lowering the over-the-air transmission overhead 450 since raw public keys are quite naturally smaller than an entire 451 certificate. There are also advantages from a code size point of 452 view for parsing and processing these keys. The cryptographic 453 procedures for associating the public key with the possession of a 454 private key also follows standard procedures. 456 The main security challenge is, however, how to associate the public 457 key with a specific entity. Without a secure binding between 458 identity and key the protocol will be vulnerable to masquerade and 459 man-in-the-middle attacks. This document assumes that such binding 460 can be made out-of-band and we list a few examples in Section 1. 461 DANE [RFC6698] offers one such approach. In order to address these 462 vulnerabilities, specifications that make use of the extension MUST 463 specify how the identity and public key are bound. If public keys 464 are obtained using DANE, these public keys are authenticated via 465 DNSSEC. Pre-configured keys is another out of band method for 466 authenticating raw public keys. While pre-configured keys are not 467 suitable for a generic Web-based e-commerce environment such keys are 468 a reasonable approach for many smart object deployments where there 469 is a close relationship between the software running on the device 470 and the server-side communication endpoint. Regardless of the chosen 471 mechanism for out-of-band public key validation an assessment of the 472 most suitable approach has to be made prior to the start of a 473 deployment to ensure the security of the system. 475 7. IANA Considerations 477 IANA is asked to register a new value in the "TLS Certificate Types" 478 registry of Transport Layer Security (TLS) Extensions 479 [TLS-Certificate-Types-Registry], as follows: 481 Value: 2 482 Description: Raw Public Key 483 Reference: [[THIS RFC]] 485 This document asks IANA to allocate two new TLS extensions, 486 "client_certificate_type" and "server_certificate_type", from the TLS 487 ExtensionType registry defined in [RFC5246]. These extensions are 488 used in both the client hello message and the server hello message. 489 The new extension type is used for certificate type negotiation. The 490 values carried in these extensions are taken from the TLS Certificate 491 Types registry [TLS-Certificate-Types-Registry]. 493 8. Acknowledgements 495 The feedback from the TLS working group meeting at IETF#81 has 496 substantially shaped the document and we would like to thank the 497 meeting participants for their input. The support for hashes of 498 public keys has been moved to [I-D.ietf-tls-cached-info] after the 499 discussions at the IETF#82 meeting. 501 We would like to thank the following persons for their review 502 comments: Martin Rex, Bill Frantz, Zach Shelby, Carsten Bormann, 503 Cullen Jennings, Rene Struik, Alper Yegin, Jim Schaad, Barry Leiba, 504 Paul Hoffman, Robert Cragie, Nikos Mavrogiannopoulos, Phil Hunt, John 505 Bradley, Klaus Hartke, Stefan Jucker, Kovatsch Matthias, Daniel Kahn 506 Gillmor, Peter Sylvester, and James Manger. Nikos Mavrogiannopoulos 507 contributed the design for re-using the certificate type registry. 509 Barry Leiba contributed guidance for the IANA consideration text. 510 Stefan Jucker, Kovatsch Matthias, and Klaus Hartke provided 511 implementation feedback regarding the SubjectPublicKeyInfo structure. 513 We would like to thank our TLS working group chairs, Eric Rescorla 514 and Joe Salowey, for their guidance and support. Finally, we would 515 like to thank Sean Turner, who is the responsible security area 516 director for this work for his review comments and suggestions. 518 9. References 520 9.1. Normative References 522 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 523 Housley, R., and W. Polk, "Internet X.509 Public Key 524 Infrastructure Certificate and Certificate Revocation List 525 (CRL) Profile", RFC 5280, May 2008. 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, March 1997. 530 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 531 Identifiers for the Internet X.509 Public Key 532 Infrastructure Certificate and Certificate Revocation List 533 (CRL) Profile", RFC 3279, April 2002. 535 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 536 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 538 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 539 "Elliptic Curve Cryptography Subject Public Key 540 Information", RFC 5480, March 2009. 542 [TLS-Certificate-Types-Registry] 543 , "TLS Certificate Types Registry", February 2013, . 547 [X.690] , "Information technology - ASN.1 encoding rules: > 548 Specification of Basic Encoding Rules (BER), Canonical > 549 Encoding Rules (CER) and Distinguished Encoding Rules > 550 (DER).", RFC 5280, 2002. 552 9.2. Informative References 554 [ASN.1-Dump] 555 Gutmann, P., "ASN.1 Object Dump Program", February 2013, 556 . 558 [Defeating-SSL] 559 Marlinspike, M., "New Tricks for Defeating SSL in 560 Practice", February 2009, . 564 [I-D.ietf-core-coap] 565 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 566 Application Protocol (CoAP)", draft-ietf-core-coap-18 567 (work in progress), June 2013. 569 [I-D.ietf-tls-cached-info] 570 Santesson, S. and H. Tschofenig, "Transport Layer Security 571 (TLS) Cached Information Extension", draft-ietf-tls- 572 cached-info-14 (work in progress), March 2013. 574 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 575 (LDAP): The Protocol", RFC 4511, June 2006. 577 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 578 of Named Entities (DANE) Transport Layer Security (TLS) 579 Protocol: TLSA", RFC 6698, August 2012. 581 Appendix A. Example Encoding 583 For example, the following hex sequence describes a 584 SubjectPublicKeyInfo structure inside the certificate payload: 586 0 1 2 3 4 5 6 7 8 9 587 ---+------+-----+-----+-----+-----+-----+-----+-----+-----+----- 588 1 | 0x30, 0x81, 0x9f, 0x30, 0x0d, 0x06, 0x09, 0x2a, 0x86, 0x48, 589 2 | 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x01, 0x05, 0x00, 0x03, 0x81, 590 3 | 0x8d, 0x00, 0x30, 0x81, 0x89, 0x02, 0x81, 0x81, 0x00, 0xcd, 591 4 | 0xfd, 0x89, 0x48, 0xbe, 0x36, 0xb9, 0x95, 0x76, 0xd4, 0x13, 592 5 | 0x30, 0x0e, 0xbf, 0xb2, 0xed, 0x67, 0x0a, 0xc0, 0x16, 0x3f, 593 6 | 0x51, 0x09, 0x9d, 0x29, 0x2f, 0xb2, 0x6d, 0x3f, 0x3e, 0x6c, 594 7 | 0x2f, 0x90, 0x80, 0xa1, 0x71, 0xdf, 0xbe, 0x38, 0xc5, 0xcb, 595 8 | 0xa9, 0x9a, 0x40, 0x14, 0x90, 0x0a, 0xf9, 0xb7, 0x07, 0x0b, 596 9 | 0xe1, 0xda, 0xe7, 0x09, 0xbf, 0x0d, 0x57, 0x41, 0x86, 0x60, 597 10 | 0xa1, 0xc1, 0x27, 0x91, 0x5b, 0x0a, 0x98, 0x46, 0x1b, 0xf6, 598 11 | 0xa2, 0x84, 0xf8, 0x65, 0xc7, 0xce, 0x2d, 0x96, 0x17, 0xaa, 599 12 | 0x91, 0xf8, 0x61, 0x04, 0x50, 0x70, 0xeb, 0xb4, 0x43, 0xb7, 600 13 | 0xdc, 0x9a, 0xcc, 0x31, 0x01, 0x14, 0xd4, 0xcd, 0xcc, 0xc2, 601 14 | 0x37, 0x6d, 0x69, 0x82, 0xd6, 0xc6, 0xc4, 0xbe, 0xf2, 0x34, 602 15 | 0xa5, 0xc9, 0xa6, 0x19, 0x53, 0x32, 0x7a, 0x86, 0x0e, 0x91, 603 16 | 0x82, 0x0f, 0xa1, 0x42, 0x54, 0xaa, 0x01, 0x02, 0x03, 0x01, 604 17 | 0x00, 0x01 606 Figure 9: Example SubjectPublicKeyInfo Structure Byte Sequence. 608 The decoded byte-sequence shown in Figure 9 (for example using 609 Peter's ASN.1 decoder [ASN.1-Dump]) illustrates the structure, as 610 shown in Figure 10. 612 Offset Length Description 613 ------------------------------------------------------------------- 614 0 3+159: SEQUENCE { 615 3 2+13: SEQUENCE { 616 5 2+9: OBJECT IDENTIFIER Value (1 2 840 113549 1 1 1) 617 : PKCS #1, rsaEncryption 618 16 2+0: NULL 619 : } 620 18 3+141: BIT STRING, encapsulates { 621 22 3+137: SEQUENCE { 622 25 3+129: INTEGER Value (1024 bit) 623 157 2+3: INTEGER Value (65537) 624 : } 625 : } 626 : } 628 Figure 10: Decoding of Example SubjectPublicKeyInfo Structure. 630 Authors' Addresses 632 Paul Wouters (editor) 633 Red Hat 635 Email: paul@nohats.ca 636 Hannes Tschofenig (editor) 637 Nokia Siemens Networks 638 Linnoitustie 6 639 Espoo 02600 640 Finland 642 Phone: +358 (50) 4871445 643 Email: Hannes.Tschofenig@gmx.net 644 URI: http://www.tschofenig.priv.at 646 John Gilmore 647 PO Box 170608 648 San Francisco, California 94117 649 USA 651 Phone: +1 415 221 6524 652 Email: gnu@toad.com 653 URI: https://www.toad.com/ 655 Samuel Weiler 656 SPARTA, Inc. 657 7110 Samuel Morse Drive 658 Columbia, Maryland 21046 659 US 661 Email: weiler@tislabs.com 663 Tero Kivinen 664 AuthenTec 665 Eerikinkatu 28 666 HELSINKI FI-00180 667 FI 669 Email: kivinen@iki.fi