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

["Leonberger, Pierce (US SSA)" <[e-mail]>]

I don't believe making the type optional will help.  Not sure what an ASN.1 toolkit is supposed to do when it encounters an OpenType with no associated type, and whatever is there would still need to be encoded.

The only solution I can think of is drop the CONTAINING or define the eContent as an OpenType.   Defining eContent as an OpenType makes handling the "Data" content type easy, but all the others are more complicated as they'll need to somehow be defined as an OCTET STRING CONTAINING.

-Pierce

________________________________________
From: Manger, James [[e-mail]]
Sent: Wednesday, November 19, 2014 7:51 PM
To: Leonberger, Pierce (US SSA); RFC Errata System; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: [pkix] [Technical Errata Reported] RFC5272 (4186)

Wow, this did get more screwed up than I appreciated.

The error is the "CONTAINING CONTENT-TYPE.Type" constraint on eContent as it is not always true. Sometime the OCTET STRING contains a BER-encoding of something, but at other times it contains unstructured content.

The other error is trying to reuse CONTENT-TYPE (which is the standard TYPE-IDENTIFIER) in EncapsulatedContentInfo. It doesn't work. We need an extra nuance to flag content that isn't an ASN.1 value.

Perhaps a solution is to redefine CONTENT-TYPE to make the type optional.

  CONTENT-TYPE ::= CLASS {
    &id    OBJECT IDENTIFIER UNIQUE,
    &Type  OPTIONAL  -- omit for non-ASN.1 data
  }
  WITH SYNTAX { [&Type] IDENTIFIED BY &id }

Then ContentInfo and EncapsulatedContentInfo become:

  ContentInfo ::= SEQUENCE {
    contentType  CONTENT-TYPE.&id({ContentSet}),
    content      [0] EXPLICIT ANY
        -- [0] EXPLICIT CONTENT-TYPE.&Type({ContentSet}{@contentType})  if Type is defined
        -- [0] EXPLICIT OCTET STRING   if Type is not defined
  }

  EncapsulatedContentInfo ::= SEQUENCE {
    eContentType  CONTENT-TYPE.&id({ContentSet}),
    eContent      [0] EXPLICIT OCTET STRING OPTIONAL
        -- (CONTAINING CONTENT-TYPE.&Type({ContentSet}{@eContentType}))  iff Type is defined
  }


RFC 6268 actually defines EncapsulatedContentInfo twice: once with and once without the "CONTAINING" constraint. See section 2 (module for RFC 3274) and section 9 (module for RFC 5652).


--
James Manger



-----Original Message-----
From: Leonberger, Pierce (US SSA) [mailto:[e-mail]]
Sent: Thursday, 20 November 2014 2:11 AM
To: Manger, James; RFC Errata System; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: [pkix] [Technical Errata Reported] RFC5272 (4186)

James,

Thanks for the reply.

I didn't fully make my argument and should have submitted this against RFC 6268 and/or 5911.

You are correct the content of "Data" Conent Type can be unstructured; however as you point out the "Data" content type is an OCTET STRING in PKCS #7.    In PKCS#7 SignedData is defined as:

9.1 SignedData type

   The signed-data content type shall have ASN.1 type SignedData:
   SignedData ::= SEQUENCE {
     version Version,
     digestAlgorithms DigestAlgorithmIdentifiers,
     contentInfo ContentInfo,
     certificates
        [0] IMPLICIT ExtendedCertificatesAndCertificates
          OPTIONAL,
     crls
       [1] IMPLICIT CertificateRevocationLists OPTIONAL,
     signerInfos SignerInfos }

   ContentInfo ::= SEQUENCE {
     contentType ContentType,
     content
       [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }

For me the problem starts way back in RFC 3369 when SignedData was redefined as:

SignedData ::= SEQUENCE {
     version CMSVersion,
     digestAlgorithms DigestAlgorithmIdentifiers,
     encapContentInfo EncapsulatedContentInfo,
     certificates [0] IMPLICIT CertificateSet OPTIONAL,
     crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
     signerInfos SignerInfos }

EncapsulatedContentInfo ::= SEQUENCE {
     eContentType ContentType,
     eContent [0] EXPLICIT OCTET STRING OPTIONAL }

In retrospect it probably would have been better to keep the ContentInfo definition from PKCS#7 but use an OpenType in place of the ANY.

In the latest syntax specified in RFC 6268 SignedData is defined as follows:

SignedData ::= SEQUENCE {
     version CMSVersion,
     digestAlgorithms SET OF DigestAlgorithmIdentifier,
     encapContentInfo EncapsulatedContentInfo,
     certificates [0] IMPLICIT CertificateSet OPTIONAL,
     crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
     signerInfos SignerInfos }

  EncapsulatedContentInfo ::= SEQUENCE {
     eContentType       CONTENT-TYPE.&id({ContentSet}),
     eContent           [0] EXPLICIT OCTET STRING
             ( CONTAINING CONTENT-TYPE.
                 &Type({ContentSet}{@eContentType})) OPTIONAL }

Within the ContentSet the "ct-Data" object is defined as (note the absence of the TYPE):

ct-Data CONTENT-TYPE ::= { IDENTIFIED BY id-data }

This is really what caused me to question the "Data" content type.  The TYPE for "ct-Data" was probably omitted knowing it would result in an extra OCTET STRING tag for eContent when the "Data" content type is present.  However, omitting the TYPE violates encoding rules for an OpenType.

There may be a clever way to define CONTENT-TYPE and use an OpenType for eContent such that each object determines whether the outer OCTET STRING is tag is to be used.   I'll give that try with our toolkit.

--
Pierce

________________________________________
From: Manger, James [[e-mail]]
Sent: Tuesday, November 18, 2014 6:07 PM
To: RFC Errata System; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; Leonberger, Pierce (US SSA)
Subject: 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:[e-mail]] On Behalf Of RFC Errata System
Sent: Wednesday, 19 November 2014 1:30 AM
To: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
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 <[e-mail]>

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
[e-mail]
https://www.ietf.org/mailman/listinfo/pkix