[dev] Re: [cvs] commit: imp/lib/MIME/Viewer pkcs7.php imp/lib SMIME.php imp smime.php

[Cliff Green]

Quoting Mike Cochrane <mike@graftonhall.co.nz>:

> S/MIME is getting there now... It's nearly caught up to PGP in what it can
> do.
Way Cool.

 
> At the moment when there is a certificate availalable it shows up at the
> bottom of a message. This doesn't look that good and who want's to see the raw
> certificate anyway (well the PGP users must do cause that's what they get).
Ugh.


> Should we:
> a: Move the add certicate link to the top with the verification info
Yes.  I haven't checked it yet, but can I assume that this link adds a
certificate to a current turba entry, or does it add a whole new entry (like the
Add to Addressbook link in the message view window)?

> b: Hide the certificate data all together
Definitely hide the raw data.  Ugh.

> c: Show info about the certificate instead (eg signer, uses (sign, encrypt
> etc), subject)
Yes, I was looking at parsing the cert to at least provide the Common Name of
the signer.  We're also going to have to think about what to do when the signing
cert (the CA's cert) is either self-signed, from a private hierarchy, or an
intermediate CA.  Where would these be stored (currently, I only have our
intermediate signing cert in the cafile directory)?  This part rapidly becomes a
headache.

> d: Have a link to certificate details and popup the above details
That would do.

> e: Have a link to the raw certificate
If we're not going to give the user a way to import it, this would be a last resort.

> f: Something I haven't though of yet
Dunno.  :)

 
> Anyway.. if you us S/MIME in another mail client them please sent some
> message between it and IMP and make sure send and receive are working fine
> for you.
Will do, soonest.

PS - I don't want to sound pedantic (okay, maybe I do), but I'd still like to
make a distinction in the variables, database fields, and functions between
public keys and certificates - this will be relevant when we get to peeling them
apart.  So far, we've been storing and handling certificates, which you can
think of as containers for public keys plus information about the identity the
public key is bound to as well as the certifying authority.  So, it may be
painful to shuffle them around now, but I think we'll want to distinguish
between them later.  For example, in sources.php.dist, you name the field
'object_smimepublickey' instead of something like 'object_usercertificate'
(note: in the inetorgperson ldap schema, the attribute is called userCertificate).

I know I can just rename these things in my own installation, but I'd like to
lobby for maintaining the distinction.

Regardless, I want to thank you for the some really great work here.

c
-- 
Cliff Green
Academic Computing Services - UMDNJ
Signature under NDA