Merge remote-tracking branch 'origin/asn1-fixes' into iana-text-change

Author: mcr

draft-ietf-anima-rfc8366bis.md

@@ -518,11 +518,20 @@ The CMS signing mechanism first defined in {{RFC8366}} continues to be defined h
 
 ## CMS Format Voucher Artifact {#cms-voucher}
 
-The IETF evolution of PKCS#7 is CMS {{RFC5652}}.
-A CMS-signed Voucher, the default type, contains a ContentInfo
-structure with the Voucher Data.
-An OID for JSON-encoded Voucher Data is allocated in {{iana-contenttype}}, and
-it is to be placed in the '`eContentType`' field in the ContentInfo.
+An object identifier (OID) [[ITU-T.X680] for JSON-encoded Voucher Data
+is allocated in {{iana-contenttype}}.
+This OID is placed in the 'eContentType' field in the EncapsulatedContentInfo:
+
+```
+      id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+           us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
+
+      id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
+
+      id-ct-animaJSONVoucher OBJECT IDENTIFIER ::= { id-ct 40 }
+```
+
+The use of PKCS#7 (cmsVersion=1) is deprecated by this document.
 
 The signing structure is a CMS SignedData structure, as specified by
 Section 5.1 of {{RFC5652}}, encoded using ASN.1 Distinguished Encoding
@@ -547,8 +556,7 @@ PKCS7 object (cmsVersion=1).  Intermediate systems (such as the
 Bootstrapping Remote Secure Key Infrastructures {{RFC8995}} Registrar)
 that might need to evaluate the Voucher in flight MUST be prepared for
 such an older format.
-No signaling of the format version is necessary, as the manufacturer knows the capabilities
-of the Pledge and will use an appropriate format Voucher for each
+No signaling of the format version is necessary, as the manufacturer knows the capabilities of the Pledge and will use an appropriate format Voucher for each
 Pledge.
 
 The CMS structure SHOULD also contain all of the certificates