keyAgreement;      encipherOnly; and      decipherOnly.   The encipherOnly and decipherOnly values may only be asserted if the   keyAgreement value is also asserted.  At most one of encipherOnly and   decipherOnly shall be asserted in keyUsage extension.  Generally, the   keyAgreement value is asserted without either the encipherOnly or   decipherOnly value being asserted.4. ASN.1 Modules4.1 1988 Syntax   PKIXkea88 {iso(1) identified-organization(3) dod(6)            internet(1) security(5) mechanisms(5) pkix(7)            id-mod(0) id-mod-kea-profile-88(7) }   BEGIN ::=   -- EXPORTS ALL --   -- IMPORTS NONE --Housley & Polk               Informational                      [Page 5]RFC 2528                        PKIX KEA                      March 1999      id-keyExchangeAlgorithm  OBJECT IDENTIFIER   ::=             { 2 16 840 1 101 2 1 1 22 }      KEA-Parms-Id     ::= OCTET STRING   END4.2 1993 Syntax      PKIXkea93 {iso(1) identified-organization(3) dod(6)            internet(1) security(5) mechanisms(5) pkix(7)            id-mod(0) id-mod-kea-profile-93(8) }      BEGIN ::=   -- EXPORTS ALL --   IMPORTS         ALGORITHM-ID           FROM PKIX1Explicit93 {iso(1) identified-organization(3)           dod(6) internet(1) security(5) mechanisms(5) pkix(7)           id-mod(0) id-pkix1-explicit-93(3) }     KeaPublicKey ALGORITHM-ID ::=  { OID id-keyExchangeAlgorithm                                     PARMS KEA-Parms-Id }      id-keyExchangeAlgorithm  OBJECT IDENTIFIER   ::=             { 2 16 840 1 101 2 1 1 22 }      KEA-Parms-Id     ::= OCTET STRING   END5. References   [KEA]      "Skipjack and KEA Algorithm Specification", Version 2.0,              29 May 1998. available from              http://csrc.nist.gov/encryption/skipjack-kea.htm   [SDN.701R] SDN.701, "Message Security Protocol", Revision 4.0              1996-06-07 with "Corrections to Message Security Protocol,              SDN.701, Rev 4.0, 96-06-07." August 30, 1996.   [RFC 2459] Housley, R., Ford, W., Polk, W. and D. Solo "Internet              X.509 Public Key Infrastructure: X.509 Certificate and CRL              Profile", RFC 2459, January 1999.Housley & Polk               Informational                      [Page 6]RFC 2528                        PKIX KEA                      March 19996. Security Considerations   This specification is devoted to the format and encoding of KEA keys   in X.509 certificates.  Since certificates are digitally signed, no   additional integrity service is necessary. Certificates need not be   kept secret, and unrestricted and anonymous access to certificates   and CRLs has no security implications.   However, security factors outside the scope of this specification   will affect the assurance provided to certificate users.  This   section highlights critical issues that should be considered by   implementors, administrators, and users.   The procedures performed by CAs and RAs to validate the binding of   the subject's identity of their public key greatly affect the   assurance that should be placed in the certificate.  Relying parties   may wish to review the CA's certificate practice statement.   The protection afforded private keys is a critical factor in   maintaining security.  Failure of users to protect their KEA private   keys will permit an attacker to masquerade as them, or decrypt their   personal information.   The availability and freshness of revocation information will affect   the degree of assurance that should be placed in a certificate.   While certificates expire naturally, events may occur during its   natural lifetime which negate the binding between the subject and   public key.  If revocation information is untimely or unavailable,   the assurance associated with the binding is clearly reduced.   Similarly, implementations of the Path Validation mechanism described   in section 6 that omit revocation checking provide less assurance   than those that support it.   The path validation algorithm specified in [RFC 2459] depends on the   certain knowledge of the public keys (and other information) about   one or more trusted CAs. The decision to trust a CA is an important   decision as it ultimately determines the trust afforded a   certificate.  The authenticated distribution of trusted CA public   keys (usually in the form of a "self-signed" certificate) is a   security critical out of band process that is beyond the scope of   this specification.   In addition, where a key compromise or CA failure occurs for a   trusted CA, the user will need to modify the information provided to   the path validation routine.  Selection of too many trusted CAs will   make the trusted CA information difficult to maintain.  On the other   hand, selection of only one trusted CA may limit users to a closedHousley & Polk               Informational                      [Page 7]RFC 2528                        PKIX KEA                      March 1999   community of users until a global PKI emerges.   The quality of implementations that process certificates may also   affect the degree of assurance provided.  The path validation   algorithm described in section 6 relies upon the integrity of the   trusted CA information, and especially the integrity of the public   keys associated with the trusted CAs.  By substituting public keys   for which an attacker has the private key, an attacker could trick   the user into accepting false certificates.   The binding between a key and certificate subject cannot be stronger   than the cryptographic module implementation and algorithms used to   generate the signature.7. Authors' Addresses   Russell Housley   SPYRUS   381 Elden Street   Suite 1120   Herndon, VA 20170   USA   EMail: housley@spyrus.com   Tim Polk   NIST   Building 820, Room 426   Gaithersburg, MD 20899   USA   EMail: wpolk@nist.govHousley & Polk               Informational                      [Page 8]RFC 2528                        PKIX KEA                      March 19998.  Full Copyright Statement   Copyright (C) The Internet Society (1999).  All Rights Reserved.   This document and translations of it may be copied and furnished to   others, and derivative works that comment on or otherwise explain it   or assist in its implementation may be prepared, copied, published   and distributed, in whole or in part, without restriction of any   kind, provided that the above copyright notice and this paragraph are   included on all such copies and derivative works.  However, this   document itself may not be modified in any way, such as by removing   the copyright notice or references to the Internet Society or other   Internet organizations, except as needed for the purpose of   developing Internet standards in which case the procedures for   copyrights defined in the Internet Standards process must be   followed, or as required to translate it into languages other than   English.   The limited permissions granted above are perpetual and will not be   revoked by the Internet Society or its successors or assigns.   This document and the information contained herein is provided on an   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING   TASK FORCE DISCLAIMS 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.Housley & Polk               Informational                      [Page 9]