errata logo graphic

Found 9 records.

Status: Verified (1)

RFC5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", May 2008

Source of RFC: pkix (sec)

Errata ID: 3579

Status: Verified
Type: Editorial

Reported By: Timothy J. Miller
Date Reported: 2013-04-03
Verifier Name: Sean Turner
Date Verified: 2013-04-05

Section 4.2.1.4 says:

certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

It should say:

CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

Notes:

ASN.1 type references must begin with an upper case character. Schema in A.2 is correct.


Status: Reported (1)

RFC5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", May 2008

Source of RFC: pkix (sec)

Errata ID: 3986

Status: Reported
Type: Technical

Reported By: Sandra Murphy
Date Reported: 2014-05-13

Section 4.1.1.3 says:

4.1.1.3.  signatureValue

   The signatureValue field contains a digital signature computed upon
   the ASN.1 DER encoded tbsCertificate.  The ASN.1 DER encoded
   tbsCertificate is used as the input to the signature function.  This
   signature value is encoded as a BIT STRING and included in the
   signature field.  The details of this process are specified for each
   of the algorithms listed in [RFC3279], [RFC4055], and [RFC4491].

It should say:

4.1.1.3.  signatureValue

   The signatureValue field contains a digital signature computed upon
   the ASN.1 DER encoded tbsCertificate.  The ASN.1 DER encoded
   tbsCertificate is used as the input to the signature function. The 
   output of the signature function is encoded as a BIT STRING and 
   included in the signatureValue field.  The details of this process 
   are specified for each of the algorithms listed in [RFC3279], 
   [RFC4055], and [RFC4491].

Notes:

The "included in the signature field" should have been "included in the signatureValue field". A field called "signature" does exist in the 5280 structure, but it is not intended to hold the value of the result of the signature function. The sentence was reworded for word flow (and to avoid using "signature value" and "signatureValue" in the same sentence).


Status: Held for Document Update (4)

RFC5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", May 2008

Source of RFC: pkix (sec)

Errata ID: 3200

Status: Held for Document Update
Type: Technical

Reported By: David Mandelberg
Date Reported: 2012-04-24
Held for Document Update by: Sean Turner

Section 4.1.2.2 says:

   The serial number MUST be a positive integer assigned by the CA to
   each certificate.  It MUST be unique for each certificate issued by a
   given CA (i.e., the issuer name and serial number identify a unique
   certificate).  CAs MUST force the serialNumber to be a non-negative
   integer.

It should say:

   The serial number MUST be a positive non-zero integer assigned by the
   CA to each certificate.  It MUST be unique for each certificate issued
   by a given CA (i.e., the issuer name and serial number identify a
   unique certificate).  CAs MUST force the serialNumber to be a positive
   integer.

Notes:

"positive" and "non-negative" do not mean the same thing. I used the third paragraph of the section as a tie-breaker to decide which of the two terms was intended:

Note: Non-conforming CAs may issue certificates with serial numbers
that are negative or zero. Certificate users SHOULD be prepared to
gracefully handle such certificates.


Errata ID: 3466

Status: Held for Document Update
Type: Editorial

Reported By: Annie Yousar
Date Reported: 2013-01-18
Held for Document Update by: Sean Turner

Section 4.2.1.6 says:

   If the subjectAltName extension is present, the sequence MUST contain
   at least one entry.  Unlike the subject field, conforming CAs MUST
|  NOT issue certificates with subjectAltNames containing empty
   GeneralName fields.  For example, an rfc822Name is represented as an
   IA5String.  While an empty string is a valid IA5String, such an
   rfc822Name is not permitted by this profile. 

It should say:

   If the subjectAltName extension is present, the sequence MUST contain
   at least one entry.  Unlike the subject field, conforming CAs MUST
|  NOT issue certificates with subjectAltName extensions containing empty
   GeneralName fields.  For example, an rfc822Name is represented as an
   IA5String.  While an empty string is a valid IA5String, such an
   rfc822Name is not permitted by this profile. 

Notes:

Certificates do not have "subjectAltNames" but only "subjectAltName extensions", which is the correct wording that is thoroughly used in the document.


Errata ID: 3674

Status: Held for Document Update
Type: Editorial

Reported By: Piyush Jain
Date Reported: 2013-06-28
Held for Document Update by: Sean Turner

Section 6.3.3 says:

If the distribution point name is present in the IDP CRL 
extension and the distribution field is present in the DP, 
then verify that one of the names in the IDP matches one 
of the names in the DP.

It should say:

If the distribution point name is present in the IDP CRL 
extension and the distributionPoint field is present in 
the DP, then verify that one of the names in the IDP 
matches one of the names in the DP.

Notes:

Original text refers to the non existent field "distribution" in DP.


Errata ID: 3754

Status: Held for Document Update
Type: Editorial

Reported By: Michal Bozon
Date Reported: 2013-10-16
Held for Document Update by: Sean Turner
Date Held: 2013-10-16

Section A.1 says:

-- Naming attributes of type X520countryName (digraph from IS 3166)

It should say:

-- Naming attributes of type X520countryName (digraph from ISO 3166)

Notes:

typo in ASN.1 comment ("IS", should be "ISO")


Status: Rejected (3)

RFC5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", May 2008

Source of RFC: pkix (sec)

Errata ID: 1774

Status: Rejected
Type: Technical

Reported By: Takashi Ito
Date Reported: 2009-05-04
Rejected by: Pasi Eronen
Date Rejected: 2009-05-27

Section 6.3 says:

   For each distribution point (DP) in the certificate CRL distribution
   points extension, for each corresponding CRL in the local CRL cache,
   while ((reasons_mask is not all-reasons) and (cert_status is
   UNREVOKED)) perform the following:

      (a)  Update the local CRL cache by obtaining a complete CRL, a
      delta CRL, or both, as required:

It should say:

   For each distribution point (DP) in the certificate CRL distribution
   points extension, for each corresponding CRL in the local CRL cache,
   while ((reasons_mask is not all-reasons) and (cert_status is
   UNREVOKED)) perform the following:

   (l)  Set the reasons_mask state variable to the union of
        its previous value and the value of the interim_reasons_mask
        state variable.

      (a)  Update the local CRL cache by obtaining a complete CRL, a
      delta CRL, or both, as required:

Notes:

This was reported in 2002 for RFC 3280, which this document obsoletes. The correction did not make it in to RFC 5280, and therefore applies to RFC 5280 as well.
--VERIFIER NOTES--
The correction already appears as step (l), the last step in the loop.


Errata ID: 3693

Status: Rejected
Type: Technical

Reported By: Florian Weimer
Date Reported: 2013-08-12
Rejected by: Sean Turner
Date Rejected: 2013-08-14

Section 4.2.1.10 says:

   DNS name restrictions are expressed as host.example.com.  Any DNS
   name that can be constructed by simply adding zero or more labels to
   the left-hand side of the name satisfies the name constraint.  For
   example, www.host.example.com would satisfy the constraint but
   host1.example.com would not.

It should say:

[Add this to the paragraph]

   If an implementation extracts DNS names from the subject
   distinguished name, DNS name restrictions MUST be applied
   to these names as well.

Notes:

When used with TLS and HTTP (according to RFC 2818), section 4.2.1.10, Name Constraints, is technically a NOP that doesn't constraint the CA that has this attribute because RFC 2818 mandates processing of the common name attribute in the subject distinguished name. Consequentially, the constraint can be bypassed by issuing a certificate without a subject alternative name. The fix is to apply the DNS name restrictions to the relevant parts of the subject distinguished name, too, as implemented here:

https://bugzilla.mozilla.org/show_bug.cgi?id=394919
--VERIFIER NOTES--
The suggested change is not editorial; it represents a significant
technical change. It also does not accurately reflect the intent of the WG.


Errata ID: 3085

Status: Rejected
Type: Editorial

Reported By: Jim Wigginton
Date Reported: 2012-01-06
Rejected by: Sean Turner
Date Rejected: 2012-01-09

Section A.1 says:

BuiltInStandardAttributes ::= SEQUENCE {
   country-name                  CountryName OPTIONAL,
   administration-domain-name    AdministrationDomainName OPTIONAL,
   network-address           [0] IMPLICIT NetworkAddress OPTIONAL,
     -- see also extended-network-address
   terminal-identifier       [1] IMPLICIT TerminalIdentifier OPTIONAL,
   private-domain-name       [2] PrivateDomainName OPTIONAL,
   organization-name         [3] IMPLICIT OrganizationName OPTIONAL,
     -- see also teletex-organization-name
   numeric-user-identifier   [4] IMPLICIT NumericUserIdentifier
                                 OPTIONAL,
   personal-name             [5] IMPLICIT PersonalName OPTIONAL,
     -- see also teletex-personal-name
   organizational-unit-names [6] IMPLICIT OrganizationalUnitNames
                                 OPTIONAL }
     -- see also teletex-organizational-unit-names

It should say:

BuiltInStandardAttributes ::= SEQUENCE {
   country-name                  CountryName OPTIONAL,
   administration-domain-name    AdministrationDomainName OPTIONAL,
   network-address           [0] IMPLICIT NetworkAddress OPTIONAL,
     -- see also extended-network-address
   terminal-identifier       [1] IMPLICIT TerminalIdentifier OPTIONAL,
   private-domain-name       [2] IMPLICIT PrivateDomainName OPTIONAL,
   organization-name         [3] IMPLICIT OrganizationName OPTIONAL,
     -- see also teletex-organization-name
   numeric-user-identifier   [4] IMPLICIT NumericUserIdentifier
                                 OPTIONAL,
   personal-name             [5] IMPLICIT PersonalName OPTIONAL,
     -- see also teletex-personal-name
   organizational-unit-names [6] IMPLICIT OrganizationalUnitNames
                                 OPTIONAL }
     -- see also teletex-organizational-unit-names

Notes:

Seems to me that private-domain-name ought to be tagged IMPLICIT just like everything else?
--VERIFIER NOTES--
PrivateDomainName (unlike the other tagged components) is an untagged
CHOICE type.


Quote from X.680:

'30.8 The IMPLICIT alternative shall not be used if the type defined
by "Type" is an untagged choice type or an untagged open type or an untagged
"DummyReference" (see ITU-T Rec. X.683 | ISO/IEC 8824-4, 8.3).'


Report New Errata