[Tickets #13661] Re: Can't decrypt signed message stored in encrypted S/MIME message

noreply at bugs.horde.org noreply at bugs.horde.org
Tue Nov 4 12:25:55 UTC 2014


DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://bugs.horde.org/ticket/13661
------------------------------------------------------------------------------
  Ticket             | 13661
  Updated By         | software-horde at interfasys.ch
  Summary            | Can't decrypt signed message stored in encrypted
                     | S/MIME message
  Queue              | IMP
  Version            | Git master
  Type               | Bug
  State              | Unconfirmed
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


software-horde at interfasys.ch (2014-11-04 12:25) wrote:

>> I have a message which is properly encoded
>
> "properly encoded" is very questionable.
>
> First, it's using the long deprecated MIME type.
>
> Second, it does not contain the smime-data parameter.  From RFC 5751 [3.2]:
>
>    Because there are several types of application/pkcs7-mime objects, a
>    sending agent SHOULD do as much as possible to help a receiving agent
>    know about the contents of the object without forcing the receiving
>    agent to decode the ASN.1 for the object.  The Content-Type header
>    field of all application/pkcs7-mime objects SHOULD include the
>    optional "smime-type" parameter, as described in the following
>    sections.
>
> In other words... that is some garbage input.
Although I agree with you and it would be nice if all clients were  
model citizens and followed the latest version of the specs to the  
letter, the media-type is deprecated, but not illegal afaik, it's like  
using SHA1 instead of sha-1 for the micalg parameter.

RFC 5751 [3.2] is saying SHOULD not MUST

Also, RFC 5751 [5.1] contains this
Type name: application
Subtype Name: pkcs7-mime
Required Parameters: NONE
Optional Parameters: smime-type/signed-data
                      smime-type/enveloped-data
                      smime-type/compressed-data
                      smime-type/certs-only
                      name

I don't know if this encoding only comes from one family of clients of  
which very few use Horde or if it's a larger problem.





More information about the bugs mailing list