Subject: [Anima] Common on draft-ietf-anima-voucher-06

From: Jim Schaad <[email-masked]>
Date: Tue, 14 Nov 2017 06:13:18 +0800

This document came to my attention in my role as an expert reviewer on the
S/MIME content types registry.  As it my normal procedure I read through the
document for anything that jumped out and I found one issue that I wanted to
highlight.

In section 5.4 there is a note about encoding this content type with PKCS7
vs CMS.  The problem is that this content cannot be encoded in PCKS#7
because it does not define an ASN.1 structure for the content.  There is no
correct way to encode a PKCS#7 message unless the content is an ASN.1
structure.  For id-data this was done by defining it as OCTET STRING.

In addition, even if one assigns the content type of OCTET STRING to this
content type when signing using PKCS #7 and no ASN.1 type for CMS (which is
what happens for id-data), the result is that there is absolutely no
difference between the resulting object if you encode by PKCS #7 or CMS.

This paragraph should be removed and it should talk about something else
instead.  

Jim

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Nov 2017 21:14:19 -0500

Jim Schaad <[email-masked]> wrote:
    > In addition, even if one assigns the content type of OCTET STRING to
    > this content type when signing using PKCS #7 and no ASN.1 type for CMS
    > (which is what happens for id-data), the result is that there is
    > absolutely no difference between the resulting object if you encode by
    > PKCS #7 or CMS.

Huh.  well, there is cmsVersion=1 vs cmsVersion=3, but it's true that there
are some steps in between.

We were further advised that we needed to leave RFC2315 behind in order to be
technically able to use newer algorithms.  As one advances through the
documents it seemed that we would be better off with the latest
specification.

Yet, we have push back from some quarters that have RFC2315 (cmsVersion=1)
libraries that they want to use.

    > This paragraph should be removed and it should talk about something
    > else instead.

Which paragram exactly?  Do you mean:

}   Note that Section 5.1 of [RFC5652] includes a discussion about how to
}  validate a CMS object which is really a PKCS7 object (cmsVersion=1).
}   Intermediate systems (such the BRSKI Registrar) which might need to
}   evaluate the voucher in flight MUST be prepared for such an older
}   format.  No signaling is necessary, as the Manufacturer knows the
}   capabilities of the pledge, and will use an appropriate format
}   voucher for each pledge.

in general, we include CMS format as an exemplar; many of want to move on to
JOSE and COSE signed artifacts...  Is that now clear for you?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-