contrib/bind9/doc/rfc/rfc2538.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                        D. Eastlake
   8 Request for Comments: 2538                                           IBM
   9 Category: Standards Track                                 O. Gudmundsson
  10                                                                 TIS Labs
  11                                                               March 1999
  12
  13
  14           Storing Certificates in the Domain Name System (DNS)
  15
  16 Status of this Memo
  17
  18    This document specifies an Internet standards track protocol for the
  19    Internet community, and requests discussion and suggestions for
  20    improvements.  Please refer to the current edition of the "Internet
  21    Official Protocol Standards" (STD 1) for the standardization state
  22    and status of this protocol.  Distribution of this memo is unlimited.
  23
  24 Copyright Notice
  25
  26    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  27
  28 Abstract
  29
  30    Cryptographic public key are frequently published and their
  31    authenticity demonstrated by certificates.  A CERT resource record
  32    (RR) is defined so that such certificates and related certificate
  33    revocation lists can be stored in the Domain Name System (DNS).
  34
  35 Table of Contents
  36
  37    Abstract...................................................1
  38    1. Introduction............................................2
  39    2. The CERT Resource Record................................2
  40    2.1 Certificate Type Values................................3
  41    2.2 Text Representation of CERT RRs........................4
  42    2.3 X.509 OIDs.............................................4
  43    3. Appropriate Owner Names for CERT RRs....................5
  44    3.1 X.509 CERT RR Names....................................5
  45    3.2 PGP CERT RR Names......................................6
  46    4. Performance Considerations..............................6
  47    5. IANA Considerations.....................................7
  48    6. Security Considerations.................................7
  49    References.................................................8
  50    Authors' Addresses.........................................9
  51    Full Copyright Notice.....................................10
  52
  53
  54
  55
  56
  57
  58 Eastlake & Gudmundsson      Standards Track                     [Page 1]
  59 \f
  60 RFC 2538            Storing Certificates in the DNS           March 1999
  61
  62
  63 1. Introduction
  64
  65    Public keys are frequently published in the form of a certificate and
  66    their authenticity is commonly demonstrated by certificates and
  67    related certificate revocation lists (CRLs).  A certificate is a
  68    binding, through a cryptographic digital signature, of a public key,
  69    a validity interval and/or conditions, and identity, authorization,
  70    or other information. A certificate revocation list is a list of
  71    certificates that are revoked, and incidental information, all signed
  72    by the signer (issuer) of the revoked certificates. Examples are
  73    X.509 certificates/CRLs in the X.500 directory system or PGP
  74    certificates/revocations used by PGP software.
  75
  76    Section 2 below specifies a CERT resource record (RR) for the storage
  77    of certificates in the Domain Name System.
  78
  79    Section 3 discusses appropriate owner names for CERT RRs.
  80
  81    Sections 4, 5, and 6 below cover performance, IANA, and security
  82    considerations, respectively.
  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 2. The CERT Resource Record
  89
  90    The CERT resource record (RR) has the structure given below.  Its RR
  91    type code is 37.
  92
  93                          1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  94      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
  95     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  96     |             type              |             key tag           |
  97     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  98     |   algorithm   |                                               /
  99     +---------------+            certificate or CRL                 /
 100     /                                                               /
 101     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
 102
 103    The type field is the certificate type as define in section 2.1
 104    below.
 105
 106    The algorithm field has the same meaning as the algorithm field in
 107    KEY and SIG RRs [RFC 2535] except that a zero algorithm field
 108    indicates the algorithm is unknown to a secure DNS, which may simply
 109    be the result of the algorithm not having been standardized for
 110    secure DNS.
 111
 112
 113
 114 Eastlake & Gudmundsson      Standards Track                     [Page 2]
 115 \f
 116 RFC 2538            Storing Certificates in the DNS           March 1999
 117
 118
 119    The key tag field is the 16 bit value computed for the key embedded
 120    in the certificate as specified in the DNSSEC Standard [RFC 2535].
 121    This field is used as an efficiency measure to pick which CERT RRs
 122    may be applicable to a particular key.  The key tag can be calculated
 123    for the key in question and then only CERT RRs with the same key tag
 124    need be examined. However, the key must always be transformed to the
 125    format it would have as the public key portion of a KEY RR before the
 126    key tag is computed.  This is only possible if the key is applicable
 127    to an algorithm (and limits such as key size limits) defined for DNS
 128    security.  If it is not, the algorithm field MUST BE zero and the tag
 129    field is meaningless and SHOULD BE zero.
 130
 131 2.1 Certificate Type Values
 132
 133    The following values are defined or reserved:
 134
 135     Value  Mnemonic  Certificate Type
 136     -----  --------  ----------- ----
 137         0            reserved
 138         1   PKIX     X.509 as per PKIX
 139         2   SPKI     SPKI cert
 140         3   PGP      PGP cert
 141     4-252            available for IANA assignment
 142       253   URI      URI private
 143       254   OID      OID private
 144     255-65534        available for IANA assignment
 145     65535            reserved
 146
 147    The PKIX type is reserved to indicate an X.509 certificate conforming
 148    to the profile being defined by the IETF PKIX working group.  The
 149    certificate section will start with a one byte unsigned OID length
 150    and then an X.500 OID indicating the nature of the remainder of the
 151    certificate section (see 2.3 below).  (NOTE: X.509 certificates do
 152    not include their X.500 directory type designating OID as a prefix.)
 153
 154    The SPKI type is reserved to indicate a certificate formated as to be
 155    specified by the IETF SPKI working group.
 156
 157    The PGP type indicates a Pretty Good Privacy certificate as described
 158    in RFC 2440 and its extensions and successors.
 159
 160    The URI private type indicates a certificate format defined by an
 161    absolute URI.  The certificate portion of the CERT RR MUST begin with
 162    a null terminated URI [RFC 2396] and the data after the null is the
 163    private format certificate itself.  The URI SHOULD be such that a
 164    retrieval from it will lead to documentation on the format of the
 165    certificate.  Recognition of private certificate types need not be
 166    based on URI equality but can use various forms of pattern matching
 167
 168
 169
 170 Eastlake & Gudmundsson      Standards Track                     [Page 3]
 171 \f
 172 RFC 2538            Storing Certificates in the DNS           March 1999
 173
 174
 175    so that, for example, subtype or version information can also be
 176    encoded into the URI.
 177
 178    The OID private type indicates a private format certificate specified
 179    by a an ISO OID prefix.  The certificate section will start with a
 180    one byte unsigned OID length and then a BER encoded OID indicating
 181    the nature of the remainder of the certificate section.  This can be
 182    an X.509 certificate format or some other format.  X.509 certificates
 183    that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
 184    type, not the OID private type.  Recognition of private certificate
 185    types need not be based on OID equality but can use various forms of
 186    pattern matching such as OID prefix.
 187
 188 2.2 Text Representation of CERT RRs
 189
 190    The RDATA portion of a CERT RR has the type field as an unsigned
 191    integer or as a mnemonic symbol as listed in section 2.1 above.
 192
 193    The key tag field is represented as an unsigned integer.
 194
 195    The algorithm field is represented as an unsigned integer or a
 196    mnemonic symbol as listed in [RFC 2535].
 197
 198    The certificate / CRL portion is represented in base 64 and may be
 199    divided up into any number of white space separated substrings, down
 200    to single base 64 digits, which are concatenated to obtain the full
 201    signature.  These substrings can span lines using the standard
 202    parenthesis.
 203
 204    Note that the certificate / CRL portion may have internal sub-fields
 205    but these do not appear in the master file representation.  For
 206    example, with type 254, there will be an OID size, an OID, and then
 207    the certificate / CRL proper. But only a single logical base 64
 208    string will appear in the text representation.
 209
 210 2.3 X.509 OIDs
 211
 212    OIDs have been defined in connection with the X.500 directory for
 213    user certificates, certification authority certificates, revocations
 214    of certification authority, and revocations of user certificates.
 215    The following table lists the OIDs, their BER encoding, and their
 216    length prefixed hex format for use in CERT RRs:
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226 Eastlake & Gudmundsson      Standards Track                     [Page 4]
 227 \f
 228 RFC 2538            Storing Certificates in the DNS           March 1999
 229
 230
 231     id-at-userCertificate
 232         = { joint-iso-ccitt(2) ds(5) at(4) 36 }
 233            == 0x 03 55 04 24
 234     id-at-cACertificate
 235         = { joint-iso-ccitt(2) ds(5) at(4) 37 }
 236            == 0x 03 55 04 25
 237     id-at-authorityRevocationList
 238         = { joint-iso-ccitt(2) ds(5) at(4) 38 }
 239            == 0x 03 55 04 26
 240     id-at-certificateRevocationList
 241         = { joint-iso-ccitt(2) ds(5) at(4) 39 }
 242            == 0x 03 55 04 27
 243
 244 3. Appropriate Owner Names for CERT RRs
 245
 246    It is recommended that certificate CERT RRs be stored under a domain
 247    name related to their subject, i.e., the name of the entity intended
 248    to control the private key corresponding to the public key being
 249    certified.  It is recommended that certificate revocation list CERT
 250    RRs be stored under a domain name related to their issuer.
 251
 252    Following some of the guidelines below may result in the use in DNS
 253    names of characters that require DNS quoting which is to use a
 254    backslash followed by the octal representation of the ASCII code for
 255    the character such as \000 for NULL.
 256
 257 3.1 X.509 CERT RR Names
 258
 259    Some X.509 versions permit multiple names to be associated with
 260    subjects and issuers under "Subject Alternate Name" and "Issuer
 261    Alternate Name".  For example, x.509v3 has such Alternate Names with
 262    an ASN.1 specification as follows:
 263
 264          GeneralName ::= CHOICE {
 265             otherName                  [0] INSTANCE OF OTHER-NAME,
 266             rfc822Name                 [1] IA5String,
 267             dNSName                    [2] IA5String,
 268             x400Address                [3] EXPLICIT OR-ADDRESS.&Type,
 269             directoryName              [4] EXPLICIT Name,
 270             ediPartyName               [5] EDIPartyName,
 271             uniformResourceIdentifier  [6] IA5String,
 272             iPAddress                  [7] OCTET STRING,
 273             registeredID               [8] OBJECT IDENTIFIER
 274          }
 275
 276    The recommended locations of CERT storage are as follows, in priority
 277    order:
 278
 279
 280
 281
 282 Eastlake & Gudmundsson      Standards Track                     [Page 5]
 283 \f
 284 RFC 2538            Storing Certificates in the DNS           March 1999
 285
 286
 287    (1) If a domain name is included in the identification in the
 288        certificate or CRL, that should be used.
 289    (2) If a domain name is not included but an IP address is included,
 290        then the translation of that IP address into the appropriate
 291        inverse domain name should be used.
 292    (3) If neither of the above it used but a URI containing a domain
 293        name is present, that domain name should be used.
 294    (4) If none of the above is included but a character string name is
 295        included, then it should be treated as described for PGP names in
 296        3.2 below.
 297    (5) If none of the above apply, then the distinguished name (DN)
 298        should be mapped into a domain name as specified in RFC 2247.
 299
 300    Example 1: Assume that an X.509v3 certificate is issued to /CN=John
 301    Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative
 302    names of (a) string "John (the Man) Doe", (b) domain name john-
 303    doe.com, and (c) uri <https://www.secure.john-doe.com:8080/>.  Then
 304    the storage locations recommended, in priority order, would be
 305        (1) john-doe.com,
 306        (2) www.secure.john-doe.com, and
 307        (3) Doe.com.xy.
 308
 309    Example 2:  Assume that an X.509v3 certificate is issued to /CN=James
 310    Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names
 311    of (a) domain name widget.foo.example, (b) IPv4 address
 312    10.251.13.201, and (c) string "James Hacker
 313    <hacker@mail.widget.foo.example>".  Then the storage locations
 314    recommended, in priority order, would be
 315         (1) widget.foo.example,
 316         (2) 201.13.251.10.in-addr.arpa, and
 317         (3) hacker.mail.widget.foo.example.
 318
 319 3.2 PGP CERT RR Names
 320
 321    PGP signed keys (certificates) use a general character string User ID
 322    [RFC 2440]. However, it is recommended by PGP that such names include
 323    the RFC 822 email address of the party, as in "Leslie Example
 324    <Leslie@host.example>".  If such a format is used, the CERT should be
 325    under the standard translation of the email address into a domain
 326    name, which would be leslie.host.example in this case.  If no RFC 822
 327    name can be extracted from the string name no specific domain name is
 328    recommended.
 329
 330 4. Performance Considerations
 331
 332    Current Domain Name System (DNS) implementations are optimized for
 333    small transfers, typically not more than 512 bytes including
 334    overhead.  While larger transfers will perform correctly and work is
 335
 336
 337
 338 Eastlake & Gudmundsson      Standards Track                     [Page 6]
 339 \f
 340 RFC 2538            Storing Certificates in the DNS           March 1999
 341
 342
 343    underway to make larger transfers more efficient, it is still
 344    advisable at this time to make every reasonable effort to minimize
 345    the size of certificates stored within the DNS.  Steps that can be
 346    taken may include using the fewest possible optional or extensions
 347    fields and using short field values for variable length fields that
 348    must be included.
 349
 350 5. IANA Considerations
 351
 352    Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
 353    only be assigned by an IETF standards action [RFC 2434] (and this
 354    document assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE).
 355    Certificate types 0x0100 through 0xFEFF are assigned through IETF
 356    Consensus [RFC 2434] based on RFC documentation of the certificate
 357    type.  The availability of private types under 0x00FD and 0x00FE
 358    should satisfy most requirements for proprietary or private types.
 359
 360 6. Security Considerations
 361
 362    By definition, certificates contain their own authenticating
 363    signature.  Thus it is reasonable to store certificates in non-secure
 364    DNS zones or to retrieve certificates from DNS with DNS security
 365    checking not implemented or deferred for efficiency.  The results MAY
 366    be trusted if the certificate chain is verified back to a known
 367    trusted key and this conforms with the user's security policy.
 368
 369    Alternatively, if certificates are retrieved from a secure DNS zone
 370    with DNS security checking enabled and are verified by DNS security,
 371    the key within the retrieved certificate MAY be trusted without
 372    verifying the certificate chain if this conforms with the user's
 373    security policy.
 374
 375    CERT RRs are not used in connection with securing the DNS security
 376    additions so there are no security considerations related to CERT RRs
 377    and securing the DNS itself.
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Eastlake & Gudmundsson      Standards Track                     [Page 7]
 395 \f
 396 RFC 2538            Storing Certificates in the DNS           March 1999
 397
 398
 399 References
 400
 401    RFC 1034   Mockapetris, P., "Domain Names - Concepts and Facilities",
 402               STD 13, RFC 1034, November 1987.
 403
 404    RFC 1035   Mockapetris, P., "Domain Names - Implementation and
 405               Specifications", STD 13, RFC 1035, November 1987.
 406
 407    RFC 2119   Bradner, S., "Key words for use in RFCs to Indicate
 408               Requirement Levels", BCP 14, RFC 2119, March 1997.
 409
 410    RFC 2247   Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
 411               Sataluri, "Using Domains in LDAP/X.500 Distinguished
 412               Names", RFC 2247, January 1998.
 413
 414    RFC 2396   Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
 415               Resource Identifiers (URI): Generic Syntax", RFC 2396,
 416               August 1998.
 417
 418    RFC 2440   Callas, J., Donnerhacke, L., Finney, H. and R.  Thayer,
 419               "OpenPGP Message Format", RFC 2240, November 1998.
 420
 421    RFC 2434   Narten, T. and H. Alvestrand, "Guidelines for Writing an
 422               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
 423               October 1998.
 424
 425    RFC 2535   Eastlake, D., "Domain Name System (DNS) Security
 426               Extensions", RFC 2535, March 1999.
 427
 428    RFC 2459   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
 429               X.509 Public Key Infrastructure Certificate and CRL
 430               Profile", RFC 2459, January 1999.
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Eastlake & Gudmundsson      Standards Track                     [Page 8]
 451 \f
 452 RFC 2538            Storing Certificates in the DNS           March 1999
 453
 454
 455 Authors' Addresses
 456
 457    Donald E. Eastlake 3rd
 458    IBM
 459    65 Shindegan Hill Road
 460    RR#1
 461    Carmel, NY 10512 USA
 462
 463    Phone:   +1-914-784-7913 (w)
 464             +1-914-276-2668 (h)
 465    Fax:     +1-914-784-3833 (w-fax)
 466    EMail:   dee3@us.ibm.com
 467
 468
 469    Olafur Gudmundsson
 470    TIS Labs at Network Associates
 471    3060 Washington Rd, Route 97
 472    Glenwood MD 21738
 473
 474    Phone: +1 443-259-2389
 475    EMail: ogud@tislabs.com
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506 Eastlake & Gudmundsson      Standards Track                     [Page 9]
 507 \f
 508 RFC 2538            Storing Certificates in the DNS           March 1999
 509
 510
 511 Full Copyright Statement
 512
 513    Copyright (C) The Internet Society (1999).  All Rights Reserved.
 514
 515    This document and translations of it may be copied and furnished to
 516    others, and derivative works that comment on or otherwise explain it
 517    or assist in its implementation may be prepared, copied, published
 518    and distributed, in whole or in part, without restriction of any
 519    kind, provided that the above copyright notice and this paragraph are
 520    included on all such copies and derivative works.  However, this
 521    document itself may not be modified in any way, such as by removing
 522    the copyright notice or references to the Internet Society or other
 523    Internet organizations, except as needed for the purpose of
 524    developing Internet standards in which case the procedures for
 525    copyrights defined in the Internet Standards process must be
 526    followed, or as required to translate it into languages other than
 527    English.
 528
 529    The limited permissions granted above are perpetual and will not be
 530    revoked by the Internet Society or its successors or assigns.
 531
 532    This document and the information contained herein is provided on an
 533    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 534    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 535    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 536    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 537    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Eastlake & Gudmundsson      Standards Track                    [Page 10]
 563 \f