Subject: RFC 4211 (CRMF) errata

From: Alfred Hönes <[email-masked]>
Date: Tue, 8 Nov 2005 18:04:27 +0100 (MEZ)

Hello,

after studying the recently published RFC 4211 authored by you
I'd like to report a couple of textual issues I found there --
some of these are even legacy issues inherited from RFC 2511.

Most issues covered below are simple typos the corrections of
which are (nearly) obvious, but a few issues require your
expertise to be corrected properly.

Therefore, I would like to obtain your comments and consent
before submitting a formal errata note to the RFC Editor.

All items below are listed in the order of their appearance
within the RFC text. To ease the recognition of the issues,
I try to point to the offending text with up/down arrows in
the form of '^^^' / 'vvv' tags contained in lines added to
the text excerpts.

(1)

Section 4.1., Signature Key POP, in the upper half of page 8,
in the explanation of the POPOSigningKey fields, says:
                                                                 vvv
     algorithmIdentifier  identifiers the signature algorithm and an
     associated parameters used to produce the POP value.

     signature  contains the POP value produce.  ...
                                              ^^
It should say:

     algorithmIdentifier  identifiers the signature algorithm and
     associated parameters used to produce the POP value.

     signature  contains the POP value produced.  ...

(2)

Section 4.2., Key Encipherment Keys, in the lower part of page 10,
in the two (doubly indented) paragraphs explaining the components
 of 'agreeMAC', uses improper names for these components -- cf.
 the ASN.1 syntax for PKMACValue at the top of page 9.
The RFC says:

        vvvvvv
        macAlg contains the algorithm identifying the method used to
        compute the MAC value.

        macValue contains the computed MAC value.
        ^^^^^^^^

It should say (I propose to make use of hierarchical subfield
notation):

        agreeMAC.algID  contains the algorithm identifying the method
        used to compute the MAC value.

        agreeMAC.value  contains the computed MAC value.

(3)

Section 4.2.1, Private Key Info Content Type, in the last paragraph
on page 11 says:

      identifier contains a name that the CA/RA can associate with the
      requestor.  This will generally be either the DN of a certificate
      or a text token passed and known to both the requestor and the
      CA/RA.  ...

It should perhaps better say:

      identifier  contains a name that the CA/RA can associate with the
      requestor.  This will generally be either the DN of a certificate
      subject or a text token passed and known to both the requestor
      ^^^^^^^^
      and the CA/RA.  ...

[Rationale: The (prospective) certificate does not have a DN,
 but its subject ...]

(4)

Section 4.4, Use of Password-Based MAC, the ASN.1 fragment at the
 bottom of page 14, says:

      PBMParameter ::= SEQUENCE {
         salt                OCTET STRING,
         owf                 AlgorithmIdentifier,
         iterationCount      INTEGER,
         mac                 AlgorithmIdentifier
         )
        ^^^

It should say:

      PBMParameter ::= SEQUENCE {
         salt                OCTET STRING,
         owf                 AlgorithmIdentifier,
         iterationCount      INTEGER,
         mac                 AlgorithmIdentifier
         }

(5)

Section 4.4, Use of Password-Based MAC, in the first text line
on page 15, says:

   The fields of PEMParameter have the following meaning:
                  ^

It should say:
                  v
   The fields of PBMParameter have the following meaning:

[Rationale: an OCR problem???]

(6)

Section 6.1, Registration Token Control, in the first paragraph
on page 19, refers to a wrong subsection; it says:

   The regToken control is used only for initialization of an end entity
   into the PKI, whereas the authenticator control (see section 7.2) can
                                                                ^
   be used for the initial as well as subsequent certification requests.

It should say:

   The regToken control is used only for initialization of an end entity
   into the PKI, whereas the authenticator control (see section 6.2) can
   be used for the initial as well as subsequent certification requests.

(7)

Section 6.3, Publication Information Control, in the upper half
of page 20, says:

   The fields of PKIPublicationInfo have the following meaning:

      action indicates whether or not the requestor wishes the CA/RA to
      publish the certificate.  The values and their means are:
                                                        ^^

It should say:

   The fields of PKIPublicationInfo have the following meaning:

      action indicates whether or not the requestor wishes the CA/RA to
      publish the certificate.  The values and their meanings are:

(8)

Section 6.3, Publication Information Control, at the bottom of
page 20, says:

  The fields of SinglePubInfo have the following meaning:

      pubMethod indicates the address type for the location at which the
      requestor desires the certificate to be placed by the CA/RA.

         dontCare indicates that the CA/RA can publish the certificate
         in whatever locations it chooses.  If dontCare is used, the
         pubInfos field MUST be omitted.
            ^^^^^

(To make the full context visible, I have shown more text than
would be necessary for the errata note.)
>From the context, I strongly suspect that the RFC text should say:

  The fields of SinglePubInfo have the following meaning:

      pubMethod indicates the address type for the location at which the
      requestor desires the certificate to be placed by the CA/RA.

         dontCare indicates that the CA/RA can publish the certificate
         in whatever locations it chooses.  If dontCare is used, the
         pubLocation field MUST be omitted.
            ^^^^^^^^

[Rationale: pubInfos is a "SEQUENCE SIZE (1..MAX) OF SinglePubInfo".
 I cannot imagine how a certain value of a SinglePubInfo instance
 subfield can ever imply a MUST to omit the full enclosing structure,
 pubInfos -- which would have removed this subfield as well :-) .
 Perhaps, the text has been cloned from the explanation of the
 'dontPublish' value of the PKIPublicationInfo.action filed given
 just below the text excerpt reproduced under item (7) above
 without fully applying the proper changes.]

(9)

Section 6.4, Archive Options Control, at the bottom of page 22,
says:

   The fields of EncryptedKey have the following meaning:

      encryptedValue is longer used.  This field has been deprecated
      along with the EncryptedValue structure.

It should say:

   The fields of EncryptedKey have the following meaning:
                        vvvv
      encryptedValue  is no longer used.  This field has been
      deprecated along with the EncryptedValue structure.

(10)

The first paragraph of section 7.1, utf8Pairs, near the bottom
of page 23, says:

   This control is used to convey text-based information from the
   Subject to an RA to a CA issuing a certificate.  The OID for this
   structure is id-regInfo-utf8Paris and has a type of UTF8String.

It should perhaps say:

   This control is used to convey text-based information from the
   Subject to an RA or to a CA issuing a certificate.  The OID for
                   ^^^^                      vvvv
   this structure is id-regInfo-utf8Paris and it has a type of
   UTF8String.

(11)

Subsequently, near the top of page 24, the same section says:

                        vvvvvvvvv
   The %xx mechanism of [RFC1738] is used to encode '?' (%3f) and '%'
   (%25) if they are not being used for their reserved purpose.  Names
   MUST NOT start with a numeric character.

It should better say:

                        vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
   The %xx mechanism of Section 2.1 of STD 66 [RFC3986] is used to
   encode '?' (%3f) and '%' (%25) if they are not being used for their
   reserved purpose.  Names MUST NOT start with a numeric character.
   
[Rationale: RFC 1738 has been obsoleted; the %-escaping method is now
 covered by the above mentioned section of that Internet Standard.]
  
Accordingly, the Reference [RFC1738] needs to be updated -- see item
(13) below.

(12)

Section 9, Security Considerations, in the first paragraph on
page 26, contains the sentence:

                                                     ...  The user can
   claim that an item was signed by the entity that generated the key as
   well as any entity that might have seen the key value during transfer
   from the generator the to EE.  ...
                      ^^^^^^
It should say:

                                                     ...  The user can
   claim that an item was signed by the entity that generated the key as
   well as any entity that might have seen the key value during transfer
   from the generator to the EE.  ...
                      ^^^^^^

(13)

Section 10.2, Informative References, on page 27, contains the
following Ref. as its final entry:

   [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
             Resource Locators (URL)", RFC 1738, December 1994.

According to item (11) above, this should be removed, and a new Ref.
[RFC3986] added -- to be taken from rfc-ref.txt .
Given the nature and context of the use of this Ref. in section 7.1
-- see item (11) above -- and the STD Status of RFC 3986, then
perhaps it is advisable to place this new Ref. into Section 10.1,
Normative References, not in section 10.2, Informative References.

(14)

Appendix A.2, in the last ASN.1 fragment on page 31, says:

   IP address (identifier "I"):
      <iname> ::= <oid>
                  ^^^^^

I'm in serious doubt whether this is correct:

I am not aware of a standard method to express an IP address
(i.e. an IPv4 address or an IPv6 address) as an OID.

If it *does* exist, indeed, a proper citation would be *very*
helpful; otherwise (as I expect) the ASN.1 should be corrected.
Perhaps, another  <ia5string>  would be appropriate, with
details left to [RFC3986].

(15)

Appendix B, near the middle of page 32, contains the following
[commented out] ASN.1, and ASN.1 comment:

  -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
         -- The contents of this type correspond to RFC 2279.
                                                        ^^^^

RFC 2279 has been obsoleted by RFC 3629 == STD 63 "long" ago.

I am aware of the fact that the UTF-8 definition in RFC 3629
syntactically and semantically by intention is a proper subset
of the definition in RFC 2279 (restriction to possible Unicode
codepoints with up to 24-bit representation).

Thus, it might be true that the reference to RFC 2279 has been
used intentionally in this ASN.1 comment, e.g., because RFC 3280
[PROFILE] (pre-3629!) referred to RFC 2279 in that context.
But, regarding the STD status of RFC 3629, a standards track RFC
like RFC 4211 should, in this case, present explicit arguments
for the deviation from STD 63. (It doesn't.)
Otherwise, the RFC should say:

  -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
         -- The contents of this type correspond to RFC 3629.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+