[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: application/pkcs7 handling (receive not send)

From: Ken Hornstein
Subject: Re: application/pkcs7 handling (receive not send)
Date: Wed, 21 Jul 2021 21:10:20 -0400

>Sorry to awaken an old story from 2019, but I would love to know what
>frobs to tweak, to be able to decode PKCS7 S/MIME encoded payload.
>MH-E is (I think) breaking out of the classic NMH path to do this,
>with the payload. So, I don't "see" a clean path in mhnshow
>definitions to do this.

Unfortunately, this is going to be a tough lift to make it truely
work how it should (also, there are unanswered questions).  I've done it
"by hand" using the "security" command on MacOS X.

MH's MIME handling can't really handle the case where one MIME type gets
turned into another.  E.g, application/pkcs7-mime.  Although thinking about
it maybe makes me think that it should be considered a nested type
like multipart/mixed.  But that's only a small part of the issue.

Unanswered questions are:

- How do we locate certificates/keys?  What if the keys are on a smartcard?
  I see that gpgsm can interface with a smartcard, KIND OF ... but it looks
  like it has it's own smartcard driver.  Really, in my experience, you want
  to call out to a PKCS#11 library.

- Generally to unlock a key you need a password or PIN.  How should this
  prompting be handled in NMH?  I see that gpgsm uses an agent to handle
  that, and I suppose we could do something similar.

- The tools need some more smarts; like when should it decide that it
  needs to decrypt a message?  Do you want "pick" to decode the entire
  message every time if it is just searching headers.

- We should probably create some kind of stream interface to make
  pipelines work better, but that means writing our own ASN.1 decoder.

These are all SOLVABLE.  They just require work.  And I'd like to solve
them!  But, time.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]