Dne 12.3.2013 08:49, Peter Sylvester napsal(a):
On 03/11/2013 11:17 PM, kap...@mizera.cz wrote:
That is what we talk about here.
Try to check previous posts in this thread.
rfc 3126 tells
This document mandates the presence of this attribute as a signed CMS
attribute, and the sequence must not be empty. The certificate used
to verify the signature must be identified in the sequence, the
Signature Validation Policy may mandate other certificate references
to be present, that may include all the certificates up to the point
of trust. The encoding of the ESSCertID for this certificate must
include the issuerSerial field.
RFC 5035 says
If more than one certificate is present, subsequent certificates
limit the set of certificates that are used during validation.
Certificates can be either attribute certificates (limiting
authorizations) or public key certificates (limiting path
validation). The issuerSerial field (in the ESSCertIDv2
structure) SHOULD be present for these certificates, unless the
client who is validating the signature is expected to have easy
access to all the certificates required for validation. If only
the signing certificate is present in the sequence, there are no
restrictions on the set of certificates used in validating the
signature.
The time stamp does not include issuerSerial in the second esscertid.
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").
There is no specification of any profile of time stamps that
indicates that a client MUST support attribute certs.
I do not think that the authors of 3161, 3126 has in mind any
support of attribute certs. I don't recall any profile requiring
this.
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 ?
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.
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.
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.
--kapetr
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
