Erwann ABALEA wrote:
>
> SET certificates are X.509v3 certificates at first.
>
> They have some critical and non-critical extensions specifying the type of
> cert it is, which level, for which usage (you can have a certificate for
> cert signing, another one for CRL signing, a third for tunneling, and
> a fourth for digital signature, all four with the same name).
>
> Basically, all the following extensions should be present in the BCA
> (Brand CA), GCA (Geopolitical CA), MCA (Merchant CA), PCA (Payment Gateway
> CA), and CCA (Cardholder CA):
> X509v3 Authority Key Identifier:
> DirName:/C=US/O=SET Test Root
> serial:0A:FE:07:21:6F:EA:BC:A8:9B:F3:4B:52:6F:D1:AE:38
> (* no keyid *)
> X509v3 Key Usage: critical
> Certificate Sign, CRL Sign (* you can combine the 2 usages *)
> X509v3 Private Key Usage Period:
> Not Before: Nov 7 15:36:00 2000 GMT, Not After: Nov 6 23:59:59 2001 GMT
> (* the maximum is one year, for every level *)
> X509v3 Certificate Policies: critical
> Policy: 2.23.42.5.0
> Unknown Qualifier: 2.23.42.7.6
> (* every level {RCA, BCA, GCA, {MCA, PCA, CCA}} can add it's one
> Policy *)
> X509v3 Basic Constraints: critical
> CA:TRUE, pathlen:2
> (* 3 for RCA, 2 for BCA, 1 for GCA, 0 for {MCA, PCA, CCA} *)
> 2.23.42.7.1: critical (* this one is the X509v3 Certificate Type *)
> .... (* something among RCA, BCA, GCA, PCA, MCA, CCA, Merchant,
> PGWY, or Cardholder *)
>
> There's another extension that is specific for the RCA (Root
> CA) certificates, and it's the "X509v3 Hashed Root Key", which contains a
> hash of the next root public key.
> Unfortunately, this extension cannot be parsed by OpenSSL right now (I
> went into this problem some months ago, posted a question, and didn't
> receive a valuable answer), as the OID is "2.23.42.7.0", and the leading
> ".0" causes problems (try to add it into the objects.h and rebuild the
> obj-dat.h, and you'll see).
>
> There are some other extensions specific for PCA certificates, some other
> for Merchant Certificates.
>
> I can send good (working) SET certificates to the OpenSSL team (if you're
> interested), these are signed by a Test Root that we host at Certplus, and
> these certificates are used for our test SET system. I can also send
> production certificates (we host some CAs), since certificates are
> public objects. The SET certificates that were present in the SSLeay
> package are invalid ones.
>
Yes I wouldn't mind looking at some SET certificates. If only to see if
the OID problem is still there. Some things were fixed a while ago but I
haven't checked to see if trailing zeroes work.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
