Russ Housley <[email protected]> wrote: >>> EncapsulatedContentInfo { eContentType !!! NOT SPECIFIED YET !!! >> >> >> Will any OID do from any arc? Can I just pick a value from my >> companies' PEN, or is are there some more traditional arc managed by >> IANA that we should look to? RFC5652 does not even have an IANA >> Considerations....
> For interoperability, it needs to be assigned in the RFC. The IANA
> considerations came along later in RFC 7107; see section 3.4.
Ah. You review comments also had a link to the right registry.
I've written:
9.3. The SMI Security for S/MIME CMS Content Type Registry
This document registers an OID in the "SMI Security for S/MIME CMS
Content Type" registry (1.2.840.113549.1.9.16.1), with the value:
Decimal Description References
------- -------------------------------------- ----------
TBD1 id-ct-animaJSONVoucher [ThisRFC]
I think that we want to be specific about the format of the voucher.
If there is some desire to have a CMS signed CBOR or CMS signed XML voucher,
then I think a new eContentType should be added.
In the BRSKI document, we have registered:
Content-Type: application/pkcs7-mime; smime-type=voucher-request
and Content-Type: application/pkcs7-mime; smime-type=voucher
and now we are wondering if we should be specifying application/cms.
===
7. IANA Considerations
This document requests the following Parameter Values for the "smime-
type" Parameters:
o voucher-request
o voucher
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
