[openssl-users] in the department of "ain't no perfect"

[Jakob Bohm]

On 16/01/2019 21:25, Viktor Dukhovni wrote:
>> On Jan 15, 2019, at 10:29 AM, Eliot Lear <lear at ofcourseimright.com> wrote:
>>
>> I have an application that requires long-lived signatures, perhaps long
>> past the point where the signer's cert has expired.  I'd like a way to
>> extract the signature date from a CMS structure.  With all the opaque
>> structs that have been introduced in the last few releases, it's not
>> clear to me how to do that.  Any examples or guidance (other than don't
>> do that)?
> I doubt this has anything to do with opaque structures.  The real
> issue here is that IIRC CMS (previously known as PKCS7) has no
> signature date.  It just has to be signed data and a signature,
> with an X.509 certificate that has an expiration.

There is a commonly implemented extension (the signingTime
authenticated/signed attribute, RFC2985 section 5.3.3 and RFC2630 section
11.3) to store this.  Microsoft tools show this as the date of the
signature, separate from the date of any signed timestamp.

There are also at least 3 common non-authenticated/unsigned attributes
for storing time stamp results:

Option A: OID 1.2.840.113549.1.9.6: An RFC2985 section 5.3.6 (RFC2630
   section 11.4) countersignature where the countersigning certificate
   has the timestamping extended key usage and the countersignature has
   an authenticated/signed signingTime attribute. This form is used and
   expected by some Microsoft implementations, including backward
   compatible code signing.

Option B: OID 1.2.840.113549.1.9.16.2.14: As defined in RFC3161
   Appendix A.

Option C: OID 1.3.6.1.4.1.311.3.3.1: The value of this attribute
   is a SET OF TimeStampToken (where each TimeStampToken is as defined
   in RFC3161).  This form is used and expected by some Microsoft
   implementations, including current code signing features.

In all 3 forms, the timestamp signs the encryptedDigest/signature
   in the SignerInfo having the attribute.  The timestamp only
   authenticates the fact that the signature was made at or before
   the specified time, revocation information may be obtained and
   archived by the relying party (but contains its own timestamps
   and signatures).

Note: The dual naming above is because RFC2630 CMS changed the names
of various things relative to the otherwise identical definitions in
PKCS#7.  The 3 attributes are used with any version of CMS/PKCS#7,
including version 1.


>
> For long-term storage, the date of interest is NOT when the object
> was signed, but when it was received, verified and stored.  For
> that what you need is separate long-term integrity protection for
> the underlying object store, separate from the origin signatures
> on inbound objects, that need only be valid at time of import.
>
> Indeed with content that's also encrypted, you'll typically want
> to immediately decrypt it, decoupling it from a comparatively
> short-lived inbound encryption public key, and re-encrypt for
> storage under a key that is managed as part of the object store.
For encrypted e-mail there is an obvious source of the date when
the signed mail was locally stored (thus the signatures inside
must have been created before that).

This source is the reception/delivery timestamp recorded in the
mail headers by your local trusted mail server or by equivalent
code in your local POP3 client.  This of cause won't work with
an untrusted 3rd party hosted mail storage server, unless some
trust can be assigned to that server.

An important limitation is that some CAs prematurely discard
historic revocation information for mail certificates, and that
most mail clients and servers don't capture and store that
information.

> The naïve model of using the signer and recipient keys as long-term
> verification and decryption keys is deeply flawed for data retention.
> This is a bit part of the reason why end-to-end email encryption has
> negligible adoption, the storage infrastructure to make it usable was
> never built.
>

As explained above, most of that storage infrastructure is in
fact in place, but the major e-mail clients lack the code to use
it.  For example the "openssl cms" command (used by some unix mail
clients, such as Mutt) doesn't have an option to specify the "as of"
date extracted from an external trusted source.  Nor does it have
an option to input a recorded OCSP response or CRL to be validated
and used according to that "as of" date.

A much bigger hindrance is the significant difficulty of finding
3rd party e-mail CA services, as those tend to be buried in weird
corners of CA sites or overly entangled with specific services
such as citizen ID for specific countries (typically allowing only
one non-secret e-mail address per person).  To clarify, I have found
at least one useful service, but it was by no means easy.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded