draft-ietf-dnsext-rfc2538bis-04.txt

bind 源码 最新实现 linux/unix/windows平台

   the key within the retrieved certificate MAY be trusted without
   verifying the certificate chain if this conforms with the user's
   security policy.

   If an organization chooses to issue certificates for it's employees,
   placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC)
   is in use, it is possible for someone to enumerate all employees of
   the organization.  This is usually not considered desirable, for the
   same reason enterprise phone listings are not often publicly
   published and are even mark confidential.

   When the URI type is used, it should be understood that it introduces
   an additional indirection that may allow for a new attack vector.
   One method to secure that indirection is to include a hash of the
   certificate in the URI itself.

   CERT RRs are not used by DNSSEC [9], so there are no security
   considerations related to CERT RRs and securing the DNS itself.

   If DNSSEC is used, then the non-existence of a CERT RR and,
   consequently, certificates or revocation lists can be securely
   asserted.  Without DNSSEC, this is not possible.


8.  IANA Considerations

   Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
   only be assigned by an IETF standards action [7].  This document
   assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE.  Certificate
   types 0x0100 through 0xFEFF are assigned through IETF Consensus [7]
   based on RFC documentation of the certificate type.  The availability
   of private types under 0x00FD and 0x00FE should satisfy most
   requirements for proprietary or private types.

   The CERT RR reuses the DNS Security Algorithm Numbers registry.  In
   particular, the CERT RR requires that algorithm number 0 remain
   reserved, as described in Section 2.  The IANA is directed to
   reference the CERT RR as a user of this registry and value 0, in
   particular.


9.  Changes since RFC 2538

   1.   Editorial changes to conform with new document requirements,
        including splitting reference section into two parts and
        updating the references to point at latest versions, and to add
        some additional references.




Josefsson                 Expires March 3, 2006                [Page 11]

Internet-Draft       Storing Certificates in the DNS         August 2005


   2.   Improve terminology.  For example replace "PGP" with "OpenPGP",
        to align with RFC 2440.
   3.   In section 2.1, clarify that OpenPGP public key data are binary,
        not the ASCII armored format, and reference 10.1 in RFC 2440 on
        how to deal with OpenPGP keys, and acknowledge that
        implementations may handle additional packet types.
   4.   Clarify that integers in the representation format are decimal.
   5.   Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
        terminology.  Improve reference for Key Tag Algorithm
        calculations.
   6.   Add examples that suggest use of CNAME to reduce bandwidth.
   7.   In section 3, appended the last paragraphs that discuss
        "content-based" vs "purpose-based" owner names.  Add section 3.2
        for purpose-based X.509 CERT owner names, and section 3.4 for
        purpose-based OpenPGP CERT owner names.
   8.   Added size considerations.
   9.   The SPKI types has been reserved, until RFC 2692/2693 is moved
        from the experimental status.
   10.  Added indirect types IPKIX, ISPKI, and IPGP.


Appendix A.  Copying conditions

   Regarding the portion of this document that was written by Simon
   Josefsson ("the author", for the remainder of this section), the
   author makes no guarantees and is not responsible for any damage
   resulting from its use.  The author grants irrevocable permission to
   anyone to use, modify, and distribute it in any way that does not
   diminish the rights of anyone else to use, modify, and distribute it,
   provided that redistributed derivative works do not contain
   misleading author or version information.  Derivative works need not
   be licensed under similar terms.


10.  References

10.1.  Normative References

   [1]   Mockapetris, P., "Domain names - concepts and facilities",
         STD 13, RFC 1034, November 1987.

   [2]   Mockapetris, P., "Domain names - implementation and
         specification", STD 13, RFC 1035, November 1987.

   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [4]   Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,



Josefsson                 Expires March 3, 2006                [Page 12]

Internet-Draft       Storing Certificates in the DNS         August 2005


         "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
         January 1998.

   [5]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396,
         August 1998.

   [6]   Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
         "OpenPGP Message Format", RFC 2440, November 1998.

   [7]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434,
         October 1998.

   [8]   Resnick, P., "Internet Message Format", RFC 2822, April 2001.

   [9]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "DNS Security Introduction and Requirements", RFC 4033,
         March 2005.

   [10]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "Resource Records for the DNS Security Extensions", RFC 4034,
         March 2005.

10.2.  Informative References

   [11]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
         RFC 2246, January 1999.

   [12]  Kent, S. and R. Atkinson, "Security Architecture for the
         Internet Protocol", RFC 2401, November 1998.

   [13]  Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
         and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
         September 1999.

   [14]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
         RFC 3548, July 2003.

   [15]  Richardson, M., "A Method for Storing IPsec Keying Material in
         DNS", RFC 4025, March 2005.

   [16]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
         (S/MIME) Version 3.1 Message Specification", RFC 3851,
         July 2004.






Josefsson                 Expires March 3, 2006                [Page 13]

Internet-Draft       Storing Certificates in the DNS         August 2005


Author's Address

   Simon Josefsson

   Email: [e-mail]














































Josefsson                 Expires March 3, 2006                [Page 14]

Internet-Draft       Storing Certificates in the DNS         August 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Josefsson                 Expires March 3, 2006                [Page 15]