idnits 2.17.1 draft-ietf-ipsec-openpgp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([OpenPGP], [OPENPGP], [DOI], [ISAKMP], [IKE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (23 March 2001) is 8428 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'IKE' on line 108 looks like a reference -- Missing reference section? 'ISAKMP' on line 111 looks like a reference -- Missing reference section? 'OPENPGP' on line 41 looks like a reference -- Missing reference section? 'DOI' on line 115 looks like a reference -- Missing reference section? 'OpenPGP' on line 118 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPSEC Working Group Will Price 2 INTERNET-DRAFT PGP Security 3 draft-ietf-ipsec-openpgp-01.txt 23 March 2001 5 OpenPGP Key Usage in IKE 7 Status of this Memo 9 This document is a submission to the IETF IP Security Protocol 10 (IPSEC) Working Group. Comments are solicited and should be 11 addressed to the working group mailing list (ipsec@lists.tislab.com) 12 or to the editor. 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (1999). All Rights Reserved. 37 Abstract 39 This document defines a profile for the usage of OpenPGP keys within 40 the IKE [IKE] protocol. The ISAKMP [ISAKMP] protocol on which IKE 41 is based defines an identifier for the use of OpenPGP [OPENPGP] 42 keys, but does not define how they should be used. 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119. 48 Certificate Payload Key Format 50 Whenever an OpenPGP key is sent as part of a Certificate payload, 51 the format MUST be that of the raw binary OpenPGP key. OpenPGP 52 wrappings such as ASCII Armor MUST NOT be used. 54 For RSA Signature authentication, the RSA master key is used for 55 signing. For DSS Signature authentication, the DSS master key 56 is used for signing. For Public Key Encryption modes, the 57 current valid subkey is used for encryption. If the key has no 58 subkeys, but the master key is usable for encryption such as an 59 RSA master key, the master key is used for encryption. 61 Use of Multiple Certificate Formats 63 The Certificate Request payload SHOULD be used to aid in 64 distinguishing between the types of certificate expected by the 65 remote system. Each side MAY request any type of certificate. 66 There is no requirement that both sides must request the same 67 type of certificate. It is RECOMMENDED that implementations 68 use the Certificate Request payload regularly when performing 69 certificate-based authentication in order to aid in interoperability 70 between implementations that may use multiple certificates in 71 multiple formats. 73 If a specific OpenPGP certificate authority is requested, the 74 Certificate Authority field of the Certificate Request payload 75 should contain the full OpenPGP fingerprint of the certificate 76 authority. Note that the use of the Certificate Request payload 77 remains important regardless of whether a specific certificate 78 authority is requested. This allows the remote IKE implementation 79 to know the preferred type of certificate. 81 Phase 1 Identification 83 Identification payloads in IKE Phase 1 when using certificate 84 authentication are required by the IPsec DOI [DOI] to use IDs 85 which represent the certificate. 87 Phase 1 identities when authenticating with an OpenPGP key MUST be 88 of type ID_KEY_ID and contain the full OpenPGP fingerprint of the 89 authenticating key represented as raw binary bytes of the size of 90 the key's hash algorithm output. 92 Other Payloads 94 Other payloads such as Signature, and the format of public key 95 encryption remain identical to the formats defined in IKE. 97 Infrastructure 99 Methods for retrieving up to date key revocation information, 100 establishing designated revokers, and otherwise establishing 101 key validity through the PGP web of trust or through an OpenPGP 102 meta-introducer hierarchy are already well-established. 103 Implementations of this specification MUST NOT accept revoked 104 or expired keys for authentication. 106 References 108 [IKE] D. Harkins, and D. Carrel, "The Internet Key Exchange 109 (IKE)", RFC 2409, November 1998. 111 [ISAKMP] D. Maughan, M. Schertler, M. Schneider, J. Turner, 112 "Internet Security Association and Key Management Protocol 113 (ISAKMP)", RFC 2408, November 1998 115 [DOI] D. Piper, "The Internet IP Security Domain of 116 Interpretation for ISAKMP", RFC 2407, November 1998 118 [OpenPGP] J. Callas, L. Donnerhacke, H. Finney, R. Thayer, 119 "OpenPGP Message Format", RFC 2440, November 1998. 121 Author 123 Will Price 124 PGP Security, Inc.