< draft-kivinen-ipsecme-oob-pubkey-04.txt   draft-kivinen-ipsecme-oob-pubkey-05.txt >
IP Security Maintenance and Extensions T. Kivinen IP Security Maintenance and Extensions T. Kivinen
(ipsecme) INSIDE Secure (ipsecme) INSIDE Secure
Internet-Draft P. Wouters Internet-Draft P. Wouters
Updates: RFC 5996 (if approved) Red Hat Intended status: Standards Track Red Hat
Intended status: Standards Track H. Tschofenig Expires: April 21, 2014 H. Tschofenig
Expires: January 31, 2014 Nokia Siemens Networks Nokia Siemens Networks
July 30, 2013 October 18, 2013
More Raw Public Keys for IKEv2 More Raw Public Keys for IKEv2
draft-kivinen-ipsecme-oob-pubkey-04.txt draft-kivinen-ipsecme-oob-pubkey-05.txt
Abstract Abstract
The Internet Key Exchange Version 2 (IKEv2) protocol currently only The Internet Key Exchange Version 2 (IKEv2) protocol currently only
supports raw RSA keys. In some environments it is useful to make use supports raw RSA keys. In some environments it is useful to make use
of other types of public keys, such as those based on Elliptic Curve of other types of public keys, such as those based on Elliptic Curve
Cryptography. This documents adds support for other types of raw Cryptography. This documents adds support for other types of raw
public keys to IKEv2 and obsoletes the old raw RSA key format. public keys to IKEv2.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 31, 2014. This Internet-Draft will expire on April 21, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 13
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Certificate Encoding Payload . . . . . . . . . . . . . . . . . 3 3. Certificate Encoding Payload . . . . . . . . . . . . . . . . . 3
4. Old Raw RSA Key Certificate Type . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . . 7 A.1. ECDSA Example . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 A.2. RSA Example . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Secure DNS allows public keys to be associated with domain names for Secure DNS allows public keys to be associated with domain names for
usage with security protocols like Internet Key Exchange Version 2 usage with security protocols like Internet Key Exchange Version 2
(IKEv2) [RFC5996] and Transport Layer Security (TLS) but it relies on (IKEv2) [I-D.kivinen-ipsecme-ikev2-rfc5996bis] and Transport Layer
extensions in those protocols to be specified. Security (TLS) but it relies on extensions in those protocols to be
specified.
IKEv2 already offers support for PKCS #1 encoded RSA keys, i.e., a In [RFC5996] IKEv2 had support for PKCS #1 encoded RSA keys, i.e., a
DER- encoded RSAPublicKey structure (see [RSA] and [RFC3447]). Other DER- encoded RSAPublicKey structure (see [RSA] and [RFC3447]). Other
raw public keys types are, however, not supported. raw public keys types are, however, not supported. In
[I-D.kivinen-ipsecme-ikev2-rfc5996bis] this feature was removed, and
this document adds support for raw public keys back to IKEv2 in more
generic way.
The TLS Out-of-Band Public Key Validation specification The TLS Out-of-Band Public Key Validation specification
([I-D.ietf-tls-oob-pubkey]) adds generic support for raw public keys ([I-D.ietf-tls-oob-pubkey]) adds generic support for raw public keys
to TLS by re-using the SubjectPublicKeyInfo format from the X.509 to TLS by re-using the SubjectPublicKeyInfo format from the X.509
Public Key Infrastructure Certificate profile [RFC5280]. Public Key Infrastructure Certificate profile [RFC5280].
This document is similar than the TLS Out-of-Band Public Key This document is similar than the TLS Out-of-Band Public Key
Validation specification, and applies the concept to IKEv2 to support Validation specification, and applies the concept to IKEv2 to support
all public key formats defined by PKIX. This approach also allows all public key formats defined by PKIX. This approach also allows
future public key extensions to be supported without the need to future public key extensions to be supported without the need to
introduce further enhancements to IKEv2. introduce further enhancements to IKEv2.
To support new types of public keys in IKEv2 the following changes To support new types of public keys in IKEv2 the following changes
are needed: are needed:
o A new Certificate Encoding format needs to be defined for carrying o A new Certificate Encoding format needs to be defined for carrying
the SubjectPublicKeyInfo structure. Section 3 specifies this new the SubjectPublicKeyInfo structure. Section 3 specifies this new
encoding format. encoding format.
o A new Certificate Encoding type needs to be allocated from the o A new Certificate Encoding type needs to be allocated from the
IANA registry. Section 6 contains this request to IANA. IANA registry. Section 5 contains this request to IANA.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Certificate Encoding Payload 3. Certificate Encoding Payload
Section 3.6 of RFC 5996 defines the Certificate payload format as Section 3.6 of RFC 5996bis defines the Certificate payload format as
shown in Figure 1. shown in Figure 1.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding | | | Cert Encoding | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
~ Certificate Data ~ ~ Certificate Data ~
skipping to change at page 4, line 30 skipping to change at page 4, line 30
Certificate Data field. Certificate Data field.
Certificate Encoding Value Certificate Encoding Value
---------------------------------------------------- ----------------------------------------------------
Raw Public Key TBD Raw Public Key TBD
o Certificate Data (variable length) - Actual encoding of the o Certificate Data (variable length) - Actual encoding of the
certificate data. The type of certificate is indicated by the certificate data. The type of certificate is indicated by the
Certificate Encoding field. Certificate Encoding field.
When the certificate encoding type 'Raw Public Key' is used then the In order to provide a simple and standard way to indicate the key
Certificate Data only contains the SubjectPublicKeyInfo part of the type when the encoding type is 'Raw Public Key', the
PKIX certificate. SubjectPublicKeyInfo structure of the PKIX certificate is used. This
is a a very simple encoding, as most of the ASN.1 part can be
included literally, and recognized by block comparison. See
[I-D.ietf-tls-oob-pubkey] Appendix A for a detailed breakdown. In
addition, Appendix A has a few examples.
In the case of the Certificate Request payload the Certification In the case of the Certificate Request payload the Certification
Authority field MUST be empty if the "Raw Public Key" certificate Authority field MUST be empty if the "Raw Public Key" certificate
encoding is used. encoding is used.
Note, that we do follow public key processing rules of the section Note, that we do follow public key processing rules of the section
1.2 of the Additional Algorithms and Identifiers for RSA Cryptography 1.2 of the Additional Algorithms and Identifiers for RSA Cryptography
for PKIX ([RFC4055]) even when the SubjectPublicKeyInfo is not part for PKIX ([RFC4055]) even when the SubjectPublicKeyInfo is not part
of the certificate, but sent here. This means RSASSA-PSS and RSASSA- of the certificate, but sent here. This means RSASSA-PSS and RSASSA-
PSS-params inside the SubjectPublicKeyInfo needs to be followed. PSS-params inside the SubjectPublicKeyInfo needs to be followed.
4. Old Raw RSA Key Certificate Type 4. Security Considerations
After this there would be two ways of sending Raw RSA public keys in
the IKEv2: The original IKEv2 mechanism (Raw RSA Key, encoding value
11), and the new format defined here. The old Raw RSA Key encoding
has not been widely used. The IKEv2 protocol already supports a
method to indicate what certificate encoding formats are supported,
i.e. a peer can send one or multiple Certificate Request payload with
the certificate encoding types it supports. From this list the
recipient can see what formats are supported and select one which is
used to send Certificate back.
Implementations conforming to this document MUST use the new format
defined here for the raw public keys, regardless of the key type.
This means that old Raw RSA Key encoding value 11 MUST NOT be used
for certificate or certificate request payloads.
Note, that recipients can simply process the old Raw RSA key
encodings just like any other unsupported or unknown certificate
encoding type, i.e. skip over it, recipients MUST NOT consider
receiving such payloads as fatal error (if other end sends such
payloads, it is completely possible that the peers do not have common
format for certificate encoding and the authentication will fail
because of that).
5. Security Considerations
An IKEv2 deployment using raw public keys needs to utilize an out-of- An IKEv2 deployment using raw public keys needs to utilize an out-of-
band public key validation procedure to be confident in the band public key validation procedure to be confident in the
authenticity of the keys being used. One such mechanism is to use a authenticity of the keys being used. One such mechanism is to use a
configuration mechanism for provisioning raw public keys into the configuration mechanism for provisioning raw public keys into the
IKEv2 software. A suitable deployment is likely to be found with IKEv2 software. A suitable deployment is likely to be found with
smart objects. Yet another approach is to rely on secure DNS to smart objects. Yet another approach is to rely on secure DNS to
associate public keys to be associated with domain names using the associate public keys to be associated with domain names using the
IPSECKEY DNS RRtype [RFC4025]. More information can be found in DNS- IPSECKEY DNS RRtype [RFC4025]. More information can be found in DNS-
Based Authentication of Named Entities (DANE) [RFC6394]. Based Authentication of Named Entities (DANE) [RFC6394].
This document does not change the assumptions made by the IKEv2 This document does not change the assumptions made by the IKEv2
specifications since "Raw RSA Key" support is already available in specifications since "Raw RSA Key" support was already available in
IKEv2. This document only generalizes the raw public key support and IKEv2. This document only generalizes the raw public key support.
obsoletes the old "Raw RSA Key" format.
6. IANA Considerations 5. IANA Considerations
This document allocates a new value from the IKEv2 Certificate This document allocates a new value from the IKEv2 Certificate
Encodings registry: Encodings registry:
TBD Raw Public Key TBD Raw Public Key
This document also obsoletes the old value in the same registry, and 6. Acknowledgements
the entry for "Raw RSA Key" should be changed to:
11 Obsoleted (was Raw RSA Key)
7. Acknowledgements
This document copies parts from the similar TLS document This document copies parts from the similar TLS document
([I-D.ietf-tls-oob-pubkey]). ([I-D.ietf-tls-oob-pubkey]).
8. References 7. References
8.1. Normative References 7.1. Normative References
[I-D.kivinen-ipsecme-ikev2-rfc5996bis]
Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", draft-kivinen-ipsecme-ikev2-rfc5996bis-01 (work
in progress), October 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", "Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010. RFC 5996, September 2010.
8.2. Informative References 7.2. Informative References
[I-D.ietf-tls-oob-pubkey] [I-D.ietf-tls-oob-pubkey]
Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
T. Kivinen, "Out-of-Band Public Key Validation for T. Kivinen, "Out-of-Band Public Key Validation for
Transport Layer Security (TLS)", Transport Layer Security (TLS)",
draft-ietf-tls-oob-pubkey-08 (work in progress), draft-ietf-tls-oob-pubkey-09 (work in progress),
July 2013. July 2013.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, March 2005. Material in DNS", RFC 4025, March 2005.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
skipping to change at page 7, line 20 skipping to change at page 6, line 46
Authentication of Named Entities (DANE)", RFC 6394, Authentication of Named Entities (DANE)", RFC 6394,
October 2011. October 2011.
[RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key Obtaining Digital Signatures and Public-Key
Cryptosystems", February 1978. Cryptosystems", February 1978.
Appendix A. Examples Appendix A. Examples
This appendix provides examples of the actual packets sent on the This appendix provides examples of the actual packets sent on the
wire. This uses the 256-bit ECDSA private/public key pair defined in wire.
the section 8.1. of the IKEv2 ECDSA document [RFC4754].
A.1. ECDSA Example
This first example uses the 256-bit ECDSA private/public key pair
defined in the section 8.1. of the IKEv2 ECDSA document [RFC4754].
The public key is as followed: The public key is as followed:
o Algorithm : id-ecPublicKey (1.2.840.10045.2.1) o Algorithm : id-ecPublicKey (1.2.840.10045.2.1)
o Fixed curve: secp256r1 (1.2.840.10045.3.1.7) o Fixed curve: secp256r1 (1.2.840.10045.3.1.7)
o Public key x coordinate : cb28e099 9b9c7715 fd0a80d8 e47a7707 o Public key x coordinate : cb28e099 9b9c7715 fd0a80d8 e47a7707
9716cbbf 917dd72e 97566ea1 c066957c 9716cbbf 917dd72e 97566ea1 c066957c
o Public key y coordinate : 2b57c023 5fb74897 68d058ff 4911c20f o Public key y coordinate : 2b57c023 5fb74897 68d058ff 4911c20f
dbe71e36 99d91339 afbb903e e17255dc dbe71e36 99d91339 afbb903e e17255dc
skipping to change at page 8, line 27 skipping to change at page 8, line 8
00000030: 9716 cbbf 917d d72e 9756 6ea1 c066 957c 00000030: 9716 cbbf 917d d72e 9756 6ea1 c066 957c
00000040: 2b57 c023 5fb7 4897 68d0 58ff 4911 c20f 00000040: 2b57 c023 5fb7 4897 68d0 58ff 4911 c20f
00000050: dbe7 1e36 99d9 1339 afbb 903e e172 55dc 00000050: dbe7 1e36 99d9 1339 afbb 903e e172 55dc
Where the NN will be the next payload type (i.e. that value depends Where the NN will be the next payload type (i.e. that value depends
on what is the next payload after this certificate payload). on what is the next payload after this certificate payload).
Note to the RFC editor / IANA, replace the XX above with the newly Note to the RFC editor / IANA, replace the XX above with the newly
allocated Raw Public Key number, and remove this note. allocated Raw Public Key number, and remove this note.
A.2. RSA Example
This second example uses random 1024-bit RSA key.
The public key is as followed:
o Algorithm : rsaEncryption (1.2.840.113549.1.1.1)
o Modulus n (1024 bits, decimal):
1323562071162740912417075551025599045700
3972512968992059076067098474693867078469
7654066339302927451756327389839253751712
9485277759962777278073526290329821841100
9721044682579432931952695408402169276996
5181887843758615443536914372816830537901
8976615344413864477626646564638249672329
04996914356093900776754835411
o Modulus n (1024 bits, hexadecimal): bc7b4347 49c7b386 00bfa84b
44f88187 9a2dda08 d1f0145a f5806c2a ed6a6172 ff0dc3d4 cd601638
e8ca348e bdca5742 31cadc97 12e209b1 fddba58a 8c62b369 038a3d1e
aa727c1f 39ae49ed 6ebc30f8 d9b52e23 385a4019 15858c59 be72f343
fb1eb87b 16ffc5ab 0f8f8fe9 f7cb3e66 3d8fe9f9 ecfa1230 66f36835
8ceaefd3
o Exponent e (17 bits, decimal): 65537
o Exponent e (17 bits, hexadecimal): 10001
The SubjectPublicKeyInfo ASN.1 object is as follows:
0000 : SEQUENCE
0003 : SEQUENCE
0005 : OBJECT IDENTIFIER rsaEncryption (1.2.840.113549.1.1.1)
0016 : NULL
0018 : BIT STRING (141 bytes)
00000000: 0030 8189 0281 8100 bc7b 4347 49c7 b386
00000010: 00bf a84b 44f8 8187 9a2d da08 d1f0 145a
00000020: f580 6c2a ed6a 6172 ff0d c3d4 cd60 1638
00000030: e8ca 348e bdca 5742 31ca dc97 12e2 09b1
00000040: fddb a58a 8c62 b369 038a 3d1e aa72 7c1f
00000050: 39ae 49ed 6ebc 30f8 d9b5 2e23 385a 4019
00000060: 1585 8c59 be72 f343 fb1e b87b 16ff c5ab
00000070: 0f8f 8fe9 f7cb 3e66 3d8f e9f9 ecfa 1230
00000080: 66f3 6835 8cea efd3 0203 0100 01
The first byte (00) of the bit string indicates that there is no
"number of unused bits". Inside that bit string there is an ASN.1
sequence having 2 integers. The second byte (30) indicates that this
is beginning of the sequence, and then next byte (81) indicates the
length does not fit in 7-bits, but requires one byte, so the length
is in the next byte (89). Then starts the first integer with tag
(02) and length (81 81). After that we have the modulus (prefixed
with 0 so it will not be negative number). After the modulus there
is new tag (02) and length (03) of the exponent, and the last 3 bytes
are the exponent.
The final encoded SubjectPublicKeyInfo object is as follows:
00000000: 3081 9f30 0d06 092a 8648 86f7 0d01 0101
00000010: 0500 0381 8d00 3081 8902 8181 00bc 7b43
00000020: 4749 c7b3 8600 bfa8 4b44 f881 879a 2dda
00000030: 08d1 f014 5af5 806c 2aed 6a61 72ff 0dc3
00000040: d4cd 6016 38e8 ca34 8ebd ca57 4231 cadc
00000050: 9712 e209 b1fd dba5 8a8c 62b3 6903 8a3d
00000060: 1eaa 727c 1f39 ae49 ed6e bc30 f8d9 b52e
00000070: 2338 5a40 1915 858c 59be 72f3 43fb 1eb8
00000080: 7b16 ffc5 ab0f 8f8f e9f7 cb3e 663d 8fe9
00000090: f9ec fa12 3066 f368 358c eaef d302 0301
000000a0: 0001
This will result the final IKEv2 Certificate Payload to be:
00000000: NN00 00a7 XX30 819f 300d 0609 2a86 4886
00000010: f70d 0101 0105 0003 818d 0030 8189 0281
00000020: 8100 bc7b 4347 49c7 b386 00bf a84b 44f8
00000030: 8187 9a2d da08 d1f0 145a f580 6c2a ed6a
00000040: 6172 ff0d c3d4 cd60 1638 e8ca 348e bdca
00000050: 5742 31ca dc97 12e2 09b1 fddb a58a 8c62
00000060: b369 038a 3d1e aa72 7c1f 39ae 49ed 6ebc
00000070: 30f8 d9b5 2e23 385a 4019 1585 8c59 be72
00000080: f343 fb1e b87b 16ff c5ab 0f8f 8fe9 f7cb
00000090: 3e66 3d8f e9f9 ecfa 1230 66f3 6835 8cea
000000a0: efd3 0203 0100 01
Where the NN will be the next payload type (i.e. that value depends
on what is the next payload after this certificate payload).
Note to the RFC editor / IANA, replace the XX above with the newly
allocated Raw Public Key number, and remove this note.
Authors' Addresses Authors' Addresses
Tero Kivinen Tero Kivinen
INSIDE Secure INSIDE Secure
Eerikinkatu 28 Eerikinkatu 28
HELSINKI FI-00180 HELSINKI FI-00180
FI FI
Email: kivinen@iki.fi Email: kivinen@iki.fi
 End of changes. 21 change blocks. 
67 lines changed or deleted 142 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/