pkcs7: support for RFC5652 5.2.1

[woodruffw]

I'm trying to parse one of Microsoft's custom PKCS#7 containers, and I'm running up against the following error:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Der(Error { kind: TagUnexpected { expected: Some(Tag(0x04: OCTET STRING)), actual: Tag(0x30: SEQUENCE) }, position: None })', examples/demo.rs:12:29
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This is happening because CMS as defined in RFC 5652 defines eContent as follows:

      eContent [0] EXPLICIT OCTET STRING OPTIONAL

whereas PKCS7 defines content (the predecessor to eContent) as follows:

      content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL

Microsoft naturally makes use of this, and chooses to make their content a SEQUENCE instead of an OCTET STRING:

SEQUENCE (2 elem)
        OBJECT IDENTIFIER 1.3.6.1.4.1.311.10.1 certTrustList (Microsoft contentType)
        [0] (1 elem)
          SEQUENCE (5 elem)

I'll work on a fix for this; just filing an issue for visibility 🙂

[woodruffw]

Whoops, forgot the link: here's where the RFC allows both forms: https://datatracker.ietf.org/doc/html/rfc5652#section-5.2.1

[smndtrl]

Do you have a specification of the content type format? I couldn't find anything with a quick google.

If so it should be easy to create a struct for it based on the der crate. Like in my gist

I don't think vendor specific content types should be supported with the pkcs7 crate. However there should be a standard way of exposing opaque content

[woodruffw]

Oh, just to clarify -- I don't expect pkcs7 to support the certTrustList format at all! That would be unreasonable 🙂

Instead, I expect it to support both PKCS#7v1.5 and IETF CMS-style SignedData contents -- that means that it should return a &[u8] or similar for PKCS#7v1.5, and an OctetString for IETF CMS. Right now it only supports the latter.

[woodruffw]

As for certTrustList itself -- I don't think there's a public specification for it. The best public resource I know is this blog post: https://unmitigatedrisk.com/?p=259

[woodruffw]

(In other words: pkcs7 shouldn't fail to parse a SignedData envelope that contains a PKCS#7v1.5-style content payload, but it shouldn't actually attempt to interpret that payload.)

[smndtrl]

@woodruffw Take a look at my PR 813. I tried to add the SignedData and use AnyRef for the content. A consumer would be able to interpret it the way they want

[carl-wallace]

So that should be an enum that supports OCTET STRING or ANY. I’m a bit surprised the ASN.1 module in 5652 does not include the PKCS 7 option as a comment. From: William Woodruff ***@***.***> Reply-To: RustCrypto/formats ***@***.***> Date: Tuesday, December 20, 2022 at 11:57 AM To: RustCrypto/formats ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [RustCrypto/formats] pkcs7: support for RFC5652 5.2.1 (Issue #812) Oh, just to clarify -- I don't expect pkcs7 to support the certTrustList format at all! That would be unreasonable 🙂 Instead, I expect it to support both PKCS#7v1.5 and IETF CMS-style SignedData contents -- that means that it should return a &[u8] or similar for PKCS#7v1.5, and an OctetString for IETF CMS. Right now it only supports the latter. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[woodruffw]

Taking a look now! It looks like you went almost exactly the same route I've been working on locally.

[woodruffw]

Addressed by #813!