[Delta] QCA 2

[Justin Karneges]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 
scaring me.

> 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 
format.

> 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 
optional.

> 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 
signature.

> 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 
messages?

> 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 
interoperable?

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.

- -Justin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAtmQK8+Nd5hn1dJ4RAvN+AKCSZxKvFhleYWnpykuXQMR0ybwNOgCdFf6P
zQbNQNfmmZ4CFi26J4A5VAs=
=SDtB
-----END PGP SIGNATURE-----