RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 4211, "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", September 2005

Note: This RFC has been updated by RFC 9045

Source of RFC: pkix (sec)

Errata ID: 2595
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Nikolai Malykh
Date Reported: 2010-10-29
Held for Document Update by: Sean Turner

Section 2.1 says:

   7.  Replaced Appendix A with a reference to [RFC2875].  The only
       difference is that the old text specified to use subject alt name
       instead of subject name if subject name was empty.  This is not
       possible for a CA certificate issued using PKIX.  It would
       however be useful to update RFC 2875 to have this fallback
       position.

   7.  Insert Appendix C describing why POP is necessary and what some
       of the different POP attacks are.

   8.  pop field in the CertReqMsg structure has been renamed to popo to
       avoid confusion between POP and pop.

   9.  The use of the EncryptedValue structure has been deprecated in
       favor of the EnvelopedData structure.

   10.  Add details on how private keys are to be structured when
       encrypted.

   11.  Allow for POP on key agreement algorithms other than DH.

It should say:

   7.  Replaced Appendix A with a reference to [RFC2875].  The only
       difference is that the old text specified to use subject alt name
       instead of subject name if subject name was empty.  This is not
       possible for a CA certificate issued using PKIX.  It would
       however be useful to update RFC 2875 to have this fallback
       position.

   8.  Insert Appendix C describing why POP is necessary and what some
       of the different POP attacks are.

   9.  pop field in the CertReqMsg structure has been renamed to popo to
       avoid confusion between POP and pop.

   10. The use of the EncryptedValue structure has been deprecated in
       favor of the EnvelopedData structure.

   11.  Add details on how private keys are to be structured when
       encrypted.

   12.  Allow for POP on key agreement algorithms other than DH.

Notes:

Item 7 erroneously repeated.

Report New Errata



Advanced Search