rfc2528.txt

RFC 的详细文档！

      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 Modules

4.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

   END

4.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

   END

5. 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 1999


6. 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 closed



Housley & 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: [e-mail]


   Tim Polk
   NIST
   Building 820, Room 426
   Gaithersburg, MD 20899
   USA

   EMail: [e-mail]


















Housley & Polk               Informational                      [Page 8]

RFC 2528                        PKIX KEA                      March 1999


8.  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]