RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (1)

RFC 2985, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", November 2000

Source of RFC: Legacy
Area Assignment: sec

Errata ID: 356
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Robert Moskowitz
Date Reported: 2000-12-13

The Table of Contents says:

5.6  Attributes defined in S/MIMIE .............................. 18

It should say:

5.6  Attributes defined in S/MIME ..............................  18

Status: Held for Document Update (1)

RFC 2985, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", November 2000

Source of RFC: Legacy
Area Assignment: sec

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

Reported By: Sean Leonard
Date Reported: 2013-10-27
Held for Document Update by: Sean Turner
Date Held: 2014-01-14

Section 5.2.1 says:

   emailAddress ATTRIBUTE ::= {
           WITH SYNTAX IA5String (SIZE(1..pkcs-9-ub-emailAddress))
           EQUALITY MATCHING RULE pkcs9CaseIgnoreMatch
           ID pkcs-9-at-emailAdress
   }

It should say:

   emailAddress ATTRIBUTE ::= {
           WITH SYNTAX IA5String (SIZE(1..pkcs-9-ub-emailAddress))
           EQUALITY MATCHING RULE pkcs9CaseIgnoreMatch
           ID pkcs-9-at-emailAddress
   }

Notes:

The ASN.1 is correct in Appendix A: ASN.1 Module.

spt: For those who missed it there is a "d" missing from the pkcs-9-at-emailAddress in the original text. As it's in the text and not the module, I'll mark this as hold for document as well as reclassifying it as editorial.

Status: Rejected (1)

RFC 2985, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", November 2000

Source of RFC: Legacy
Area Assignment: sec

Errata ID: 7813
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Florian Weber
Date Reported: 2024-02-18
Rejected by: Paul Wouters
Date Rejected: 2024-02-22

Section 5.2.6 says:

  5.2.6 Gender

   The gender attribute specifies the gender of the subject it is
   associated with.

   gender ATTRIBUTE ::= {
           WITH SYNTAX PrintableString (SIZE(1) ^
                       FROM ("M" | "F" | "m" | "f"))
           EQUALITY MATCHING RULE caseIgnoreMatch
           SINGLE VALUE TRUE
           ID pkcs-9-at-gender
   }

   The letter "M" (or "m") represents "male" and the letter "F" (or "f")
   represents "female".  gender attributes must be single-valued.

It should say:

  5.2.6 Gender

   The gender attribute specifies the gender of the subject it is
   associated with.

   gender ATTRIBUTE ::= {
           WITH SYNTAX IA5String (SIZE(1..pkcs-9-ub-gender))
           EQUALITY MATCHING RULE caseIgnoreMatch
           ID pkcs-9-at-gender
   }

   Attributes of this type need not be single-valued.

Notes:

The original specification restricts the gender attribute to be single-valued. The suggested correction removes the requirement for the attribute to be single-valued, allowing for greater flexibility in representing gender attributes. The suggested correction aligns with the evolving understanding and recognition of gender diversity. By updating the syntax and removing the single value requirement, the revised attribute definition can better accommodate a broader range of gender identities, ensuring inclusivity and accuracy in representing the gender of a subject. This change would introduce a new upper bound pkcs-9-ub-gender with a bound of type INTEGER ::= pkcs-9-ub-pkcs9String. If this correction is to be applied, the RFC should change or remove existing references to the incorrect gender attribute specification throughout the RFC.
--VERIFIER NOTES--
Paul Wouters(AD): While we applaud your intent for improved inclusivity, this modification cannot be done via an errata. We don't have versions of RFCs, so if we were to make a functional change than someone stating they comply to this RFC, you would not know if that includes this new feature or not. The proper way to make this change is to suggest a bis version of this RFC that would obsolete this RFC with the proposed changes. Feel free to reach out to one of the Security Area Directors if you need help on how to start this process.

Report New Errata



Advanced Search