RE: signed e-mail [Virus checked]

[Ryan Hurst <ryanh@xxxxxxxxxxxx>]

Olaf --
	I believe you may be miss-informed, what certificates are checked in
the case of CryptoAPI are dependant on what API is used to determine
certificate status and what parameters are passed to them
(CertVerifyRevocation, WinTrust, CertVerifyCRLRevocation or
CertGetCertificateChain). Some applications check the entire chain and
return the overall status ala PKIX, while others only check the end entity
certificate as you describe. For reference see
http://msdn.microsoft.com/library/en-us/security/cryptoref2_7x0z.asp?frame=t
rue additionally the paper Bob referred to talks about some details of this
as-well.

For example if one calls the recommended call of CertVerifyRevocation then
what is checked is determined by what the array of certificates passed in
contains. On the other end if one uses to deprecated call of
CertVerifyCRLRevocation only one certificate is checked at a time. There is
another call which I find most applications use which is
CertGetCertificateChain, this takes a flag that states if the any, some or
all certificates in the chain should be checked. 

For example I believe IIS 5.0 checks using this later mechanism and passes
CERT_CHAIN_REVOCATION_CHECK_CHAIN so the entire chain (including the root is
checked).

Ryan M. Hurst
ValiCert, Inc.

-----Original Message-----
From: Olaf.Schlueter@xxxxxxxxxxxx [mailto:Olaf.Schlueter@xxxxxxxxxxxx] 
Sent: Thursday, November 15, 2001 3:42 AM
To: Bob Jueneman
Cc: ietf-pkix@xxxxxxx; owner-ietf-pkix@xxxxxxxxxxxx
Subject: Re: signed e-mail [Virus checked]


Very interesting document. It does contain a hidden sensation, at least
from the german point of view. The XP implementation of path validation is
compliant with the german signature law conformant model:

"In the Windows .NET Server PKI, a certification path can be valid as long
as the CA certificate was valid at the time the certificate was issued"

Lots of discussions about this rule among experts in germany when it has
been derived by legal argueing (a signature valid at the time of signing
cannot be invalidated later on otherwise it is not a signature in the world
of lawyers) from the german signature law as it was not compliant with the
PKIX path validation process. I remember some remarks on this list on that
topic as well.

Certification pathes valid according to PKIX are valid according to this
model as well, but the law conformant model treats some pathes as valid
that PKIX would consider invalid. The main advantage is that existing user
certificates do not become invalid if the issuing CA certificate is
revoked. With a properly configured trust center CA revocation  would be
the only occasion where the two models would give different results.

It was not expected that this "german invention" would be implemented in
standard software containing PKI functionality soon, if ever.

Olaf Schlueter
SECARTIS AG



 

                    "Bob Jueneman"

                    <bjueneman@xxxxxxx       To:     <ietf-pkix@xxxxxxx>

                    com>                     cc:

                    Sent by:                 Subject:     Re: signed e-mail
[Virus checked]                           
                    owner-ietf-pkix@xx

                    il.imc.org

 

 

                    15.11.2001 00:37

 

 





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/prodtechn
ol/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

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



(See attached file: Bob Jueneman.vcf)