RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Reported (3)

RFC 7030, "Enrollment over Secure Transport", October 2013

Source of RFC: pkix (sec)

Errata ID: 4384

Status: Reported
Type: Technical

Reported By: Pierce Leonberger
Date Reported: 2015-06-02

Section 4.5.2 says:

CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID

AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }

Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
     type   ATTRIBUTE.&id({IOSet}),
     values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }

It should say:

AttrOrOID ::= CHOICE {
      oid OBJECT IDENTIFIER, 
      attribute Attribute{YouNeedToDefineOrReferenceAnObjectSet}
}

Notes:

1. The AttrOrOID CHOICE was started with a '(' versus a '{'.

2. Attribute{} is a parameterized type and you are missing the parameter reference within the AttrOrOID CHOICE for "attribute".

3. You need to define or reference the object set to be used in #2.

Highly recommend you create an ASN.1 Module as part of this specification. This will make it clear which specifications (and the versions there of) you are importing types from (i.e. Attribute{}) and the tagging that should be used (module level). If you need to define a new object set for #3 then this new module would be the perfect home for it.

Errata ID: 5107

Status: Reported
Type: Technical

Reported By: Sean Turner
Date Reported: 2017-09-07

Section 3.2.1 says:


It should say:

Add the following is as the last paragraph of Section 3.2.1:

  [RFC2616] indicates "HTTP does not use the
  Content-Transfer-Encoding (CTE) field of RFC 2045”; nevertheless, this
  document was published specifying the use of the
  Content-Transfer-Encoding header with a value of ‘base64' in Sections
  4.1.3, 4.3.1, 4.3.2, 4.4.2, 4.5.2, as well as in the examples in
  Appendices A.1-A.4.   As HTTP is binary-clean transport, there is no
  need to indicate this for HTTP-based protocols like EST.  EST server
  implementations SHOULD omit the Content-Transfer-Encoding header if
  they know a priori that EST clients do not rely this field.  EST
  Clients SHOULD expect that the Content-Transfer-Encoding header will
  be absent unless they have an a priori agreement with the EST server.
  The mechanism to establish this client dependency is out-of-scope.

Notes:

EST, which is an HTTP-based protocol, erroneous used CTE. This errata addresses this error.

Note that the text was reviewed by a RAI AD as well as multiple EST implementors.

Errata ID: 5108

Status: Reported
Type: Technical

Reported By: Sean Turner
Date Reported: 2017-09-07

Section 4.2.3, 4.4.2 says:

OLD from s.4.2.3:

  If the content-type is not set, the response data MUST be a plaintext
  human-readable error message containing explanatory information
  describing why the request was rejected (for example, indicating that
  CSR attributes are incomplete).

OLD from s4.4.2:

  If the content-type is not set, the response data MUST be a plaintext
  human-readable error message.

It should say:

NEW for s4.2.3:

  If the content-type is not set, the response data must be a plaintext
  human-readable error message containing explanatory information
  describing why the request was rejected (for example, indicating that
  CSR attributes are incomplete).  Servers MAY use the "text/plain”
  content-type [RFC2046] for human-readable errors.

NEW for s4.4.2:

  If the content-type is not set, the response data must be a plaintext
  human-readable error message. Servers MAY use the "text/plain”
  content-type [RFC2046] for human-readable errors.

Notes:

The current text is somewhat unclear as to what content-type needs to be used for the human-readable error. There are many human-readable content-types, but "text/plain" seems to be the most sensible.

Note that the MUST was reduced to a must because no content-type is specified.

Report New Errata



Search RFCs
Advanced Search
×