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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




Attachment: signature.asc
Description: OpenPGP digital signature

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux