Re: [pkix] [Technical Errata Reported] RFC5272 (4186)

This errata should be rejected.
When eContentType (or contentType) is id-data, eContent (or content) is an (explicitly [0] tagged) OCTET STRING. The content of the OCTET STRING is the "unstructured data".

The text in the original PKCS#7 spec (eg RFC 2315 section 8 "Data content type") was quite clear:

   8. Data content type

      The data content type is just an octet string. It shall have ASN.1
      type Data:

      Data ::= OCTET STRING

      The data content type is intended to refer to arbitrary octet
      strings, such as ASCII text files; the interpretation is left to the
      application. Such strings need not have any internal structure
      (although they may; they could even be DER encodings).

The subsequent text in CMC [RFC5272] and CMS [RFC3852, RFC5652] is less clear because it does not mention OCTET STRING when defining id-data. Sections 5.2 "EncapsulatedContentInfo" and 5.2.1 "Compatibility with PKCS#7" go to some effort to explain this.

--
James Manger

-----Original Message-----
From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of RFC Errata System
Sent: Wednesday, 19 November 2014 1:30 AM
To: jimsch@nwlink.com; mmyers@fastq.com; stephen.farrell@cs.tcd.ie; Kathleen.Moriarty.ietf@gmail.com; kent@bbn.com; stefan@aaa-sec.com
Cc: pkix@ietf.org; pierce.leonberger@baesystems.com; rfc-editor@rfc-editor.org
Subject: [pkix] [Technical Errata Reported] RFC5272 (4186)

The following errata report has been submitted for RFC5272, "Certificate Management over CMS (CMC)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5272&eid=4186

--------------------------------------
Type: Technical
Reported by: Pierce Leonberger <pierce.leonberger@baesystems.com>

Section: 3.2.1.3.2

Original Text
-------------
The Data content type allows for general transport of unstructured
   data.

   The Data content type is used by this document for:

      Holding the encrypted random value y for POP proof in the
      encrypted POP control (see Section 6.7).

Corrected Text
--------------
See Notes

Notes
-----
It's invalid for the encoding of an ANY or OpenType to have "unstructured" data.  See X.690 section 8.15:

8.15 Encoding of an open type
The value of an open type is also a value of some (other) ASN.1 type. The encoding of such a value shall be the complete encoding herein specified for the value considered as being of that other type.

Note there's similar wording in X.209 section 21 for ANY:

21 Encoding of a value of the ANY type
The encoding of an ANY type shall be the complete encoding specified in this Recommendation for the type of the value of the ANY type.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5272 (draft-ietf-pkix-2797-bis-07)
--------------------------------------
Title               : Certificate Management over CMS (CMC)
Publication Date    : June 2008
Author(s)           : J. Schaad, M. Myers
Category            : PROPOSED STANDARD
Source              : Public-Key Infrastructure (X.509)
Area                : Security
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix