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.
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. .
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.
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.
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.
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.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
