[Delta] QCA 2
justin-psi at affinix.com
Thu May 27 14:56:25 PDT 2004
-----BEGIN PGP SIGNED MESSAGE-----
On Thursday 27 May 2004 1:52 pm, Marco Carnut wrote:
> > What I propose is that the provider plugin should create an
> > internal thread, invisible to the QCA user. This is how my NDns
> > works, and
> > means the user doesn't have to worry about thread-safety.
> That would be a cleaner idea. I'll try to see how to implement
> this in any new code I write.
I'll give this a shot soon. I had gotten rid of the "RSA" class, and allowed
generation via the constructor of my newer "RSAPrivateKey". However, I think
I'll bring back a generator class, one that will do signalling, so that I
don't have to make the key classes themselves into QObjects.
> I do have a need for many choices though, but this is hard to
> explain now. It'll become clear later on. The bottom line is that
> I'd prefer sensible defaults instead of too many restrictions.
> So simple things are kept simple but if you need to do something
> nonstandard, you can.
Alright, we'll have to see how workable these are.
> > For RSA, you've added password protected PEM. I have done
> > this in QCA2, but I left out the 'algorithm' parameter, and
> > just use TripleDES (Botan recommends everyone uses it).
> It was easy enough to add and some of my users said they wanted
> AES (for no justifiable reason... for pwd encryption 3DES is
> great because it's so slow... but my marketroid users want it
> for compliance with competing products spec sheets).
Are you sure this is a good idea? Here's the excerpt from Botan:
If pbe is blank, then the default algorithm (controlled by the "base/default
pbe" option) will be used. As shipped, this default is "PBE-PKCS5v20
(SHA-1,TripleDES/CBC)". This is among the more secure options of PKCS #5, and
is widely supported among implementations of PKCS #5 v2.0. It offers 168 bits
of security against attacks, which should be more that sufficient. If you
need compatibility with systems that only support PKCS #5 v1.5, pass
"PBE-PKCS5v15(MD5,DES/CBC)" as pbe. However, be warned that this PBE
algorithm only has 56 bits of security against brute force attacks.
There may be some strange programs out there that support the v2.0 extensions
to PBES1 but not PBES2; if you need to inter-operate with a program like
that, use "PBE-PKCS5v15(MD5,RC2/CBC)". For example, OpenSSL supports this
format (though since it also supports the v2.0 schemes, there is no reason
not to just use TripleDES). This scheme uses a 64 bit key, which, while
significantly better than a 56 bit key, is a bit too small for comfort.
Where does your AES fit in? Is it "PBE-PKCS5v20(SHA-1,AES128/CBC)" ? Thus,
only the cipher name is what you wish to change?
> > What is RSA::toSPKAC() ?
> In my app I generate a new keypair that is sent to a Certificate
> Authority. This CA accepts the public key in SPKAC (Signed Public
> Key and Challenge) format. This is the Netscape-style of generating
> keypairs and sending the public key to the CA (this is done with the
> <KEYGEN...> tag). IE, on the other hand, uses a whole different and
> more complicated approach. To keep things simple in my app, I used
> Netscape's approach.
Does this really need to be in QCA? The mention of specific web browsers is
> Great. I imagine we have a way to convert those QBigIntegers
> to nicely formatted QStrings that my app needs.
Yes, to/from QString and to/from QByteArray are possible, the latter in binary
> So, this Cert::extensions() method just return those things as
> name-value pairs. There's a kludge: extensions also have a flag
> to tell them whether they are critical or not. The critical ones
> have an "*" appended to their names. Yeah, I know this is ugly.
> I planned to fix this later, creating a nice class for it.
Is it all just name/value ? Your example output looked hierarchal, though
maybe I was reading it wrong.
> > Explain these:
> > QString signatureAlgorithm() const;
> > QString signature() const;
> As I said, my app dissects the certificate. There's this dialog that
> displays even more info than the "openssl x509" command. Those two
> get the name of the signature algorithm used in the certificate
> (most commonly sha1WithRSAEncryption or md5WithRSAEncryption) and
In OpenSSL, would this be "NID_sha1" and "NID_md5", respectively? This is
what I was talking about earlier regarding fixed settings. My RSA class
currently signs always with sha1. I suppose we'll want to now make this
> the signature block itself (which should be a QBigInteger).
This is the Issuer signature of the certificate data? This is fine, though
the result is probably more appropriately a QByteArray like any other
> PKCS7 is a standardized format for a "bag" that can hold certs,
> signatures and messages. For instance, when a CA signs your
> certificate, it sends it in a PKCS7 bag along with its own CA
> cert. The PKCS7 can assemble and dissasemble those bags from/to
> a nice QPtrList<QCA::Cert>, along with saving/reading to/from
> disk or memory in PEM (Base64+armor).
A bag of certs I can understand. But what do you mean signatures and
> PKCS7 can also do S/MIME encryption and signatures. The PKCS7
> class can both generate those sigs and verify them. I didn't
> implement the encryption/decryption stuff just yet.
Ok, it was this signing stuff that made me first think of CA signatures. So
this actually for S/MIME, as in what email clients use?
> PKCS12 is a limited PKCS7 bag + private keys. That's what you
> use when you want to move your private key, say from IE to
> Mozilla or vice versa. The class uses the OpenSSL "keep it simple"
> API to allow importing/exporting of cert chains and private keys.
I figured S/MIME programs must have had something like PGP programs do, for
storing public and private "keyrings". Is PKCS12 effectively this, but
I wonder, are PKCS7/12 simple enough that they could be implemented directly
within QCA? This way they could work with any X509 provider plugin. The
reason I ask is because I wanted to make a full featured provider using
Botan, but it has no support for PKCS7/12.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Delta-affinix.com