On 16/01/2019 21:25, Viktor Dukhovni wrote:
On Jan 15, 2019, at 10:29 AM, Eliot Lear <l...@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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
