Subject: Re: [pkix] timestamp signature validation

From: [email-masked]
Date: Wed, 13 Mar 2013 09:52:36 +0100

Hello,

thanks Peter Sylvester you know now about the problem with attr. certs 
in timestamps I have with TSA.

It may be useful for you to see original thread with details and example 
in OpenSSL user forum.

Thread subject: "possible Bug in OpenSSL - rfc 3161 - TSA service"

See:

http://marc.info/?l=openssl-users&w=2&r=1&s=possible+Bug+in+OpenSSL+-+rfc+3161+-+TSA&q=b

--kapetr

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 13 Mar 2013 12:30:16 +0000

[email-masked] writes:

>It may be useful for you to see original thread with details and example in
>OpenSSL user forum.
>

I like the comments made in the thread that "Adobe handles it so it must be
OK".  That's a bit like saying "Internet Explorer handles it so it must be
valid HTML".

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 16 Mar 2013 06:08:28 +0000

Martin Rex <[email-masked]> writes:

>The first thing that puzzles me: why does ESSCertID use such an extremely
>awkward "ESSCertID"?

The PKIX charter explicitly prohibits doing anything in a logical,
straightforward way (look at... well, I hardly know where to start in terms of
referencing RFCs for this, there's so many).  However the issue has been
quickly resolved (as have many other of the more awkward requirements in RFCs)
by everyone agreeing that an ESSCertID is:

  ESSCertID ::=  SEQUENCE { certHash OCTET STRING SIZE(20) -- SHA1 hash }

>I'm puzzled why rfc5035 defines ESSCertIDv2 in a fashion that it is
>thoroughly binary incompatible with ESSCertID from rfc2634?

See above.  As an implementer you just deal with these things and move on,
it's not worth breaking your head over it.

Peter.