Dne 12.3.2013 11:54, Peter Sylvester napsal(a):
On 03/12/2013 09:30 AM, kap...@mizera.cz wrote:
RFC 3161 is written badly. The whole text was a joke anyway.
The requester SHALL verify that the
TimeStampToken contains the correct certificate identifier of the TSA
One may conclude that openssl should simply not validate anything else than
the first certificate. And simply ignore the rest of the ESS sequence.
Probably with an option.
That is similar what I wrote about meantime solution until OpenSSL
supports attr,certs.
It must not be there, if the attribute cert is available. If the TSQ
is with "-cert" => the TAC certificate is included in TSR. (I know -
it is not in our example which is "nocert").
Is there anywhere in the policy of the TSA an indication about what a
client is supposed to do with the atribute certificate, i.e. where
is the documentation of the behaviour of their own client.
There are two OID as attributes. .
No.
http://www.postsignum.cz/politiky_tsa.html
That is what about I "fight" with the Certification Authority.
I was (I am) afraid if their timestamps are rfc 3161 compliant or not.
They claim YES.
What do you thing ?
You can add critical extensions into the signing cert, whatever you want,
you remain conformant but not interoperable.
I'm not sure - on one side you are right: "authors of 3161, 3126 has
in mind any support of attribute certs"
but on the other side: rfc 3161 simply refers to RFC 2634 where are
attr. certs mentioned => they may (can) be there and should not
preclude verification process => the client MUST be able understand
all what is in tree with 3161 as root.
That's because the authors of RFC 3161 had probably overlooked the
possibility of attribute certs. T
he only reason for using ESSCert was to include a reference
to the signing cert (and maybe its chain), but not to allow all options.
Although the text says (last sentence):
If the certReq field is present and set to true, the TSA's public key
certificate that is referenced by the ESSCertID identifier inside a
SigningCertificate attribute in the response MUST be provided by the
TSA in the certificates field from the SignedData structure in that
response. That field may also contain other certificates.
I do not think that the last sentence means attribute certificates.
In fact RFC 3161 doesn't tell what one has to verify, And, as said
in the beginning, there is nothing in the text that says that
a client has to verify anything beyong the TSA's signature cert.
No. It is defined here:
RFC2634 page 47
The verification and possible usage of attr.certs is covered by other
RFC which are referred in 3161 => 3161 must not "say it" - there are
other RFCs an openssl have to support it to be usable for verifying not
just TS, but all signed messages (rfcs about CMS, ESS, ...) which can
contain attr. certs.
However, the actual identification of the entity
that signed the response will always occur through the use of the
certificate identifier (ESSCertID Attribute) inside a
SigningCertificate attribute which is part of the signerInfo (See
Section 5 of [ESS]).
Here one talks about IDENTIFICATION, attribute certs are for something
else.
???
No - it has nothing to do with our problem
BTW: rfc 3126, 5035, ... are not referred by 3161 => in timestamps may
be used only and only what is in tree with 3161 as root.
=> rfc 3126, 5035 are not valid for timestamps.
if a timestamp ess would be ok with an attribute cert, what is
the client supposed to do? It can verify the signatures of
the attribute cert up to some trust anchor, but then?
what authorisation is supposed to be checked? that the
tsa is allowed to issue certs for a particular policy? (don't
yes, maybe).
if the TSKlient is able to do something non stadardized special
verification, use that one.
That is no solution - the Q is: are or are not these timestamps
compliant with RFC 3161.
Compliant is not the right word, conformant. And since there
are no real conformance requirements, the question is almost
useless. You may try to use the argument, that the TSA MUST
include teh TSA cert into the ESScertid and add and nothing else
but that won't word because this argument is French. ;-)
The ESS cert that there SHOULD be a issuer and serial. That's not the
case.
Why do you thing ?
Where is it wrote ?
And even if - it is "SHOULD" not "MUST".
The TAC is included - (if "-cert" in TSQ) - the HASH is enough - openssl
has all it needs. It can chech the hash with hashes in included certs in
TSR.
If not, then they have no value.
Remark: discussed CA (TSA) is official, one of main CA in our country
- whole government things, law (electronic sigs, timestamps, ..), ...
depends on such institution. So it is very important Q.
The question is interoperability.
As said, I think the openssl tests can simply be weakend to only
validate the
first ESS cert.
No.
Such solution would broke the norm - see again: RFC2634 page 47
--kapetr
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
