in the department of "ain't no perfect"

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

in the department of "ain't no perfect"

Eliot Lear
I realize things haven't been made easy to do this on purpose, and that
there's even a comment in one of the man pages to that effect, but here
goes...

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)?

TIA

Eliot



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: in the department of "ain't no perfect"

Charles Mills
Leaping into something where I really don't know what I am talking about, does not code signing do that routinely? I can install software signed with a certificate that has expired, provided it had not expired when the code was signed.

Does that help, or it is just useless chatter about something you already knew?

Charles


-----Original Message-----
From: openssl-users [mailto:[hidden email]] On Behalf Of Eliot Lear
Sent: Tuesday, January 15, 2019 7:29 AM
To: [hidden email]
Subject: [openssl-users] in the department of "ain't no perfect"

I realize things haven't been made easy to do this on purpose, and that there's even a comment in one of the man pages to that effect, but here goes...

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)?

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: in the department of "ain't no perfect"

OpenSSL - User mailing list
> 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)?


Can you list which fields you need and open an issue on github?  Yes, this would be a bug-fix because "going opaque" made some things not possible.

Thanks.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: in the department of "ain't no perfect"

Michael Wojcik
In reply to this post by Charles Mills
> From: openssl-users [mailto:[hidden email]] On Behalf Of
> Charles Mills
> Sent: Tuesday, January 15, 2019 13:50
>
> > From: openssl-users [mailto:[hidden email]] On Behalf Of
> > Eliot Lear
> > Sent: Tuesday, January 15, 2019 7:29 AM
>
> > Subject: [openssl-users] in the department of "ain't no perfect"

In the department of "how to post to a technical mailing list": Please choose a meaningful subject line. That's more useful for recipients, and much more useful for people skimming through archives, either a public one or their own collection. (As someone with a literature and rhetoric background I understand the impulse toward stylistic flair, but the subject line isn't the occasion for it. Kairos, y'know.)

> > I have an application that requires long-lived signatures, perhaps long past
> > the point where the signer's cert has expired.
>
> Leaping into something where I really don't know what I am talking about,
> does not code signing do that routinely? I can install software signed with a
> certificate that has expired, provided it had not expired when the code was
> signed.

That's because it's a timestamped signature. Timestamping involves getting a signed timestamp from a public timestamp server run by a trusted source (typically a public CA), and adding that to the document being signed. It attests that the signature was generated while the signing certificate was still valid.

There are issues with timestamped signatures. In particular, because information about certificate revocation (CRL entries and OCSP records) is generally discarded after the revoked certificate expires - to prevent CRLs and OCSP databases from growing without limit - once a certificate has expired there's no way to know whether a timestamped signature was created before the certificate was revoked. Or, for that matter, before the key was compromised (which was presumably some time before revocation).

I don't know whether Eliot has considered timestamped signatures, but generally timestamping is done by whoever generates the message. I suppose you could receive a message, and if its signature is not timestamped, you could validate the signature, then enclose the whole thing in a message of your own, which you could then timestamp and sign, attesting that it was valid when you received it. (Or you could keep that information in some other fashion, of course.)

> > I'd like a way to extract the signature date from a CMS structure.

Date or data? It's not clear what your intention is here.

> > With all the opaque structs that have
> > been introduced in the last few releases, it's not clear to me how to do
> > that.

Offhand, I don't know. But I'll note that - returning to the matter of mailing-list use - you haven't told us what version of OpenSSL you're using. Or your platform, though since this is an API question that shouldn't matter (unless someone can suggest an alternative API - which, come to think of it, someone might, if only we knew more about your platform and application).

--
Michael Wojcik
Distinguished Engineer, Micro Focus


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: in the department of "ain't no perfect"

Eliot Lear
In reply to this post by OpenSSL - User mailing list
Hi Rich and thanks for your response.  Please see below.

On 15.01.19 21:12, Salz, Rich via openssl-users wrote:
>> 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)?
>
> Can you list which fields you need and open an issue on github?  Yes, this would be a bug-fix because "going opaque" made some things not possible.


Wilco.  For the benefit of others, I'm the verifier, and at least at the
moment, no externally signed timestamp is available.  So what I want
access to is the id-signingTime attribute from the CMS structure,
preferably parsed neatly into a time_t akin to
X509_VERIFY_PARAM_get_time, but presumably coming  from CMS_ContentInfo.

I don't know if this was was ever externalized, Rich, but I'll open the
Github issue.  I recognize that examining this value is not without
risks in the general case.

Eliot

ps: sorry for the artsy subject line.





--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: in the department of "ain't no perfect"

Hubert Kario
On Tuesday, 15 January 2019 22:38:32 CET Eliot Lear wrote:

> Hi Rich and thanks for your response.  Please see below.
>
> On 15.01.19 21:12, Salz, Rich via openssl-users wrote:
> >> 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)?>
> > Can you list which fields you need and open an issue on github?  Yes, this
> > would be a bug-fix because "going opaque" made some things not possible.
> Wilco.  For the benefit of others, I'm the verifier, and at least at the
> moment, no externally signed timestamp is available.  So what I want
> access to is the id-signingTime attribute from the CMS structure,
> preferably parsed neatly into a time_t akin to
> X509_VERIFY_PARAM_get_time, but presumably coming  from CMS_ContentInfo.
>
> I don't know if this was was ever externalized, Rich, but I'll open the
> Github issue.  I recognize that examining this value is not without
> risks in the general case.
for one, if the attacker can forge a signature, he or she can easily forge
that attribute too – it's not something you can depend on

For maintaining signatures that need to be valid long into the future
standards like CAdES should be used. They keep time of signing in timestamps
signed by trusted time-stamping authorities, along with the rest of revocation
data necessary to verify the original signature.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: in the department of "ain't no perfect"

Eliot Lear
Hi Hubert

On 16.01.19 12:27, Hubert Kario wrote:
> For maintaining signatures that need to be valid long into the future
> standards like CAdES should be used. They keep time of signing in timestamps
> signed by trusted time-stamping authorities, along with the rest of revocation
> data necessary to verify the original signature.


Understood.  At this point in the maturity cycle of the technology,
we're just not there yet.  My choices are, have people ignore invalid
signatures in their entirety or provide something more nuanced for now.

Eliot



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: in the department of "ain't no perfect"

Hubert Kario
On Wednesday, 16 January 2019 13:22:53 CET Eliot Lear wrote:

> Hi Hubert
>
> On 16.01.19 12:27, Hubert Kario wrote:
> > For maintaining signatures that need to be valid long into the future
> > standards like CAdES should be used. They keep time of signing in
> > timestamps signed by trusted time-stamping authorities, along with the
> > rest of revocation data necessary to verify the original signature.
>
> Understood.  At this point in the maturity cycle of the technology,
> we're just not there yet.  My choices are, have people ignore invalid
> signatures in their entirety or provide something more nuanced for now.
you don't have to start with implementing the full CAdES-LTA, you can start
with just adding support for timestamping, the CAdES-T

using time from the signature to verify it is as good as ignoring the
certificate expiration date - if you need to make the signatures verifiable
now, do that, not use the false sense of security of using easily fakeable
date
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: in the department of "ain't no perfect"

Charles Mills
Temporary solutions that "work" tend to become permanent solutions.

That's how products end up shipping with hard-coded admin passwords or similar back doors.

Charles


-----Original Message-----
From: openssl-users [mailto:[hidden email]] On Behalf Of Hubert Kario
Sent: Wednesday, January 16, 2019 6:47 AM
To: Eliot Lear
Cc: [hidden email]
Subject: Re: [openssl-users] in the department of "ain't no perfect"

On Wednesday, 16 January 2019 13:22:53 CET Eliot Lear wrote:

> Hi Hubert
>
> On 16.01.19 12:27, Hubert Kario wrote:
> > For maintaining signatures that need to be valid long into the
> > future standards like CAdES should be used. They keep time of
> > signing in timestamps signed by trusted time-stamping authorities,
> > along with the rest of revocation data necessary to verify the original signature.
>
> Understood.  At this point in the maturity cycle of the technology,
> we're just not there yet.  My choices are, have people ignore invalid
> signatures in their entirety or provide something more nuanced for now.

you don't have to start with implementing the full CAdES-LTA, you can start with just adding support for timestamping, the CAdES-T

using time from the signature to verify it is as good as ignoring the certificate expiration date - if you need to make the signatures verifiable now, do that, not use the false sense of security of using easily fakeable date

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: in the department of "ain't no perfect"

Viktor Dukhovni
In reply to this post by Eliot Lear
> On Jan 15, 2019, at 10:29 AM, Eliot Lear <[hidden email]> 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.

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.

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.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: in the department of "ain't no perfect"

Hubert Kario
On Wednesday, 16 January 2019 21:25:32 CET Viktor Dukhovni wrote:

> > On Jan 15, 2019, at 10:29 AM, Eliot Lear <[hidden email]> 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)?
>
> 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.
alternatively, you can save all the certificates and revocation data, bind it
to the original signature using a timestamp from a TSA and store that (that's
necessary if you want to be able to prove to some 3rd party that you received
a correctly signed document/message at that time)

but that is very close to reimplementing CAdES, or related standards, and is
far from simple (for one, requires adding, regularly, new timestamps to extend
validity of the original signature and subsequent timestamps)

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: in the department of "ain't no perfect"

Eliot Lear

On 17.01.19 17:29, Hubert Kario wrote:

>
> alternatively, you can save all the certificates and revocation data, bind it
> to the original signature using a timestamp from a TSA and store that (that's
> necessary if you want to be able to prove to some 3rd party that you received
> a correctly signed document/message at that time)
>
> but that is very close to reimplementing CAdES, or related standards, and is
> far from simple (for one, requires adding, regularly, new timestamps to extend
> validity of the original signature and subsequent timestamps)
>
Right.  There are a lot of trust challenges around the timestamp. 
Because there are multiple non-cooperating entities involved, the signer
is not in a position to predict who the recipients will trust, and the
recipients may be retrieving the information later.  This is not a
simple matter.

What's more, we're not in a position to provide meaningful programmatic
diagnostic info in this case because CMS is calling X.509 codes, and so
ERR_get_err has a little issue when multiple libraries are in play.  And
while nobody likes to hear, “I'll just bypass this one thing”, as a
matter of practicality we want to provide the application user (in this
case an administrator) a choice of what to do with as much information
as possible.

Eliot





--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: in the department of "ain't no perfect"

Hubert Kario
On Thursday, 17 January 2019 18:03:55 CET Eliot Lear wrote:

> On 17.01.19 17:29, Hubert Kario wrote:
> > alternatively, you can save all the certificates and revocation data, bind
> > it to the original signature using a timestamp from a TSA and store that
> > (that's necessary if you want to be able to prove to some 3rd party that
> > you received a correctly signed document/message at that time)
> >
> > but that is very close to reimplementing CAdES, or related standards, and
> > is far from simple (for one, requires adding, regularly, new timestamps
> > to extend validity of the original signature and subsequent timestamps)
>
> Right.  There are a lot of trust challenges around the timestamp.
> Because there are multiple non-cooperating entities involved, the signer
> is not in a position to predict who the recipients will trust, and the
> recipients may be retrieving the information later.  This is not a
> simple matter.
>
> What's more, we're not in a position to provide meaningful programmatic
> diagnostic info in this case because CMS is calling X.509 codes, and so
> ERR_get_err has a little issue when multiple libraries are in play.  And
> while nobody likes to hear, “I'll just bypass this one thing”, as a
> matter of practicality we want to provide the application user (in this
> case an administrator) a choice of what to do with as much information
> as possible.
then I'd say that showing the date from within the signature will be more
confusing than helpful to the administrator

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: in the department of "ain't no perfect"

OpenSSL - User mailing list
In reply to this post by Viktor Dukhovni
On 16/01/2019 21:25, Viktor Dukhovni wrote:

>> On Jan 15, 2019, at 10:29 AM, Eliot Lear <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: in the department of "ain't no perfect"

Eliot Lear
In reply to this post by Hubert Kario

On 17.01.19 21:20, Hubert Kario wrote:
> then I'd say that showing the date from within the signature will be more
> confusing than helpful to the administrator

Nevermind the date, you can't even get the expiration error
programmatically.



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: in the department of "ain't no perfect"

Hubert Kario
In reply to this post by OpenSSL - User mailing list
On Friday, 18 January 2019 05:45:11 CET Jakob Bohm via openssl-users wrote:

> On 16/01/2019 21:25, Viktor Dukhovni wrote:
> >> On Jan 15, 2019, at 10:29 AM, Eliot Lear <[hidden email]>
> > 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.
it does in newer versions (it is definitely present in 1.1.0i):
 -attime intmax             verification epoch time

> 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.

that's true

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

signature.asc (849 bytes) Download Attachment