Internet Draft D. Venable Expires: June 9, 2005 Protegga December 2004 Cryptographic Domain Ownership Verification (CDOV) Protocol draft-venable-cdov-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. IPR Disclosure Acknowledgement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Abstract This document defines the Cryptographic Domain Ownership Verification (CDOV) protocol which may be used by Certificate Authorities (CA) to verify that a certificate belongs to the owner of the appropriate DNS domain name prior to signing. Venable Expires June 9, 2005 [Page 1] Internet-Draft CDOV Protocol December 2004 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 1. Introduction Certificate Authorities (CA) have had a difficult time verifying identities over the years. Some have used trusted third parties such as notary publics. A few have not bothered to perform any verification at all, and most are somewhere in the middle. This protocol makes use of the whois [2] database to allow CAs to verify that both a public key certificate and its associated DNS domain name are owned by the same individual or group. It is important to note that this protocol does not verify the identity of the individual requesting that the key be signed. As such, this protocol may be useful as an electronic, potentially automated alternative to a notary public to be used by a CA to verify whether a public key certificate should be signed. 1.1 Assumptions This protocol assumes that the registrars' whois servers are secure and that only authorized persons have access to the individual records. 2. Specification The CDOV protocol consists of the following steps: o A CA receives the initial request from a client containing the client's public key certificate [3] and contact information. o The CA then generates a Domain Verification Code (DVC) (see section 2.1) and provides it to the client over a secure medium. o The client places the DVC in a specified field within the domain's whois record. o After a sufficient time for the records to be updated (e.g., 24 hours), the CA performs a whois on the domain and verifies the DVC. In the event that the DVC is not yet present, the CA SHOULD check every 12 hours until such time that either the DVC is present or 48 hours have passed. Venable Expires June 9, 2005 [Page 2] Internet-Draft CDOV Protocol December 2004 o If the DVC is still not included, or is incorrect in the domain's whois record after a total of 72 hours, the CA should notify the individual making the request as well as all contacts listed in the domain's whois record. o Upon verification of the DVC, the CA signs the certificate and provides it to the client. At this point the DVC may be removed from the domain's whois record. 2.1 Domain Verification Code A Domain Verification Code (DVC) is a cryptographic hash (see section 2.1.1) of two concatenated values: a cryptographic hash of the public key certificate, and a cryptographic pseudo-random bit sequence (see section 2.1.2) of the same length. This is illustrated in the following diagram. Let PKC denote the public key certificate, and let PRNG denote the cryptographic pseudo-random bit sequence generator. Let (H) denote an operation using a cryptographic hash function. Let MD denote the result of a hashing operation, and let RS denote a pseudo-random sequence. Let DVC denote the Domain Verification Code. ---------- ---------- | PKC | | PRNG | ---------- ---------- | | (H) | |______ ______| | | ------------------------------- | MD | RS | ------------------------------- | (H) | --------------- | DVC | --------------- 2.1.1 Hash Functions Any iterative cryptographic hash function may be used with the CDOV protocol. Note: Although MD5 [4] and SHA-1 [5] are still widely used as of this writing, given their probable lifespans it would be best to use an algorithm that produces, at a minimum, a 256 bit hash such as SHA-256 [6]. Venable Expires June 9, 2005 [Page 3] Internet-Draft CDOV Protocol December 2004 2.1.2 Cryptographic Pseudo-random Sequence Generation Any cryptographic pseudo-random bit sequence generator may be used with the CDOV protocol. 3. Security Considerations The security of the CDOV protocol relies upon four factors: the security of the hash function, the security of the pseudo-random bit sequence generator, the security of the registrars' whois servers, and the integrity of the channel over which the CA provides the DVC to the client. 4. IANA Considerations This document has no actions for IANA. Venable Expires June 9, 2005 [Page 4] Internet-Draft CDOV Protocol December 2004 5. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Harrenstien, K., Stahl, M., and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985. [3] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. 6. Informative References [4] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [5] National Institute of Standards and Technology. FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. [6] NIST, "Description of SHA-256, SHA-384, and SHA-512", http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf Author's Address Questions about this memo can be directed to: David J. Venable Protegga, LLC 7600 Watson Drive Plano, TX 75025 USA Phone: +1 210 232 3269 EMail: dave.venable@protegga.com Venable Expires June 9, 2005 [Page 5] Internet-Draft CDOV Protocol December 2004 Full Copyright Statement Copyright (C) The Internet Society (2004). 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. 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. Intellectual Property 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 ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Venable Expires June 9, 2005 [Page 6]