Subject: Re: signed e-mail

From: Aram Perez <[email-masked]>
Date: Sun, 11 Nov 2001 07:12:04 -0800

On Friday, November 9, 2001, at 09:34  AM, Rob G Weemhoff wrote:

> To start with, why are we, as security advocates, not all using signed
> e-mail?

Because we are humans and we trust the Internet mail system. With all 
the respect they are due, you can tell the emails that come from Bob 
Juneman, Lynn Wheeler, Peter Gutman, Peter Williams, Steve Kent and 
others and hence we have an implicit way of verifying and trusting that 
the emails did actually come from those persons. And this implicit 
verification and trust has nothing to do with any type of PKI.

Just my opinion,
Aram Perez

---

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 12 Nov 2001 10:14:36 -0700

Aram,

You mean it wouldn't take a Shakespearean scholar and a computer stylistic analysis program to tell us apart? :-) 

And, of course, just because you might be able to trust that the e-mail came from me says nothing at all about whether you should trust the CONTENT of said message.  At the (slight) risk of being confused with Lynn, the fact that I sign a check doesn't mean that there is any money in the account.

This is why I said that if I were to routinely digitally sign my mail, I would probably put some legal disclaimers on it. Perhaps this is a philosophical point, but why else would you SIGN something, as opposed to putting your address in a tag line?  to answer my own question, I can see three reasons:

1.  To make sure that the message arrived unaltered.  But this is hardly a sufficient justification -- message mangling, even accidental corruption, is sufficiently rare that most of us would question whether it was even worth the bother of checking the right box, much less deploying an entire PKI system for.

2.  To make sure that the message really came from the putative sender, and that someone wasn't playing games.  Again, at least in this venue, that isn't a problem, and so it's not worth doing for that purpose alone, IMHO.

3.  To make sure that the content of the message really represented the sender intent, by requiring him to go though some formalistic or quasi-ceremonial mechanism -- in my case being prompted to enter the password for my signature key each time.  If the e-mail is not a contract, then the signature was presumably intended at the least to be a publicly acknowledged utterance, which the sender would not later attempt to repudiate.

Now granted, maybe we could all benefit from a sluggish Send button from time to time, just to allow time to engage the brain before opening the e-mail mouth, but it isn't clear that this would constitute a sufficient justification for routinely signing e-mail either, at least on a discussion list such as this.  Rob Weemhoff privately indicated that IBM was starting to use (or was considering using) signed e-mail when communication with customers or potential customers, and I think that such communications might very well fall into that "I really meant to say this" category.

Bob

>>> Aram Perez <[email-masked]> 11/11/01 08:12AM >>>

Just my opinion,
Aram Perez

---

From: Bob Jueneman<[email-masked]>
Date: Tue, 13 Nov 2001 12:00:00 -0600

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" <[email-masked]> 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 [email-masked], 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" <[email-masked]> 11/09/01 10:34AM >>>

----
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: [email-masked] 
Fax: +31(0)33 2470578
Computerweg 8
3821 AB  Amersfoort
The Netherlands

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

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 14 Nov 2001 16:37:33 -0700

In a recent message, I asked some questions regarding how MS-CAPI handles CRLs, controls caching, etc.  A friendly little bird provided me a reference to an excellent white paper on the subject: 

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/WinXPPro/support/tshtcrl.asp

The long and short of it is that CRLs are cached in several locations, but in Windows 2000 they are held until the validity period of the CRL expires.  The only way to purge them is to delete the temporary Internet files.

In Windows XP, the processing is more complex, and at least when used in conjunction with delta CRLs a freshness parameter can be specified.

On the one hand, the paper is of considerable interest in laying out how the processing of certificate paths is accomplished in accordance of the current standards, and how they deal with all of the various options.

On the other, it is an excellent illustration of how complex the standards have become, and how difficult it can be for both the end user, or even worse the system administrator who is trying to set up a PKI.

It reinforces my belief that most of the necessary functionality is now in place  -- and then some, in some cases.  But the ability to manage this process is still far from being under control, and that is probably the single biggest hindrance that is holding back PKI.

Bob

Robert R. Jueneman
Security Architect

---

From: "Rob G Weemhoff" <[email-masked]>
Date: Sat, 17 Nov 2001 20:02:56 +0100

On Tuesday, 13-11-2001 at 12:00 CST, Bob Jueneman<[email-masked]> 
wrote:
> [...]  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. 

I observed that when I save the CRL file to disk and thereafter install 
it, it says the import is successful, but in fact id did not overwrite the 
existing CRL as I noticed with the certificate manager in MMC. 
When I do, like you, execute remotely it is imported correctly, and also 
if I first delete the old CRL.

But, this locally stored CRL appears not to be used at all.

> [...] but this may be due to some kind of an interaction with the 
> personal firewall I run (Zone Alarm Pro).  [...]

I use Symantic Desktop Firewall, and I am unsure about its rules, because 
it silently blocks things, but I have from the logs no indication of any 
inference.

> [...]

I am very happy with your long expose, because this discussion is exactly 
what I hoped for.

One of my observations: There is no difference in Outlook Express/Windows 
2000 SP2 reporting the validity of my Equifax and my Verisign certificate, 
while the Verisign intermediate CA contains a CRL distribution point and 
(as you observed) the Equifax CA does not.
The revocation status is: The digital ID has not been revoked or 
revocation information for this certificate could not be determined.
I do not know if there can be an unconditionally valid status but I know 
there is no unconditional status when it can not get the CRL because I 
deluded Outlook in thinking it was connected while I switched off my 
socksification so both CRL's positively could not be accessed.
So now I know that Outlook Express can not access the CRL's, but I do not 
know why.

B.t.w. I am preparing a revoked Equifax certificate for testing purposes. 
If someone wants to receive a message intentionally signed with a revoked 
certificate, just ask directly, and I will sent a message when I have seen 
the certificate in the CRL.

----
Regards,
Ing. Rob G. WEEMHOFF 

http://w3.ibm.com/services/bisglobal/solutions/security.html
news://forums.ibm.com/forums.security.community
See you at Sametime (http://w3.ibm.com/team/im/)