RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (5)

RFC 3281, "An Internet Attribute Certificate Profile for Authorization", April 2002

Note: This RFC has been obsoleted by RFC 5755

Source of RFC: pkix (sec)

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

Reported By: Stephen Farrell
Date Reported: 2003-03-07

Section 4.4.6 says:

   Clearance ::= SEQUENCE {
           policyId            [0] OBJECT IDENTIFIER,
           classList           [1] ClassList DEFAULT {unclassified},
           securityCategories  [2] SET OF SecurityCategory OPTIONAL
   }

It should say:

   Clearance ::= SEQUENCE {
           policyId            OBJECT IDENTIFIER,
           classList           ClassList DEFAULT {unclassified},
           securityCategories  SET OF SecurityCategory OPTIONAL
   }

Notes:

The differences in tagging arose due to an unnoticed technical corrigendum (TC-2) being applied to the X.501 document during preparation of RFC 3281. The X.501 format is the correct form and will be included in a future update of RFC 3281. Implementers SHOULD modify their decoding functions to accept either format and, even if claiming RFC 3281 conformance, SHOULD output the (correct) X.501 format pending the issuing of a corrected RFC at which point the incorrect RFC 3281 format will no longer be specified.

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

Reported By: Russ Housley
Date Reported: 2002-07-30

Section 7.1 says:

    The AC then contains the ciphertext inside its signed data.  The
    EnvelopedData (id-envelopedData) ContentType is used, and the
    content field will contain the EnvelopedData type.

It should say:

    Within EnvelopedData, the encapuslatedContentInfo identifies the
    content type carried withing the ciphertext.  In this case, the 
    contentType field of encapsulatedContentInfo MUST contain
    id-ct-attrCertEncAttrs, which has the following value:

       attrCertEncAttrs OBJECT IDENTIFIER ::=
             { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
	     pkcs9(9)
               id-smime(16) id-ct(1) 14 }

Notes:


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

Reported By: Kurt Zeilenga
Date Reported: 2008-07-30
Verifier Name: Tim Polk
Date Verified: 2008-11-20

Section 4.4.6 says:

            SecurityCategory ::= SEQUENCE {
                 type      [0]  IMPLICIT OBJECT IDENTIFIER,
                 value     [1]  ANY DEFINED BY type
            }

It should say:

           SecurityCategory ::= SEQUENCE {
                 type      [0]  OBJECT IDENTIFIER,
                 value     [1] EXPLICIT ANY DEFINED BY type
            }

Notes:

It appears an error in the definition of SecurityCategory was introduced when it was taken from a module with EXPLICIT TAG default into a module with IMPLICIT TAG default. In particular, the tag on the value MUST be EXPLICIT due to the ANY. Otherwise the tag of the any would replace the value's tag.

Note that extra IMPLICIT in the original text is merely extraneous (whereas the missing EXPLICIT is quite problematic).

It is also noted that clearance was NOT defined in X.501(1993), but X.500(1997). However, X.501(2005) may be the best reference for clearance.

Errata ID: 303
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Russ Housley
Date Reported: 2004-08-26

Section 4.1 says:

             AttributeCertificateInfo ::= SEQUENCE {
                  version              AttCertVersion  -- version is v2,

It should say:

             AttributeCertificateInfo ::= SEQUENCE {
                  version              AttCertVersion,  -- version is v2,

Errata ID: 710
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Gidon Moont
Date Reported: 2006-12-20
Verifier Name: Stephen Farrell
Date Verified: 2006-12-21

Section 4.3.2 says:

   Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF
   Targets".  Conforming AC issuer implementations MUST only produce one
   "Targets" element.  Confirming AC users MUST be able to accept a
   "SEQUENCE OF Targets".  If more than one Targets element is found in
   an AC, the extension MUST be treated as if all Target elements had
   been found within one Targets element.

It should say:

   Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF
   Targets".  Conforming AC issuer implementations MUST only produce one
   "Targets" element.  Conforming AC users MUST be able to accept a
   "SEQUENCE OF Targets".  If more than one Targets element is found in
   an AC, the extension MUST be treated as if all Target elements had
   been found within one Targets element.

Notes:

Confirming -> Conforming

Report New Errata



Advanced Search