Re: Thawte Digital Certificate Revocation List Issue

From: *Vanguard* (no-email_at_post-reply-in-newsgroup.invalid)
Date: 03/12/04 

Date: Fri, 12 Mar 2004 13:55:03 -0600

"Illinois Divorce Reform" said in
news:OR5x3VFCEHA.2620@TK2MSFTNGP12.phx.gbl:
> I am new to digital certificates and cannot get the Thawte certificate
> revocation lists to work.
>
> I get this message when I view the cert:
>
> 'The digital ID cannot be checked for revocation because a revocation
> list is not available.'
>
> I get this message even though I have imported the certificates.
>
> Any guidance would be appreciated.
>
> BC
> trxcv@adams.net

It's been awhile since I played with the Thawte certificates. Their
freebie certs are worthless for digital signing since anyone can get one
and no proof of identity is required to get one. Yeah, you can go
through their Web Of Trust to get more info added to your certificate
but, I believe, there is a charge made by each authentication and you
need something like 3 authentications. Probably costs the same as if
you got a full certificate in the first place. The only good for the
Thawte freemail certs is to let you encrypt your message, not to
identify yourself.

The problem is with Microsoft and Thawte. Microsoft requires the cert
to specify its CA (certificate authority) and where to find the
revocation list. Thawte doesn't specify in its certs where to find the
CRL (certificate revocation list) so Outlook doesn't know where to get
it. The concept of a CRL hails back to the days when sales clerks had
to scan through a list of known bad checks hoping that the list of bad
checks is much smaller than the list of good ones. Since there's no
point in trying to verify most Thawte freemail certificates because the
owner isn't identified any further than the fact that they have the
e-mail address used for that freemail cert. Since Thawte doesn't
specify where to get their CRL to the e-mail client, authentication
cannot be automated. Instead you have to go to Thawte's web site and
download their then current CRL (I don't remember what you do with it
after downloading it). That means every time you want to verify a cert
that you will have to download their CRL again. Yeah, like that's going
to happen. A manual process to obtain the CRLs to validate a digital
signature obviates the expected automated procedure expected by users.

Check the article at
http://www.thawte.com/html/SUPPORT/email/iexplorer.html. Thawte's claim
is no e-mail client currently supports the automated download of CRLs
(but they haven't updated this article since I played with their
freemail certs something like over a year ago). I only use Outlook for
e-mail so I cannot verify that no other e-mail clients support automated
download of CRLs. When I contacted Microsoft, they claimed that the
Thawte freemail certs did not list the download path (I don't recall if
an actual path is listed in the cert or the CA server is expected to
respond with the path to tell the client where to get the CRL).

OCSP (see http://www.openvalidation.org/whatisocsp/whatindex.htm) is
supposed to replace the CRL downloading. Even if CRLs worked, and even
if they automated okay, you would end up having to repeatedly download
the CRLs and you would have to download every CA's CRL. I don't know
how many CAs there are but it sounds ridiculous that I have to download
lots of CRLs, one for each CA, and have to do it continually to make
sure all those local copies of the CRLs are up to date. OSCP (Online
Certificate Status Protocol) sounds like a better solution but it
probably won't let you validate a cert unless you are also online at the
time. That means the e-mail client would have to poll the OSCP server
right after it got a digitally signed e-mail. But then if CRLs actually
worked then e-mail clients would also have to be online and yank the CRL
after it got a digitally signed message so it would know from which CA
to yank the CRL. RFC 2560
(http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2560.html) is for OSCP but
I don't know if it has actually been ratified, if any e-mail clients
support it yet, or if any of the CAs have implemented it. A typical
catch-22 scenario: do CAs implement OSCP when no e-mail clients yet
support it or do they wait until enough e-mail clients support OSCP to
then implement OSCP servers?

My only experience with x.509 digital signatures was with using Thawte's
freemail certificates. From what I could find out, Outlook couldn't
validate a digitally signed message that used a Thawte cert because
Thawte didn't provide the path to find their CRL in their certificate.
Maybe someone that uses a different CA, like Verisign, can indicate if
Outlook can automate the authentication for digitally signed e-mails
that use a CA *other* than Thawte.

The only good for digital signatures is to note that they have NOT been
revoked. That doesn't really tell you anything if the cert has not been
revoked other than the information contained within the certificate
itself. For Thawte freemail certs, the only valid information is the
e-mail address. But since you can get Thawte freemail certs for
disposable webmail accounts, like Hotmail or Yahoo, and since those
account owners don't have to validate anything in the information for
those accounts (i.e., they are pretty much anonymous except for the
sender's IP address that those services insert into the headers), there
is little value to most digital signatures. Oh, gee, it's signed by
someone using a Hotmail account. That tells you nothing about the
sender. Even for regular e-mail accounts, I find that ISPs are
extremely reluctant to divulge any information about their customers so
you trying to find out who owns an e-mail account with them will require
that you are reporting abuse from this user (but then the ISP might
handle that and still not tell you who owns the account) or you use the
courts to press them to divulge the sender. Obviously the more
information that is contained within the certificate the more you'll
know about the sender. I really don't know how many Thawte freemail
certificate users actually bother using Thawte's Web of Trust notaries
to update their certs to insert more personalized data. Just because a
certificate is not revoked does not mean it adequately identifies the
sender.

Relevant Pages

  • Re: ADFS Token-signing Certs Not in Trusted Root Store
    ... This is good info, Joe. ... So now I know that the token-signing certificate is ... Get a signing cert from a CA ... case, you never have to worry about expiration or CRL checking, as your cert ...
    (microsoft.public.windows.server.active_directory)
  • Re: Newbie wants to learn about PKI Server 2003......
    ... 2003 PKI Certificate Security", and have been lurking here for a bit. ... We will implement a 2 tier heirarchy, with the Root CA being offline. ... All clients that attempt revocation checking will first attempt to retrieve the CRL from the ... level below a self-signed cert, so applications that are 3280 compliant would never check the ...
    (microsoft.public.windows.server.security)
  • "include in CDP" extention error - Reproducible error:
    ... Cert Auth Properties, that I have to re-issue the CAExch cert because PKIView ... users where to get CRL and CA cert files. ... Wrong Issuer "Certificate " Time: ...
    (microsoft.public.security)
  • Re: CRL Issues with Win2k3 Cert Svcs
    ... When I look at the CDPs (CRL Distribution Points) I see the standard ... Include in the CDP extension of issued certificates is set. ... The certificate request was submitted to a Certificate Authority ... KRA cert count: 0 ...
    (microsoft.public.windows.server.active_directory)
  • Re: exim4 SSL/TLS client: refusal to verify certificate
    ... You might need to grab the thawte CA cert and ... Exim doesn't even care about the server's certificate. ... I concatenate all Thawte root certs ...
    (Debian-User)
Quantcast