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
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
