doc/protocol/rfc5081.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                               N. Mavrogiannopoulos
   8 Request for Comments: 5081                                   Independent
   9 Category: Experimental                                     November 2007
  10
  11
  12   Using OpenPGP Keys for Transport Layer Security (TLS) Authentication
  13
  14 Status of This Memo
  15
  16    This memo defines an Experimental Protocol for the Internet
  17    community.  It does not specify an Internet standard of any kind.
  18    Discussion and suggestions for improvement are requested.
  19    Distribution of this memo is unlimited.
  20
  21 Abstract
  22
  23    This memo proposes extensions to the Transport Layer Security (TLS)
  24    protocol to support the OpenPGP key format.  The extensions discussed
  25    here include a certificate type negotiation mechanism, and the
  26    required modifications to the TLS Handshake Protocol.
  27
  28 Table of Contents
  29
  30    1. Introduction ....................................................2
  31    2. Terminology .....................................................2
  32    3. Changes to the Handshake Message Contents .......................2
  33       3.1. Client Hello ...............................................2
  34       3.2. Server Hello ...............................................3
  35       3.3. Server Certificate .........................................3
  36       3.4. Certificate Request ........................................4
  37       3.5. Client Certificate .........................................5
  38       3.6. Other Handshake Messages ...................................5
  39    4. Security Considerations .........................................5
  40    5. IANA Considerations .............................................6
  41    6. Acknowledgements ................................................6
  42    7. References ......................................................6
  43       7.1. Normative References .......................................6
  44       7.2. Informative References .....................................7
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 Mavrogiannopoulos             Experimental                      [Page 1]
  59 \f
  60 RFC 5081                   Using OpenPGP Keys              November 2007
  61
  62
  63 1.  Introduction
  64
  65    The IETF has two sets of standards for public key certificates, one
  66    set for use of X.509 certificates [PKIX] and one for OpenPGP
  67    certificates [OpenPGP].  At the time of writing, TLS [TLS] standards
  68    are defined to use only X.509 certificates.  This document specifies
  69    a way to negotiate use of OpenPGP certificates for a TLS session, and
  70    specifies how to transport OpenPGP certificates via TLS.  The
  71    proposed extensions are backward compatible with the current TLS
  72    specification, so that existing client and server implementations
  73    that make use of X.509 certificates are not affected.
  74
  75 2.  Terminology
  76
  77    The term "OpenPGP key" is used in this document as in the OpenPGP
  78    specification [OpenPGP].  We use the term "OpenPGP certificate" to
  79    refer to OpenPGP keys that are enabled for authentication.
  80
  81    This document uses the same notation and terminology used in the TLS
  82    Protocol specification [TLS].
  83
  84    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  85    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  86    document are to be interpreted as described in [RFC2119].
  87
  88 3.  Changes to the Handshake Message Contents
  89
  90    This section describes the changes to the TLS handshake message
  91    contents when OpenPGP certificates are to be used for authentication.
  92
  93 3.1.  Client Hello
  94
  95    In order to indicate the support of multiple certificate types,
  96    clients MUST include an extension of type "cert_type" (see Section 5)
  97    to the extended client hello message.  The hello extension mechanism
  98    is described in [TLSEXT].
  99
 100    This extension carries a list of supported certificate types the
 101    client can use, sorted by client preference.  This extension MUST be
 102    omitted if the client only supports X.509 certificates.  The
 103    "extension_data" field of this extension contains a
 104    CertificateTypeExtension structure.
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114 Mavrogiannopoulos             Experimental                      [Page 2]
 115 \f
 116 RFC 5081                   Using OpenPGP Keys              November 2007
 117
 118
 119       enum { client, server } ClientOrServerExtension;
 120
 121       enum { X.509(0), OpenPGP(1), (255) } CertificateType;
 122
 123       struct {
 124          select(ClientOrServerExtension) {
 125             case client:
 126                CertificateType certificate_types<1..2^8-1>;
 127             case server:
 128                CertificateType certificate_type;
 129          }
 130       } CertificateTypeExtension;
 131
 132    No new cipher suites are required to use OpenPGP certificates.  All
 133    existing cipher suites that support a compatible, with the key, key
 134    exchange method can be used in combination with OpenPGP certificates.
 135
 136 3.2.  Server Hello
 137
 138    If the server receives a client hello that contains the "cert_type"
 139    extension and chooses a cipher suite that requires a certificate,
 140    then two outcomes are possible.  The server MUST either select a
 141    certificate type from the certificate_types field in the extended
 142    client hello or terminate the connection with a fatal alert of type
 143    "unsupported_certificate".
 144
 145    The certificate type selected by the server is encoded in a
 146    CertificateTypeExtension structure, which is included in the extended
 147    server hello message using an extension of type "cert_type".  Servers
 148    that only support X.509 certificates MAY omit including the
 149    "cert_type" extension in the extended server hello.
 150
 151 3.3.  Server Certificate
 152
 153    The contents of the certificate message sent from server to client
 154    and vice versa are determined by the negotiated certificate type and
 155    the selected cipher suite's key exchange algorithm.
 156
 157    If the OpenPGP certificate type is negotiated, then it is required to
 158    present an OpenPGP certificate in the certificate message.  The
 159    certificate must contain a public key that matches the selected key
 160    exchange algorithm, as shown below.
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170 Mavrogiannopoulos             Experimental                      [Page 3]
 171 \f
 172 RFC 5081                   Using OpenPGP Keys              November 2007
 173
 174
 175       Key Exchange Algorithm  OpenPGP Certificate Type
 176
 177       RSA                     RSA public key that can be used for
 178                               encryption.
 179
 180       DHE_DSS                 DSS public key that can be used for
 181                               authentication.
 182
 183       DHE_RSA                 RSA public key that can be used for
 184                               authentication.
 185
 186    An OpenPGP certificate appearing in the certificate message is sent
 187    using the binary OpenPGP format.  The certificate MUST contain all
 188    the elements required by Section 11.1 of [OpenPGP].
 189
 190    The option is also available to send an OpenPGP fingerprint, instead
 191    of sending the entire certificate.  The process of fingerprint
 192    generation is described in Section 12.2 of [OpenPGP].  The peer shall
 193    respond with a "certificate_unobtainable" fatal alert if the
 194    certificate with the given fingerprint cannot be found.  The
 195    "certificate_unobtainable" fatal alert is defined in Section 4 of
 196    [TLSEXT].
 197
 198       enum {
 199            cert_fingerprint (0), cert (1), (255)
 200       } OpenPGPCertDescriptorType;
 201
 202       opaque OpenPGPCertFingerprint<16..20>;
 203
 204       opaque OpenPGPCert<0..2^24-1>;
 205
 206       struct {
 207            OpenPGPCertDescriptorType descriptorType;
 208            select (descriptorType) {
 209                 case cert_fingerprint: OpenPGPCertFingerprint;
 210                 case cert: OpenPGPCert;
 211            }
 212       } Certificate;
 213
 214 3.4.  Certificate Request
 215
 216    The semantics of this message remain the same as in the TLS
 217    specification.  However, if this message is sent, and the negotiated
 218    certificate type is OpenPGP, the "certificate_authorities" list MUST
 219    be empty.
 220
 221
 222
 223
 224
 225
 226 Mavrogiannopoulos             Experimental                      [Page 4]
 227 \f
 228 RFC 5081                   Using OpenPGP Keys              November 2007
 229
 230
 231 3.5.  Client Certificate
 232
 233    This message is only sent in response to the certificate request
 234    message.  The client certificate message is sent using the same
 235    formatting as the server certificate message, and it is also required
 236    to present a certificate that matches the negotiated certificate
 237    type.  If OpenPGP certificates have been selected and no certificate
 238    is available from the client, then a certificate structure that
 239    contains an empty OpenPGPCert vector MUST be sent.  The server SHOULD
 240    respond with a "handshake_failure" fatal alert if client
 241    authentication is required.
 242
 243 3.6.  Other Handshake Messages
 244
 245    All the other handshake messages are identical to the TLS
 246    specification.
 247
 248 4.  Security Considerations
 249
 250    All security considerations discussed in [TLS], [TLSEXT], and
 251    [OpenPGP] apply to this document.  Considerations about the use of
 252    the web of trust or identity and certificate verification procedure
 253    are outside the scope of this document.  These are considered issues
 254    to be handled by the application layer protocols.
 255
 256    The protocol for certificate type negotiation is identical in
 257    operation to ciphersuite negotiation of the [TLS] specification with
 258    the addition of default values when the extension is omitted.  Since
 259    those omissions have a unique meaning and the same protection is
 260    applied to the values as with ciphersuites, it is believed that the
 261    security properties of this negotiation are the same as with
 262    ciphersuite negotiation.
 263
 264    When using OpenPGP fingerprints instead of the full certificates, the
 265    discussion in Section 6.3 of [TLSEXT] for "Client Certificate URLs"
 266    applies, especially when external servers are used to retrieve keys.
 267    However, a major difference is that although the
 268    "client_certificate_url" extension allows identifying certificates
 269    without including the certificate hashes, this is not possible in the
 270    protocol proposed here.  In this protocol, the certificates, when not
 271    sent, are always identified by their fingerprint, which serves as a
 272    cryptographic hash of the certificate (see Section 12.2 of
 273    [OpenPGP]).
 274
 275    The information that is available to participating parties and
 276    eavesdroppers (when confidentiality is not available through a
 277    previous handshake) is the number and the types of certificates they
 278    hold, plus the contents of certificates.
 279
 280
 281
 282 Mavrogiannopoulos             Experimental                      [Page 5]
 283 \f
 284 RFC 5081                   Using OpenPGP Keys              November 2007
 285
 286
 287 5.  IANA Considerations
 288
 289    This document defines a new TLS extension, "cert_type", assigned a
 290    value of 9 from the TLS ExtensionType registry defined in [TLSEXT].
 291    This value is used as the extension number for the extensions in both
 292    the client hello message and the server hello message.  The new
 293    extension type is used for certificate type negotiation.
 294
 295    The "cert_type" extension contains an 8-bit CertificateType field,
 296    for which a new registry, named "TLS Certificate Types", is
 297    established in this document, to be maintained by IANA.  The registry
 298    is segmented in the following way:
 299
 300    1.  Values 0 (X.509) and 1 (OpenPGP) are defined in this document.
 301
 302    2.  Values from 2 through 223 decimal inclusive are assigned via IETF
 303        Consensus [RFC2434].
 304
 305    3.  Values from 224 decimal through 255 decimal inclusive are
 306        reserved for Private Use [RFC2434].
 307
 308 6.  Acknowledgements
 309
 310    This document was based on earlier work made by Will Price and
 311    Michael Elkins.
 312
 313    The author wishes to thank Werner Koch, David Taylor, Timo Schulz,
 314    Pasi Eronen, Jon Callas, Stephen Kent, Robert Sparks, and Hilarie
 315    Orman for their suggestions on improving this document.
 316
 317 7.  References
 318
 319 7.1.  Normative References
 320
 321    [TLS]      Dierks, T. and E. Rescorla, "The TLS Protocol Version
 322               1.1", RFC 4346, April 2006.
 323
 324    [OpenPGP]  Callas, J., Donnerhacke, L., Finey, H., Shaw, D., and R.
 325               Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
 326
 327    [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
 328               and T. Wright, "Transport Layer Security (TLS)
 329               Extensions", RFC 4366, April 2006.
 330
 331    [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
 332               IANA Considerations Section in RFCs", RFC 2434,
 333               October 1998.
 334
 335
 336
 337
 338 Mavrogiannopoulos             Experimental                      [Page 6]
 339 \f
 340 RFC 5081                   Using OpenPGP Keys              November 2007
 341
 342
 343    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 344               Requirement Levels", RFC 2119, March 1997.
 345
 346 7.2.  Informative References
 347
 348    [PKIX]     Housley, R., Ford, W., Polk, W., and D. Solo, "Internet
 349               X.509 Public Key Infrastructure Certificate and
 350               Certificate Revocation List (CRL) Profile", RFC 3280,
 351               April 2002.
 352
 353 Author's Address
 354
 355    Nikos Mavrogiannopoulos
 356    Independent
 357    Arkadias 8
 358    Halandri, Attiki  15234
 359    Greece
 360
 361    EMail: nmav@gnutls.org
 362    URI:   http://www.gnutls.org/
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Mavrogiannopoulos             Experimental                      [Page 7]
 395 \f
 396 RFC 5081                   Using OpenPGP Keys              November 2007
 397
 398
 399 Full Copyright Statement
 400
 401    Copyright (C) The IETF Trust (2007).
 402
 403    This document is subject to the rights, licenses and restrictions
 404    contained in BCP 78, and except as set forth therein, the authors
 405    retain all their rights.
 406
 407    This document and the information contained herein are provided on an
 408    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 409    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 410    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 411    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 412    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 413    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 414
 415 Intellectual Property
 416
 417    The IETF takes no position regarding the validity or scope of any
 418    Intellectual Property Rights or other rights that might be claimed to
 419    pertain to the implementation or use of the technology described in
 420    this document or the extent to which any license under such rights
 421    might or might not be available; nor does it represent that it has
 422    made any independent effort to identify any such rights.  Information
 423    on the procedures with respect to rights in RFC documents can be
 424    found in BCP 78 and BCP 79.
 425
 426    Copies of IPR disclosures made to the IETF Secretariat and any
 427    assurances of licenses to be made available, or the result of an
 428    attempt made to obtain a general license or permission for the use of
 429    such proprietary rights by implementers or users of this
 430    specification can be obtained from the IETF on-line IPR repository at
 431    http://www.ietf.org/ipr.
 432
 433    The IETF invites any interested party to bring to its attention any
 434    copyrights, patents or patent applications, or other proprietary
 435    rights that may cover technology that may be required to implement
 436    this standard.  Please address the information to the IETF at
 437    ietf-ipr@ietf.org.
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Mavrogiannopoulos             Experimental                      [Page 8]
 451 \f