[nmh-workers] Additional features for S/MIME support

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[nmh-workers] Additional features for S/MIME support

Ken Hornstein-2
I was looking at what kind of things we need to generate S/MIME
messages, and ... well, we're like 60% of the way there (by that I mean
60% of the TOOLS you need are there; other tools would generate the CMS
data).  Here are a few things I think we need to make this actually
doable:

- A way to store the message headers, unmodified
- A way to generate "canonical" output (basically, with \r\n line endings).
- A way to store the top-level MIME part of a message, but also including
  any MIME headers.
- A way of storing multipart content that's not one of the subparts, but the
  actual complete multipart data.

All of these seem like they are extra stuff that should be added to mhstore.
(I thought about mhl for the message headers, but ... that wants to really
format them for humans).  Specifically, how about the following switches:

  -headers
  -canonical
  -multicontent

For the top-level MIME part, I was thinking of -part 0.  Or maybe that's not
quite right; maybe -toplevel.  Thoughts?

--Ken

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Additional features for S/MIME support

Alexander Zangerl-4
On Sat, 28 Sep 2019 19:52:58 -0400, Ken Hornstein writes:
>I was looking at what kind of things we need to generate S/MIME
>messages, and ... well, we're like 60% of the way there (by that I mean
>60% of the TOOLS you need are there;

if possible please keep that part generic enough to also work for
pgp/mime (https://tools.ietf.org/html/rfc3156). i strongly suspect that
there's fewer hoops to jump through for pgp/mime than for s/mime, so
supporting both shouldn't be onerous.

>other tools would generate the CMS data).
...
>All of these seem like they are extra stuff that should be added to mhstore.

i'm not entirely sure how you envision that split between nmh and 'other
tools' to work, because you mention both generating s/mime messages
and mhstore at the same time.

regards
az


--
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
If you can't build it with 2N3055's, it's not worth building. -- Peter Gutmann

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Additional features for S/MIME support

Ken Hornstein-2
>if possible please keep that part generic enough to also work for
>pgp/mime (https://tools.ietf.org/html/rfc3156). i strongly suspect that
>there's fewer hoops to jump through for pgp/mime than for s/mime, so
>supporting both shouldn't be onerous.

It looks like there's a fair amount of overlap.  Oh, there is one additional
bit of tooling I think is necessary: being able to specify the "raw" contents
of a multipart part when CREATING a message.

>>All of these seem like they are extra stuff that should be added to mhstore.
>
>i'm not entirely sure how you envision that split between nmh and 'other
>tools' to work, because you mention both generating s/mime messages
>and mhstore at the same time.

Let me see if I can make it clear enough.  Here's my vauge idea of
a sample script that would generate a S/MIME multipart/signed.  The
argument is a nmh draft file.  Pretend error checking is being done,
cleanup on exit, etc etc.

#!/bin/sh

mhbuild -auto -directives $1
mhstore -file $1 -headers -outfile /tmp/newdraft.$$
mhstore -file $1 -toplevel -canonical -multicontent -outfile /tmp/body-canonical.$$
mhstore -file $1 -toplevel -multicontent -outfile /tmp/body.$$
[ ... command to sign the data in /tmp/body-canonical.$$, output in
  /tmp/signdata.$$ ]
echo "------" >> /tmp/newdraft.$$
echo "#begin signed; protocol=application/pkcs7-signature; micalg=sha-256" >> /tmp/newdraft.$$
# This is a hypothetical syntax for including "pre-formed" multipart content
echo '#!<' >> /tmp/newdraft.$$
cat /tmp/body.$$ >> /tmp/newdraft.$$
echo "#application/pkcs7-signature; name=smime.p7s {attachment; filename=smime.p7s} /tmp/signdata.$$" >> /tmp/newdraft.$$
echo "#end" >> /tmp/newdraft.$$

mhbuild /tmp/newdraft.$$

exit 0

Does that make sense?  I'm not sure that's all 100% correct, but I think it
is kinda close.  What you would do with PGP/GPG is pretty close to that,
I think.

--Ken

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Additional features for S/MIME support

Alexander Zangerl-4
On Sat, 28 Sep 2019 21:24:00 -0400, Ken Hornstein writes:
>Oh, there is one additional
>bit of tooling I think is necessary: being able to specify the "raw" contents
>of a multipart part when CREATING a message.

yes.

># This is a hypothetical syntax for including "pre-formed" multipart content
>echo '#!<' >> /tmp/newdraft.$$
>cat /tmp/body.$$ >> /tmp/newdraft.$$
>echo "#application/pkcs7-signature; name=smime.p7s {attachment; filename=smime.p7s} /tmp/signdata.$$" >> /tmp/newdraft.$$
>echo "#end" >> /tmp/newdraft.$$

i think telling mhbuild to ignore directives for pre-formed stuff will need need both 'start verbatim here'
and 'stop verbatim here' markers, or you won't be able to attach the crypto signature or end the outermost
multipart... maybe something like shell here document delimiters?

>Does that make sense?

thanks, yes, that clarifies things.

>What you would do with PGP/GPG is pretty close to that, I think.

the mime types are different but that's pretty much it. (i feel confident claiming that because
i wrote an outgoing automatic signer-or-encrypter for pgp/mime a while ago; see http://snafu.priv.at/mystuff/kuvert/ for details)

regards
az


--
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Commercial televsion is like deliberately sticking hat pins through your
frontal lobes most of the time. -- Rebecca Ore

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Additional features for S/MIME support

Ken Hornstein-2
>i think telling mhbuild to ignore directives for pre-formed stuff
>will need need both 'start verbatim here' and 'stop verbatim here'
>markers, or you won't be able to attach the crypto signature or end
>the outermost multipart... maybe something like shell here document
>delimiters?

Oh, that's a good point.  It was late when I wrote that ... maybe the
simplest thing to do is make it so you could include the "verbatim"
stuff only from a file?  Anyway, I think my goal is clear ... the idea
is to make it so the nmh tools are good enough so you can manipulate an
existing draft, extract the parts you need to sign/encrypt, and then
generate the correct MIME structure.  I think we are reasonably close.

--Ken

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Additional features for S/MIME support

Michael Richardson-5
In reply to this post by Ken Hornstein-2

Ken Hornstein <[hidden email]> wrote:
    > I was looking at what kind of things we need to generate S/MIME
    > messages, and ... well, we're like 60% of the way there (by that I mean
    > 60% of the TOOLS you need are there; other tools would generate the CMS
    > data).  Here are a few things I think we need to make this actually
    > doable:

Can you explain the problem you are trying to solve?

I think it is about being able to take S/MIME messages which might be
encrypted, and then (optionally) store the unencrypted bits somewhere so that we can
manipulate them easily?
This is an especial win for signed but not encrypted messages.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [



--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Additional features for S/MIME support

Ken Hornstein-2
>Can you explain the problem you are trying to solve?

I want to be able to GENERATE a S/MIME message given a MH draft message.
There are a number of tools for platforms that can take a file and generate
CMS output (such as a signature) based on that file.  We don't quite have
the tooling to (a) get the correct output to feed into such a tool and
(b) generate things in such a way to make the correct MIME output.

>I think it is about being able to take S/MIME messages which might be
>encrypted, and then (optionally) store the unencrypted bits somewhere
>so that we can manipulate them easily?

Actually, we are actually "okay" on having some of the basic tools
necessary to get that stuff output.  I have mhstore'd a received S/MIME
message and use the right crypto tools to extract out the content.
Seamless display is a little harder, but we're not terrible at least.

--Ken

--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Additional features for S/MIME support

Michael Richardson-5
Ken Hornstein <[hidden email]> wrote:
    >> Can you explain the problem you are trying to solve?

    > I want to be able to GENERATE a S/MIME message given a MH draft message.
    > There are a number of tools for platforms that can take a file and generate
    > CMS output (such as a signature) based on that file.  We don't quite have
    > the tooling to (a) get the correct output to feed into such a tool and
    > (b) generate things in such a way to make the correct MIME output.

Oh, I see. Generate, not process.
mh-e does this for me now, but it would definitely be nice to have a cmdline
mechanism to do this.   I think that it would enable a bunch of things that
people find difficult today.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [


--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers