idnits 2.17.00 (12 Aug 2021) /tmp/idnits6500/draft-ietf-tls-oob-pubkey-09.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 30, 2013) is 3217 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 427 -- Looks like a reference, but probably isn't: '2' on line 419 -- Looks like a reference, but probably isn't: '3' on line 431 -- Looks like a reference, but probably isn't: '4' on line 420 -- Looks like a reference, but probably isn't: '5' on line 433 -- Looks like a reference, but probably isn't: '6' on line 436 ** 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: January 31, 2014 Nokia Siemens Networks 6 J. Gilmore 8 S. Weiler 9 SPARTA, Inc. 10 T. Kivinen 11 AuthenTec 12 July 30, 2013 14 Out-of-Band Public Key Validation for Transport Layer Security (TLS) 15 draft-ietf-tls-oob-pubkey-09.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 31, 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 . . . . . . . . . . . . . . . . 8 67 4.5. Client authentication . . . . . . . . . . . . . . . . . . 8 68 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 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], for example, define the following OIDs shown 178 in Figure 3. Note that this list is not exhaustive and more OIDs may 179 be defined in future RFCs. RFC 5480 also defines a number of OIDs. 181 Key Type | Document | OID 182 -----------------------+----------------------------+------------------- 183 RSA | Section 2.3.1 of RFC 3279 | 1.2.840.113549.1.1 184 .......................|............................|................... 185 Digital Signature | | 186 Algorithm (DSS) | Section 2.3.2 of RFC 3279 | 1.2.840.10040.4.1 187 .......................|............................|................... 188 Elliptic Curve | | 189 Digital Signature | | 190 Algorithm (ECDSA) | Section 2 of RFC 5480 | 1.2.840.10045.2.1 191 -----------------------+----------------------------+------------------- 193 Figure 3: Example Algorithm Object Identifiers. 195 The message exchange in Figure 4 shows the 'client_certificate_type' 196 and 'server_certificate_type' extensions added to the client and 197 server hello messages. 199 client_hello, 200 client_certificate_type 201 server_certificate_type -> 203 <- server_hello, 204 client_certificate_type, 205 server_certificate_type, 206 certificate, 207 server_key_exchange, 208 certificate_request, 209 server_hello_done 210 certificate, 211 client_key_exchange, 212 certificate_verify, 213 change_cipher_spec, 214 finished -> 216 <- change_cipher_spec, 217 finished 219 Application Data <-------> Application Data 221 Figure 4: Basic Raw Public Key TLS Exchange. 223 The semantic of the two extensions is defined as follows: 225 The 'client_certificate_type' and 'server_certificate_type' sent 226 in the client hello, may carry a list of supported certificate 227 types, sorted by client preference. It is a list in the case 228 where the client supports multiple certificate types. These 229 extension MUST be omitted if the client only supports X.509 230 certificates. The 'client_certificate_type' sent in the client 231 hello indicates the certificate types the client is able to 232 provide to the server, when requested using a certificate_request 233 message. The 'server_certificate_type' in the client hello 234 indicates the type of certificates the client is able to process 235 when provided by the server in a subsequent certificate payload. 237 The 'client_certificate_type' returned in the server hello 238 indicates the certificate type found in the attached certificate 239 payload. Only a single value is permitted. The 240 'server_certificate_type' in the server hello indicates the type 241 of certificates the client is requested to provide in a subsequent 242 certificate payload. The value conveyed in the 243 'server_certificate_type' MUST be selected from one of the values 244 provided in the 'server_certificate_type' sent in the client 245 hello. If the server does not send a certificate_request payload 246 or none of the certificates supported by the client (as indicated 247 in the 'server_certificate_type' in the client hello) match the 248 server-supported certificate types the 'server_certificate_type' 249 payload sent in the server hello is omitted. 251 The "extension_data" field of this extension contains the 252 ClientCertTypeExtension or the ServerCertTypeExtension structure, as 253 shown in Figure 5. The CertificateType structure is an enum with 254 with values from TLS Certificate Type Registry. 256 struct { 257 select(ClientOrServerExtension) 258 case client: 259 CertificateType client_certificate_types<1..2^8-1>; 260 case server: 261 CertificateType client_certificate_type; 262 } 263 } ClientCertTypeExtension; 265 struct { 266 select(ClientOrServerExtension) 267 case client: 268 CertificateType server_certificate_types<1..2^8-1>; 269 case server: 270 CertificateType server_certificate_type; 271 } 272 } ServerCertTypeExtension; 274 Figure 5: CertTypeExtension Structure. 276 No new cipher suites are required to use raw public keys. All 277 existing cipher suites that support a key exchange method compatible 278 with the defined extension can be used. 280 4. TLS Handshake Extension 282 4.1. Client Hello 284 In order to indicate the support of out-of-band raw public keys, 285 clients MUST include the 'client_certificate_type' and 286 'server_certificate_type' extensions in an extended client hello 287 message. The hello extension mechanism is described in TLS 1.2 288 [RFC5246]. 290 4.2. Server Hello 292 If the server receives a client hello that contains the 293 'client_certificate_type' and 'server_certificate_type' extensions 294 and chooses a cipher suite then three outcomes are possible: 296 1. The server does not support the extension defined in this 297 document. In this case the server returns the server hello 298 without the extensions defined in this document. 300 2. The server supports the extension defined in this document and 301 has at least one certificate type in common with the client. In 302 this case it returns the 'server_certificate_type' and indicates 303 the selected certificate type value. 305 3. The server supports the extension defined in this document but 306 does not have a certificate type in common with the client. In 307 this case the server terminate the session with a fatal alert of 308 type "unsupported_certificate". 310 If the TLS server also requests a certificate from the client (via 311 the certificate_request) it MUST include the 312 'client_certificate_type' extension with a value chosen from the list 313 of client-supported certificates types (as provided in the 314 'client_certificate_type' of the client hello). 316 If the client hello indicates support of raw public keys in the 317 'client_certificate_type' extension and the server chooses to use raw 318 public keys then the TLS server MUST place the SubjectPublicKeyInfo 319 structure into the Certificate payload. 321 4.3. Certificate Request 322 The semantics of this message remain the same as in the TLS 323 specification. 325 4.4. Other Handshake Messages 327 All the other handshake messages are identical to the TLS 328 specification. 330 4.5. Client authentication 332 Client authentication by the TLS server is supported only through 333 authentication of the received client SubjectPublicKeyInfo via an 334 out-of-band method. 336 5. Examples 338 Figure 6, Figure 7, and Figure 8 illustrate example exchanges. 340 The first example shows an exchange where the TLS client indicates 341 its ability to receive and validate raw public keys from the server. 342 In our example the client is quite restricted since it is unable to 343 process other certificate types sent by the server. It also does not 344 have credentials (at the TLS layer) it could send. The 345 'client_certificate_type' extension indicates this in [1]. When the 346 TLS server receives the client hello it processes the 347 'client_certificate_type' extension. Since it also has a raw public 348 key it indicates in [2] that it had chosen to place the 349 SubjectPublicKeyInfo structure into the Certificate payload [3]. The 350 client uses this raw public key in the TLS handshake and an out-of- 351 band technique, such as DANE, to verify its validity. 353 client_hello, 354 server_certificate_type=(RawPublicKey) -> // [1] 356 <- server_hello, 357 server_certificate_type=(RawPublicKey), // [2] 358 certificate, // [3] 359 server_key_exchange, 360 server_hello_done 362 client_key_exchange, 363 change_cipher_spec, 364 finished -> 366 <- change_cipher_spec, 367 finished 369 Application Data <-------> Application Data 371 Figure 6: Example with Raw Public Key provided by the TLS Server 373 In our second example the TLS client as well as the TLS server use 374 raw public keys. This is a use case envisioned for smart object 375 networking. The TLS client in this case is an embedded device that 376 is configured with a raw public key for use with TLS and is also able 377 to process raw public keys sent by the server. Therefore, it 378 indicates these capabilities in [1]. As in the previously shown 379 example the server fulfills the client's request, indicates this via 380 the "RawPublicKey" value in the server_certificate_type payload, and 381 provides a raw public key into the Certificate payload back to the 382 client (see [3]). The TLS server, however, demands client 383 authentication and therefore a certificate_request is added [4]. The 384 certificate_type payload in [2] indicates that the TLS server accepts 385 raw public keys. The TLS client, who has a raw public key pre- 386 provisioned, returns it in the Certificate payload [5] to the server. 388 client_hello, 389 client_certificate_type=(RawPublicKey) // [1] 390 server_certificate_type=(RawPublicKey) // [1] 391 -> 392 <- server_hello, 393 server_certificate_type=(RawPublicKey)//[2] 394 certificate, // [3] 395 client_certificate_type=(RawPublicKey)//[4] 396 certificate_request, // [4] 397 server_key_exchange, 398 server_hello_done 400 certificate, // [5] 401 client_key_exchange, 402 change_cipher_spec, 403 finished -> 405 <- change_cipher_spec, 406 finished 408 Application Data <-------> Application Data 410 Figure 7: Example with Raw Public Key provided by the TLS Server and 411 the Client 413 In our last example we illustrate a combination of raw public key and 414 X.509 usage. The client uses a raw public key for client 415 authentication but the server provides an X.509 certificate. This 416 exchange starts with the client indicating its ability to process 417 X.509 certificates provided by the server, and the ability to send 418 raw public keys (see [1]). The server provides the X.509 certificate 419 in [3] with the indication present in [2]. For client authentication 420 the server indicates in [4] that it selected the raw public key 421 format and requests a certificate from the client in [5]. The TLS 422 client provides a raw public key in [6] after receiving and 423 processing the TLS server hello message. 425 client_hello, 426 server_certificate_type=(X.509) 427 client_certificate_type=(RawPublicKey) // [1] 428 -> 429 <- server_hello, 430 server_certificate_type=(X.509)//[2] 431 certificate, // [3] 432 client_certificate_type=(RawPublicKey)//[4] 433 certificate_request, // [5] 434 server_key_exchange, 435 server_hello_done 436 certificate, // [6] 437 client_key_exchange, 438 change_cipher_spec, 439 finished -> 441 <- change_cipher_spec, 442 finished 444 Application Data <-------> Application Data 446 Figure 8: Hybrid Certificate Example 448 6. Security Considerations 450 The transmission of raw public keys, as described in this document, 451 provides benefits by lowering the over-the-air transmission overhead 452 since raw public keys are quite naturally smaller than an entire 453 certificate. There are also advantages from a code size point of 454 view for parsing and processing these keys. The cryptographic 455 procedures for associating the public key with the possession of a 456 private key also follows standard procedures. 458 The main security challenge is, however, how to associate the public 459 key with a specific entity. Without a secure binding between 460 identity and key the protocol will be vulnerable to masquerade and 461 man-in-the-middle attacks. This document assumes that such binding 462 can be made out-of-band and we list a few examples in Section 1. 463 DANE [RFC6698] offers one such approach. In order to address these 464 vulnerabilities, specifications that make use of the extension MUST 465 specify how the identity and public key are bound. In addition to 466 ensuring the binding is done out-of-band an implementation also needs 467 to check the status of that binding. 469 If public keys are obtained using DANE, these public keys are 470 authenticated via DNSSEC. Pre-configured keys is another out of band 471 method for authenticating raw public keys. While pre-configured keys 472 are not suitable for a generic Web-based e-commerce environment such 473 keys are a reasonable approach for many smart object deployments 474 where there is a close relationship between the software running on 475 the device and the server-side communication endpoint. Regardless of 476 the chosen mechanism for out-of-band public key validation an 477 assessment of the most suitable approach has to be made prior to the 478 start of a deployment to ensure the security of the system. 480 7. IANA Considerations 482 IANA is asked to register a new value in the "TLS Certificate Types" 483 registry of Transport Layer Security (TLS) Extensions 484 [TLS-Certificate-Types-Registry], as follows: 486 Value: 2 487 Description: Raw Public Key 488 Reference: [[THIS RFC]] 490 This document asks IANA to allocate two new TLS extensions, 491 "client_certificate_type" and "server_certificate_type", from the TLS 492 ExtensionType registry defined in [RFC5246]. These extensions are 493 used in both the client hello message and the server hello message. 494 The new extension type is used for certificate type negotiation. The 495 values carried in these extensions are taken from the TLS Certificate 496 Types registry [TLS-Certificate-Types-Registry]. 498 8. Acknowledgements 500 The feedback from the TLS working group meeting at IETF#81 has 501 substantially shaped the document and we would like to thank the 502 meeting participants for their input. The support for hashes of 503 public keys has been moved to [I-D.ietf-tls-cached-info] after the 504 discussions at the IETF#82 meeting. 506 We would like to thank the following persons for their review 507 comments: Martin Rex, Bill Frantz, Zach Shelby, Carsten Bormann, 508 Cullen Jennings, Rene Struik, Alper Yegin, Jim Schaad, Barry Leiba, 509 Paul Hoffman, Robert Cragie, Nikos Mavrogiannopoulos, Phil Hunt, John 510 Bradley, Klaus Hartke, Stefan Jucker, Kovatsch Matthias, Daniel Kahn 511 Gillmor, Peter Sylvester, Hauke Mehrtens, and James Manger. Nikos 512 Mavrogiannopoulos contributed the design for re-using the certificate 513 type registry. Barry Leiba contributed guidance for the IANA 514 consideration text. Stefan Jucker, Kovatsch Matthias, and Klaus 515 Hartke provided implementation feedback regarding the 516 SubjectPublicKeyInfo structure. 518 We would like to thank our TLS working group chairs, Eric Rescorla 519 and Joe Salowey, for their guidance and support. Finally, we would 520 like to thank Sean Turner, who is the responsible security area 521 director for this work for his review comments and suggestions. 523 9. References 525 9.1. Normative References 527 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 528 Housley, R., and W. Polk, "Internet X.509 Public Key 529 Infrastructure Certificate and Certificate Revocation List 530 (CRL) Profile", RFC 5280, May 2008. 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, March 1997. 535 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 536 Identifiers for the Internet X.509 Public Key 537 Infrastructure Certificate and Certificate Revocation List 538 (CRL) Profile", RFC 3279, April 2002. 540 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 541 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 543 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 544 "Elliptic Curve Cryptography Subject Public Key 545 Information", RFC 5480, March 2009. 547 [TLS-Certificate-Types-Registry] 548 , "TLS Certificate Types Registry", February 2013, . 552 [X.690] , "Information technology - ASN.1 encoding rules: > 553 Specification of Basic Encoding Rules (BER), Canonical > 554 Encoding Rules (CER) and Distinguished Encoding Rules > 555 (DER).", RFC 5280, 2002. 557 9.2. Informative References 559 [ASN.1-Dump] 560 Gutmann, P., "ASN.1 Object Dump Program", February 2013, 561 . 563 [Defeating-SSL] 564 Marlinspike, M., "New Tricks for Defeating SSL in 565 Practice", February 2009, . 569 [I-D.ietf-core-coap] 570 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 571 Application Protocol (CoAP)", draft-ietf-core-coap-18 572 (work in progress), June 2013. 574 [I-D.ietf-tls-cached-info] 575 Santesson, S. and H. Tschofenig, "Transport Layer Security 576 (TLS) Cached Information Extension", draft-ietf-tls- 577 cached-info-14 (work in progress), March 2013. 579 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 580 (LDAP): The Protocol", RFC 4511, June 2006. 582 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 583 of Named Entities (DANE) Transport Layer Security (TLS) 584 Protocol: TLSA", RFC 6698, August 2012. 586 Appendix A. Example Encoding 588 For example, the following hex sequence describes a 589 SubjectPublicKeyInfo structure inside the certificate payload: 591 0 1 2 3 4 5 6 7 8 9 592 ---+------+-----+-----+-----+-----+-----+-----+-----+-----+----- 593 1 | 0x30, 0x81, 0x9f, 0x30, 0x0d, 0x06, 0x09, 0x2a, 0x86, 0x48, 594 2 | 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x01, 0x05, 0x00, 0x03, 0x81, 595 3 | 0x8d, 0x00, 0x30, 0x81, 0x89, 0x02, 0x81, 0x81, 0x00, 0xcd, 596 4 | 0xfd, 0x89, 0x48, 0xbe, 0x36, 0xb9, 0x95, 0x76, 0xd4, 0x13, 597 5 | 0x30, 0x0e, 0xbf, 0xb2, 0xed, 0x67, 0x0a, 0xc0, 0x16, 0x3f, 598 6 | 0x51, 0x09, 0x9d, 0x29, 0x2f, 0xb2, 0x6d, 0x3f, 0x3e, 0x6c, 599 7 | 0x2f, 0x90, 0x80, 0xa1, 0x71, 0xdf, 0xbe, 0x38, 0xc5, 0xcb, 600 8 | 0xa9, 0x9a, 0x40, 0x14, 0x90, 0x0a, 0xf9, 0xb7, 0x07, 0x0b, 601 9 | 0xe1, 0xda, 0xe7, 0x09, 0xbf, 0x0d, 0x57, 0x41, 0x86, 0x60, 602 10 | 0xa1, 0xc1, 0x27, 0x91, 0x5b, 0x0a, 0x98, 0x46, 0x1b, 0xf6, 603 11 | 0xa2, 0x84, 0xf8, 0x65, 0xc7, 0xce, 0x2d, 0x96, 0x17, 0xaa, 604 12 | 0x91, 0xf8, 0x61, 0x04, 0x50, 0x70, 0xeb, 0xb4, 0x43, 0xb7, 605 13 | 0xdc, 0x9a, 0xcc, 0x31, 0x01, 0x14, 0xd4, 0xcd, 0xcc, 0xc2, 606 14 | 0x37, 0x6d, 0x69, 0x82, 0xd6, 0xc6, 0xc4, 0xbe, 0xf2, 0x34, 607 15 | 0xa5, 0xc9, 0xa6, 0x19, 0x53, 0x32, 0x7a, 0x86, 0x0e, 0x91, 608 16 | 0x82, 0x0f, 0xa1, 0x42, 0x54, 0xaa, 0x01, 0x02, 0x03, 0x01, 609 17 | 0x00, 0x01 611 Figure 9: Example SubjectPublicKeyInfo Structure Byte Sequence. 613 The decoded byte-sequence shown in Figure 9 (for example using 614 Peter's ASN.1 decoder [ASN.1-Dump]) illustrates the structure, as 615 shown in Figure 10. 617 Offset Length Description 618 ------------------------------------------------------------------- 619 0 3+159: SEQUENCE { 620 3 2+13: SEQUENCE { 621 5 2+9: OBJECT IDENTIFIER Value (1 2 840 113549 1 1 1) 622 : PKCS #1, rsaEncryption 623 16 2+0: NULL 624 : } 625 18 3+141: BIT STRING, encapsulates { 626 22 3+137: SEQUENCE { 627 25 3+129: INTEGER Value (1024 bit) 628 157 2+3: INTEGER Value (65537) 629 : } 630 : } 631 : } 633 Figure 10: Decoding of Example SubjectPublicKeyInfo Structure. 635 Authors' Addresses 636 Paul Wouters (editor) 637 Red Hat 639 Email: paul@nohats.ca 641 Hannes Tschofenig (editor) 642 Nokia Siemens Networks 643 Linnoitustie 6 644 Espoo 02600 645 Finland 647 Phone: +358 (50) 4871445 648 Email: Hannes.Tschofenig@gmx.net 649 URI: http://www.tschofenig.priv.at 651 John Gilmore 652 PO Box 170608 653 San Francisco, California 94117 654 USA 656 Phone: +1 415 221 6524 657 Email: gnu@toad.com 658 URI: https://www.toad.com/ 660 Samuel Weiler 661 SPARTA, Inc. 662 7110 Samuel Morse Drive 663 Columbia, Maryland 21046 664 US 666 Email: weiler@tislabs.com 668 Tero Kivinen 669 AuthenTec 670 Eerikinkatu 28 671 HELSINKI FI-00180 672 FI 674 Email: kivinen@iki.fi