Build SignedData CMS (and PKCS #7) #1051

bkstein · 2023-05-05T08:12:46Z

This branch adds a builder for SignedData PKCS #7 messages.

pkcs7/Cargo.toml

tarcieri · 2023-05-05T12:42:59Z

See also #1045 where we are discussing the future of the pkcs7 crate

baloo · 2023-05-05T18:28:22Z

pkcs7/src/builder.rs

+    /// This method returns a `ContentInfo` of type `signedData`. After this call, the builder cannot
+    /// be used any more. However, as the signature(s) are stored in the builder, the builder object
+    /// must be kept until the message is dropped.
+    pub fn build(&'s mut self) -> Result<ContentInfo<'s>> {


Just wondering, would it make sense to reuse the Builder trait from x509-cert, it's a dependency already.

This would also hold for CertificateBuilder, right?
As for the PKCS #7 builder: how would we handle multiple signers? My current solution is to add a SignerInfo including the signature with each call of SignedDataBuilder::sign(). Idea: I could possibly rename sign() to add_signer() and just add the SignerInfo without the signature. The signatures would then be calculated when building the message with SignedDataBuilder::build().

Yeah, I guess you would need an owned structure to be able to use it.

@baloo I'm currently moving my implementations to the cms crate, which uses owned types. It looks like I will be able to reuse your Builder trait for the SignerInfo objects. 🙂

bkstein · 2023-05-06T15:26:41Z

cc @carl-wallace

See also #1045 where we are discussing the future of the pkcs7 crate

Yes, I will definitely check the cms crate. But first I'd like to solve my lifetime problem.

tarcieri · 2023-05-06T15:31:11Z

@bkstein the ContentInfo type in the cms crate is owned and doesn't have a lifetime, which may make it easier to work with:

https://docs.rs/cms/0.2.1/cms/content_info/struct.ContentInfo.html

bkstein · 2023-05-07T19:01:39Z

@bkstein the ContentInfo type in the cms crate is owned and doesn't have a lifetime, which may make it easier to work with:

https://docs.rs/cms/0.2.1/cms/content_info/struct.ContentInfo.html

I had a look into the cms crate and I wonder, why the structs own their content while the pkcs7 structs borrow everything. Is there a special reason for this?
However, I think that building cmss types will be easier. I will try this tomorrow.

tarcieri · 2023-05-07T19:08:56Z

@bkstein some past discussion here: #765

We ended up moving many of the crates to use all owned types. This makes things like builders easier (as you are experiencing), but also makes one-pass deserialization from PEM possible.

The pkcs7 crate predates that decision. We should maybe consider retiring it and moving everything to cms.

bkstein · 2023-05-07T19:31:21Z

That sounds reasonable to me, too. The only difference between CMS and PKCS #7 I could find ist the coding of encapsulated content (RFC 5652, 5.2.1) and that should be manageable.

…pto-formats into bk/pkcs7-signing

tarcieri · 2023-05-13T22:08:37Z

I've officially deprecated the pkcs7 crate: #1062

@bkstein do you think you could update this PR to add this same functionality to cms instead?

bkstein · 2023-05-14T06:00:12Z

Yes, I worked exactly on this during the last week. But I'm not ready, yet.

bkstein · 2023-05-24T14:36:47Z

I moved the code from crate pkcs7 (which is deprecated) to cms. I used Builder from x509-cert to create the SignerInfo. Builder should probably be moved to a more central location in the future. I also moved der::asn1::set_of::der_sort() to make it public for some other types. The implementation is not yet usable for creating PKCS #7 messages, as enveloped_data must also be created. This will be next.

tarcieri · 2023-05-24T14:41:15Z

I also moved der::asn1::set_of::der_sort() to make it public for some other types.

Unless I'm missing something, all you're doing is calling it before SetOfVec::try_from.

That's unnecessary, as SetOfVec::try_from will call it for you: https://github.com/RustCrypto/formats/blob/8f480f5/der/src/asn1/set_of.rs#L389

bkstein · 2023-05-24T18:21:31Z

I also moved der::asn1::set_of::der_sort() to make it public for some other types.

Unless I'm missing something, all you're doing is calling it before SetOfVec::try_from.

That's unnecessary, as SetOfVec::try_from will call it for you: https://github.com/RustCrypto/formats/blob/8f480f5/der/src/asn1/set_of.rs#L389

I added try_from to some types, that are not type aliases of SetOfVec, but aggregate SetOfVec. See e.g. RelativeDistinguishedName. My intention was to re-use der_sort() there, but I forgot to replace the duplicated code. I will fix this tomorrow, if moving der_sort() is OK for you.

tarcieri · 2023-05-24T19:00:16Z

See e.g. RelativeDistinguishedName

That still looks like a newtype of SetOfVec, which you can build using impl TryFrom<Vec<AttributeTypeAndValue>> for SetOfVec<AttributeTypeAndValue>.

I still don't see why you need der_sort in the public API.

x509-cert/src/name.rs

baloo · 2023-05-24T20:55:40Z

pkcs7/src/signer_info.rs

@@ -15,12 +15,12 @@ use x509_cert::{
 /// ```text
 /// SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
 /// ```
-type SignedAttributes<'a> = SetOfVec<Attribute>;
+pub type SignedAttributes<'a> = SetOfVec<Attribute>;


I believe changes in pkcs7 need to be dropped (deprecated).

Right, I will check pkcs7 for remainders of my changes.

cms/Cargo.toml

baloo · 2023-05-24T22:08:38Z

looks great! Thank you for doing that!

bkstein · 2023-05-30T09:03:53Z

@baloo To make sure, I understand correctly: I make a PR #xyz with the x509-cert change, revert this change in the current PR #1051 and after you merged PR #xyz, you or I will patch this into the cms-and const-oid-only PR #1051?

bkstein · 2023-05-30T14:22:54Z

@baloo Split PR #1092 was merged by tarcieri. I updated this branch to the new master.

tarcieri · 2023-05-30T14:24:30Z

@bkstein can you split out the const-oid changes? That will make them a lot easier to cherry-pick in a backport

bkstein · 2023-05-30T15:04:12Z

Sure, I already expected this 🙂.

baloo · 2023-05-30T15:30:10Z

We also merged #1071 this weekend which bring back the minimal-versions checks, this is to ensure we specify the minimum required version of each dependency.
This will keep failing until we release all the dependencies you need and we bump the cms/Cargo.toml with those versions here.

cms/Cargo.toml

Co-authored-by: Arthur Gautier <superbaloo+registrations.github@superbaloo.net>

bkstein · 2023-05-31T06:12:30Z

Just realized, that resolving does not automatically accept the suggested changes. 🙄

baloo · 2023-05-31T06:29:10Z

we'll still need you to send the const-oid changes in a new PR. Once merged we'll backport that to const-oid 0.9 release you can use here.

Sorry for the extra work.

bkstein · 2023-05-31T06:55:04Z

we'll still need you to send the const-oid changes in a new PR. Once merged we'll backport that to const-oid 0.9 release you can use here.

Sorry for the extra work.

I checked the const-oid changes and found out, that all OIDs are now available with RFC 5911. Thus, we don't need a new const-oid. I will check OID usage in my branch, change the const_oid::db::rfc5652::... to the corresponding const_oid::db::rfc5911::... and remove rfc5652.txt.

bkstein · 2023-05-31T07:17:16Z

@tarcieri @baloo For the above noted reasons, I reverted the changes in const-oid, so we don't need a new version here.

const-oid/oiddbgen/Cargo.lock

baloo · 2023-05-31T16:13:06Z

(lastly, I think we'll want you to squash those commits if you could)

tarcieri · 2023-05-31T18:08:05Z

@baloo we use squash-and-merge so we don't depend on developers to squash their own PRs

carl-wallace · 2023-06-26T17:04:43Z

Sorry I missed this request somehow last month (was very busy then and just missed it). I reviewed now in prep of reviewing the EnvelopedData changes and had a couple of comments. None of this is essential (though fixing the test case probably ought be done).

SignerInfoBuilder.assemble

Ought the signer be interrogated for the SignerIdentifier (as it is for signature algorithm)? Same could apply to yielding a certificate (or certification path) that is consistent with the signer as well. This was not appropriate for a certificate builder but given this is a little higher level it may be worth another trait.
Should there be a consistency check here re: digest algorithm and signature algorithm?

SignedDataBuilder.build

Same question re: interrogating SignerInfos for digest algorithms and for consistency check where external is used.

Test comments

The test_build_signed_data uses SHA256 and SHA512 in two different SignerInfo structures but only lists SHA256 in the SignedData.digestAlgorithms field. Section 5.3 indicates hash algorithms in SignerInfo.digestAlgorithm SHOULD be in the SignedData.digestAlgorithms field.
SHA512 is inconsistent with ecdsaWithSHA256 as well (which may suggest the consistency check mentioned above is needed).
May be worth including a certs-only test (which worked fine).

Questions

Why is the signing time attribute required? This seems like something that ought be optional. RFC6019 defines an alternative signing time, for example. Some protocols (like SCEP) use a nonce. A brief survey of things that reference RFC5652 doesn't show much in the way of requiring signingTime (RFC8551 and RFC8995 intimate it is required but there's no MUST).

Nits

The word signed is presented in quotes in documentation comments, but unsigned is not. Suggest dropping the quotes.

bkstein · 2023-06-28T06:45:41Z

@carl-wallace Thanks for reviewing this.

I have some questions/remarks.

SignedDataBuilder.build/assemble

Could you give an example, how you would interrogate the info?

Test comments

If I understand CMS correctly, digest algorithm and signature algorithm are independent. The digest algorithm is used to hash the message content. The hash value is then signed together with other signed attributes. Please correct me, if I'm wrong.
A "Degenerate certificates-only CMS SignedData" test is a very good idea. 🙂

Questions

As for the signing time attribute: I think you are right and it is not required. We should probably leave it out. Also to remove unnecessary dependencies. The builder is currently not no_std and I have to admit, that I didn't have that on the agenda. Understanding RFC 5652 was hard enough.

Nits

The quotes definitely MUST be dropped.

carl-wallace · 2023-06-29T09:54:39Z

Re: interrogation, adding a trait bound to S is what I was thinking. At present it is Keypair + DynSignatureAlgorithmIdentifier. Adding some trait that returns a SignerIndentifier here (or RecipientIdentifier for EnvelopedData) might close a gap. Where S is a P12 or a hardware module, this info ought be available. I've no surveyed where this would go but it seems doable.

Re: hash algorithm and signature algorithm, you're right they can move independently, but accumulating the full list in the SignedData later is required (as a SHOULD). The consistency check suggestion is likely too much, just ignore that.

Here's a certs only test case:

#[test]
fn test_build_certs_only_signed_data() {
    // Make some content
    let content = EncapsulatedContentInfo {
        econtent_type: const_oid::db::rfc5911::ID_DATA,
        econtent: None,
    };

    let certificate_buf = include_bytes!("examples/ValidCertificatePathTest1EE.pem");
    let certificate = x509_cert::Certificate::from_pem(certificate_buf).unwrap();

    let mut builder = SignedDataBuilder::new(&content);

    let signed_data_pkcs7 = builder
        .add_certificate(CertificateChoices::Certificate(certificate))
        .expect("error adding certificate")
        .build()
        .expect("building signed data failed");
    let signed_data_pkcs7_der = signed_data_pkcs7
        .to_der()
        .expect("conversion of signed data to DER failed.");
    println!(
        "{}",
        pem_rfc7468::encode_string("PKCS7", LineEnding::LF, &signed_data_pkcs7_der)
            .expect("PEM encoding of signed data DER failed")
    );
}

Added - `SignedData` builder (RustCrypto#1051) Changed - Deprecate `pkcs7` in favor of `cms` (RustCrypto#1062) - der: add `SetOf(Vec)::insert(_ordered)`; deprecate `add` (RustCrypto#1067) - Re-enable all minimal-versions checks (RustCrypto#1071) Fixed - Don't insert signing time attribute by default (RustCrypto#1148) - Fixed encoding of `SubjectKeyIdentifier` (RustCrypto#1152)

Added - `SignedData` builder (#1051) Changed - Deprecate `pkcs7` in favor of `cms` (#1062) - der: add `SetOf(Vec)::insert(_ordered)`; deprecate `add` (#1067) - Re-enable all minimal-versions checks (#1071) Fixed - Don't insert signing time attribute by default (#1148) - Fixed encoding of `SubjectKeyIdentifier` (#1152)

bkstein added 3 commits April 14, 2023 10:46

Added SHA-3 OIDs.

97d95ea

Saving work

c664cc7

Open issue: builder lifetimes

0b2df17

tarcieri reviewed May 5, 2023

View reviewed changes

pkcs7/Cargo.toml Outdated Show resolved Hide resolved

baloo reviewed May 5, 2023

View reviewed changes

Updated rsa depenedency

e88075a

bkstein added 3 commits May 8, 2023 12:57

Merge branch 'master' into bk/pkcs7-signing

06f7b62

Merge branch 'bk/pkcs7-signing' of https://github.com/bkstein/RustCry…

dae6fe6

…pto-formats into bk/pkcs7-signing

Builder for signed data works (untested, no content creation support)

a5f6f2c

bkstein added 4 commits May 23, 2023 14:00

SignerInfoBuilder compiles.

861a680

Fixed test for cms signed data builder

5352740

Added "builder" feature for cms.

09eef80

Merge branch 'master' into bk/pkcs7-signing

bba8096

bkstein changed the title ~~PKCS #7 Signing~~ Build SignedData CMS (and PKCS #7) May 24, 2023

tarcieri reviewed May 24, 2023

View reviewed changes

x509-cert/src/name.rs Outdated Show resolved Hide resolved

baloo reviewed May 24, 2023

View reviewed changes

cms/Cargo.toml Show resolved Hide resolved

bkstein mentioned this pull request May 30, 2023

x509-cert: Added TryFrom<Vec<AttributeTypeAndValue>> for RelativeDistinguishedName #1092

Merged

Merge branch 'master' into bk/pkcs7-signing

93606f2

baloo reviewed May 30, 2023

View reviewed changes

cms/Cargo.toml Outdated Show resolved Hide resolved

baloo reviewed May 30, 2023

View reviewed changes

cms/Cargo.toml Outdated Show resolved Hide resolved

baloo reviewed May 30, 2023

View reviewed changes

cms/Cargo.toml Outdated Show resolved Hide resolved

bkstein and others added 3 commits May 31, 2023 08:10

Update cms/Cargo.toml:x509-cert version

09a2624

Co-authored-by: Arthur Gautier <superbaloo+registrations.github@superbaloo.net>

Update cms/Cargo.toml: ecdsa version

29ddb67

Co-authored-by: Arthur Gautier <superbaloo+registrations.github@superbaloo.net>

Update cms/Cargo.toml: rsa version

f7f1a6b

Co-authored-by: Arthur Gautier <superbaloo+registrations.github@superbaloo.net>

Reverted obsolete rfc5652 in const-oid.

266b517

baloo reviewed May 31, 2023

View reviewed changes

const-oid/oiddbgen/Cargo.lock Outdated Show resolved Hide resolved

Reverted changes on const-oid/oiddbgen/Cargo.lock.

e5cb963

baloo approved these changes Jun 1, 2023

View reviewed changes

tarcieri merged commit 09ed183 into RustCrypto:master Jun 1, 2023

baloo mentioned this pull request Jul 14, 2023

cms v0.2.2 #1153

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Build SignedData CMS (and PKCS #7) #1051

Build SignedData CMS (and PKCS #7) #1051

bkstein commented May 5, 2023 •

edited

Loading

tarcieri commented May 5, 2023

baloo May 5, 2023

bkstein May 6, 2023

baloo May 6, 2023

bkstein May 15, 2023

bkstein commented May 6, 2023

tarcieri commented May 6, 2023

bkstein commented May 7, 2023

tarcieri commented May 7, 2023

bkstein commented May 7, 2023

tarcieri commented May 13, 2023

bkstein commented May 14, 2023

bkstein commented May 24, 2023

tarcieri commented May 24, 2023

bkstein commented May 24, 2023

tarcieri commented May 24, 2023

baloo May 24, 2023

bkstein May 25, 2023

baloo commented May 24, 2023

bkstein commented May 30, 2023 •

edited

Loading

bkstein commented May 30, 2023

tarcieri commented May 30, 2023

bkstein commented May 30, 2023

baloo commented May 30, 2023

bkstein commented May 31, 2023 •

edited

Loading

baloo commented May 31, 2023 •

edited

Loading

bkstein commented May 31, 2023

bkstein commented May 31, 2023 •

edited

Loading

baloo commented May 31, 2023

tarcieri commented May 31, 2023

carl-wallace commented Jun 26, 2023

bkstein commented Jun 28, 2023

carl-wallace commented Jun 29, 2023

Build SignedData CMS (and PKCS #7) #1051

Build SignedData CMS (and PKCS #7) #1051

Conversation

bkstein commented May 5, 2023 • edited Loading

tarcieri commented May 5, 2023

baloo May 5, 2023

Choose a reason for hiding this comment

bkstein May 6, 2023

Choose a reason for hiding this comment

baloo May 6, 2023

Choose a reason for hiding this comment

bkstein May 15, 2023

Choose a reason for hiding this comment

bkstein commented May 6, 2023

tarcieri commented May 6, 2023

bkstein commented May 7, 2023

tarcieri commented May 7, 2023

bkstein commented May 7, 2023

tarcieri commented May 13, 2023

bkstein commented May 14, 2023

bkstein commented May 24, 2023

tarcieri commented May 24, 2023

bkstein commented May 24, 2023

tarcieri commented May 24, 2023

baloo May 24, 2023

Choose a reason for hiding this comment

bkstein May 25, 2023

Choose a reason for hiding this comment

baloo commented May 24, 2023

bkstein commented May 30, 2023 • edited Loading

bkstein commented May 30, 2023

tarcieri commented May 30, 2023

bkstein commented May 30, 2023

baloo commented May 30, 2023

bkstein commented May 31, 2023 • edited Loading

baloo commented May 31, 2023 • edited Loading

bkstein commented May 31, 2023

bkstein commented May 31, 2023 • edited Loading

baloo commented May 31, 2023

tarcieri commented May 31, 2023

carl-wallace commented Jun 26, 2023

bkstein commented Jun 28, 2023

carl-wallace commented Jun 29, 2023

bkstein commented May 5, 2023 •

edited

Loading

bkstein commented May 30, 2023 •

edited

Loading

bkstein commented May 31, 2023 •

edited

Loading

baloo commented May 31, 2023 •

edited

Loading

bkstein commented May 31, 2023 •

edited

Loading