Re: signed e-mail

[Bob Jueneman<bjueneman@xxxxxxxxxx>]

Rob, I wanted to get back to you after I did a little more checking regarding some of the compliance issues I raised.  It appears that I may have misstated a couple of things.

I displayed your entire certificate path, and then because I don't normally accept certificates from CAs that I haven't encountered before, I manually accepted the Equifax certificate that was signed by Thawte.  (No, I didn't go off to read their CPS, and no, I don't know what some of their OIDs mean, so no, I don't really have a logical reason for doing so.)  I did notice that they don't include an authorityRevocationList for their certificate (not yours), so I can't be entirely sure that the CA's certificate hasn't been revoked. 

Also, their certificate (not yours) is flagged as not being V3 compliant, because their keyUsage is not flagged as critical.  I haven't gone back to double-check the relevant standards, but according to the text you sent me privately, it appears that keyUsage MAY be marked critical, or may not, so perhaps GroupWise is being overly strict. Curiously, the Thawte root certificate is marked as compliant, but not one the one that they issued to Equifax. But that is a minor issue in any case.

After explicitly trusting the Equifax CA, your own certificate is flagged as being compliant. I marked it as trusted, and everything looked fine, except for the CRL processing.  When I tried to validate the CRL, GroupWise failed to retrieve it, complaining about an "unknown error".  So I copied the URL form the certificate and pasted it into the address line of IE5.  It asked me whether to save the file or execute it remotely, so I held my breath and said execute remotely, and down it came, just fine.

Now if I go back and re-retrieve and revalidate your message, it now comes up with no complaints at all, and indicates that the message is properly signed -- everything is lovely.  Since GroupWise uses MS-CAPI to do most of its crypto processing, it appears that downloading the CRL into IE stuffed it into the right location for GroupWise to process.

So now I have two problems.  First, I don't know why GroupWise couldn't retrieve it, but this may be due to some kind of an interaction with the personal firewall I run (Zone Alarm Pro).  I obviously allow IE to go out to the Internet, but I don't automatically allow GroupWise to do so, because I don't want it to suck down HTTP contents from some site without my knowing about it.  But Zone Alarm didn't ask permission, so I don't know what's happening.  The GroupWise developer said that he just calls CAPI to verify the CRL, and returns whatever error condition CAPI returns.  So I am going to have to research this further.

The second question is how long CAPI will archive that CRL without revalidating it.  Although I've looked through the various Tools menus, so far I can't find anything that appears to control how CRL caching is done, so my suspicion is that it will remember that CRL until the expiration date, and then presumably try it again and presumably fail again.  After I send this, I'll reboot and see if it attempts to get a new one, and I'll also try it on my laptop, both in connected and disconnected mode.  Of course I'll first have to go through the same acceptance process on my laptop. But does anyone know any more details about how CAPI controls CRL caching?

Nonetheless, despite the need to do some further research, I believe that this process is indicative of why PKI has so far failed to thrive. I certainly don't profess to be an expert in every nuance of this process, but I would assume that I probably know more, and have a lot more patience, than the average user trying to use PKI software.  And if I'm having this much trouble trying to get PKI to work smoothly, I can certainly understand why the people that are responsible for the help desk in most companies would be reluctant to support it without a compelling need, regardless of the potential long-term virtues.

Most of these problems seem to be management and administration issues, rather than the technical functionality per se:

1.  Adding new roots is too complex, yet the number of roots that already come "trusted" is probably far too many to be safe.  Because the process of acquiring certificates from a TTP is too complex to begin with, there will be a tendency for enterprises to mint their own certificates, using their own CA toolkit.  This will of course exacerbate the trusted root problem.  We need a very simple, brain-dead way for user's to generate and/or download their own keys and certificates, together with all of the root and intermediate CA certificates that the enterprise decides to trust, together with some way 

2.  Adding intermediate CAs is also too complex, and unless authority revocation lists are supported it raises the question of whether that certificate itself is still valid.  so in addition to worrying about the out-of-band trust required for root certificates, we also have to worry about intermediate CAs

3.  Unless an option is set to always trust users authenticated by this CA, adding a new user to your list of trusted users is that much more work.  And why would you automatically trust a new user, unless are we are using this for is purely syntactic validation, with no concern for the deeper semantic issues?

4.  Support for CRLs is uneven at best, and that's being charitable.  Your Equifax certificate includes a CRLDistributionPoint, but so far there seems to be a glitch in the process somewhere which I'm going to try to resolve.  Michael Stroder's certificate doesn't include one, so I can't automatically trust his certificate.  Bernd Matthis's certificate (issued by Thawte) not only doesn't contain a CRLDistributionPoint, but it contains a Basic Constraint (set to Critical!) on an end user certificate. But Massimiliano Pala's certificate takes the prize.  Not only does his e-mail not contain a self-signed root certificate so I could decide whether or not to accept it, but there is no CRLDistributionPoint. Instead, there is support for a Netscape revocation URL, which points to  https://www.openca.org/cgi-bin/getcrl .  But that requires some kind of a certificate or other form of authentication in order to download it!  So despite the OpenCA name, this is apparently a closed PKI that you have to be a member of to use.  So why sign a public e-mail with such a certificate?!

Of course, some of us are in the position of being the shoemaker's children.  My own certificate does not chain back to a common root, because the root CAs are not inclined to support the use of subordinate CAs operated by individual companies -- it obviously eats into their business.  And it also doesn't include support for CRLs, since the general feeling is along the lines of "Why should we further enhance a free product when no one is making any money in the PKI business except VeriSign?"  Catch22, of course.  And while we did at least provide a URL to the defining document for the Novell Security Attributes within the attribute itself, our software and Peter Gutman's certificate dump routine are probably the only ones that would display the contents properly.

Regards,

Bob


>>> "Bob Jueneman" <bjueneman@xxxxxxxxxx> 11/09/01 02:14PM >>>
Well, in part because most of the TTP CA's software is rather far behind the current standards and S/MIME implementations, and that causes some aggravating user interface problems.

Your Equifax certificate, for example, does not contain a CRLDistributionPoint, so I have no way of verifying whether your certificate is still valid.  In addition, it doesn't have the keyUsage field flagged as critical, so I get a warning that it is not V3 compliant as well. 

Your own certificate confirms that you are Rob G Weemhoff, AKA  rob_weemhoff@xxxxxxxxxx , but it also says, as part of your subject name, that you are OID.0.9.2342.19200300.100.1.1=093252788.  And since I don't recognize that OID, I don't know whether that means that I should give you the secret handshake the next time we meet, or simply shoot you when you show up.  Or maybe that's your robot ID, or your rabies vaccination tag number -- who knows!

So I get a big splash screen full of warnings that I then have to ignore to read what you said.  And even though your certificate presumably confirms that your identity is indeed Rob Weemhoff, that in itself doesn't convey any useful information to me the first time around, since I don't know Rob Weemhoff from Adam.

But it did turn a 413 byte message into a 7138 byte MIME-encoded message, which has to be transported and stored until I decide to purge it.

In short, no value was added when communicating with strangers, except that I know that the mail gateway didn't mangle your message.  

In addition, if I were to digitally sign my mail, then I would feel compelled to add a fairly lengthy paragraph of legal disclaimers to protect myself against the possibility that my utterances might be construed to be legally binding under the laws of the Nether Antilles or elsewhere.

Having said all of that, I DO routinely use signed and/or encrypted mail when there is some purpose for doing so.

Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software



>>> "Rob G Weemhoff" < rob_weemhoff@xxxxxxxxxx > 11/09/01 10:34AM >>>
To start with, why are we, as security advocates, not all using signed 
e-mail?

----
Regards,
Ing. Rob G. WEEMHOFF 
Senior Consulting IT-Architect 
IBM Security and Privacy Services (EMEA)
Tel:        +31(0)20 513  9102 
Mobile: +31(0)653263269

E-mail:  Rob_Weemhoff@xxxxxxxxxx  
Fax: +31(0)33 2470578
Computerweg 8
3821 AB  Amersfoort
The Netherlands

 http://www.ibm.com/security  
See you at AIM (RobGWeemhoff)

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature