From: Bear Giles <[EMAIL PROTECTED]>
bear> The primary key is an opaque string henceforce known as the "alias".
bear> The plugin may treat this as a primary key, but must not attempt to
bear> interpret it as a hash, email address, keyid, serial number, etc.
I think I like the idea. Let's see what Dr Genson has to say.
bear> The attributes for each alias include:
bear>
bear> - key (PKCS8?)
bear>
bear> - certificate (X509)
bear>
bear> - cert chain (stack of X509, PKCS7 or PKCS12 format?)
bear>
bear> - creation date for entry
About the certificate and the chain: the chain will add a lot of
redundant information, at least as I see it, since each component of
the chain will most obviously be in separate certificate entries. You
could of course have the chain as a stack of "aliases". And also, if
the chain would be changed for any reason (that's absolutely possible,
as part of a cross-certification process, for example), that would
potentially be a LOT of entries to change. No, best leave chain
construction to run-time, wouldn't you say?
bear> A "KEY ENTRY" may contain a key alone (secret key), or a key and
bear> certificate (private key). In the latter case, the entry should also
bear> contain the cert chain returned from the CA.
bear>
bear> A "CERTIFICATE ENTRY" contains a certificate alone.
Hmm, some of what you say is a little bit confusing. First of all,
most people use "private key" for what you call "secret key" (they use
"secret key" for it as well...). If you must do a separation, I'd do
it in three:
KEY ENTRY that contains a private/secret key only
PRIVATE CERTIFICATE ENTRY that contains cert and private key.
CERTIFICATE ENTRY that contains cert only.
But homestly, I can't quite see the puspose of those names unless it's
just to make description easier.
bear> In addition, we would define additional functions including
bear>
bear> Enumeration list(PATTERN *p)
bear> list subset of aliases which satisfy some pattern. PATTERN would
bear> be like we discussed earlier - something like
bear>
bear> typedef struct {
bear> enum {
bear> SUBJECT, // X509_NAME
bear> ISSUER, // X509_NAME
bear> SERIAL, // ASN1_INTEGER
bear> SHASH, // unsigned char[] (assuming SHA1 from Gutman paper)
bear> IHASH, // unsigned char[]
bear> IANDSHASH, // unsigned char[]
bear> CERTHASH, // unsigned char[]
bear> B64SHASH, // char *
bear> B64IHASH, // char *
bear> B64IANDSHASH, // char *
bear> B64CERTHASH, // char *
bear> COMMON_NAME, // char *
bear> EMAIL, // char *
bear> } type;
bear> union {
bear> type1 a;
bear> type2 b;
bear> ...
bear> } u;
bear> };
Hmm, I have a hard time to see this as working for anything but the
few easy examples it's meant for. I would prefer a much more flexible
interface which would allow me to do searches on more or less any
combinations of attributes, and the attributes available are at the
discretion of the application, not the bottom-level plug-in.
A search pattern could be a vector of tuples <OID, value> or
something like that, and the application could be given the
possibility to send down a callback to the plug-in, which could help
doing the selection given a certificate and a chunk of database
attributes.
--
Richard Levitte \ Spannv�gen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-733-72 88 11
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, GemPlus: http://www.gemplus.com/
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
