Subject: Acquisition Problem Solved for some certs? (Was: Re: RFC 3280: same certificate in a certification path)

From: Tom Gindin <[email-masked]>
Date: Sun, 29 Jun 2003 22:14:37 -0400

Peter:

      I believe I can specify a set of standard conditions on certificates
that would permit all the CA certificates and CRL's relevant to them to be
retrieved by a generic PKIX-compliant RP, assuming that the mechanisms in
the certificate work as expected.  These mechanisms don't need to include,
and for practical operation probably should exclude, any directory access
except those where the entry name is supplied along with the network
location of its authoritative directory.  First, the subject certificate
must have an AIA extension containing either a caIssuers access descriptor
whose location is an LDAP URI including a host name or an HTTP Certs access
descriptor.  Second, each certificate in the chain must contain one of the
following three things: a CRL Distribution Point with a URI
DistributionPointName, an AIA extension with an OCSP access descriptor, or
an AIA extension with an HTTP CRL access descriptor.  If one condition from
each set is true, the RP can get the full set of required CA certificates
and CRL's (or status responses) from known Internet locations using a
well-defined protocol, and he gets to choose his own cross certification
path from among the ones found using the AIA method.
      I don't believe that an RP can rely on the world wide directory
working any more than you do.  Despite the implied endorsement of caIssuers
above, I don't know the format to be retrieved using either HTTP or FTP for
that access descriptor and I would have included those two mechanisms if I
could find it.  I don't see a data format for that in RFC 3280 4.2.2.1, and
I apologize for not having complained about it while that was a draft - the
format could be .p7c, but how can anyone be sure?  It's odd that YOU think
this problem requires X.500 (actually the global directory), since two of
the five solution pieces above come from "Certstore" - admittedly that's a
draft, not a standard.
      The above set of conditions are not necessarily the only ones which
will work, but they are the only ones which I can see will work without
requiring global interoperation of directories.  In particular, anybody who
has a heuristic that permits the acquisition of the full set of CA
certificates without requiring the subject certificate to have an AIA or
SIA extension is challenged to put one forward.  In the meantime, these
conditions exclude most real certificates today, and it is not plausible
that this technique will ever include all cross-certification paths,
because it relies on the presence of those certificates in a repository
known to the immediate CA.

            Tom Gindin

P.S. -      The opinions above are mine, and not necessarily those of my
employer.

                      [email-masked]                                                                                                
                      nd.ac.nz (Peter          To:       [email-masked], [email-masked], [email-masked]                       
                      Gutmann)                 cc:                                                                                     
                      Sent by:                 Subject:  Re: RFC 3280: same certificate in a certification path                        
                      owner-ietf-pkix@m                                                                                                
                      ail.imc.org                                                                                                      

                      06/26/2003 09:53                                                                                                 
                      PM                                                                                                               

Stephen Kent <[email-masked]> writes:

>Huh? the RP is responsible for acquiring the necessary certs and CRLs to
>validate a signature.

Right, and the fact that that works so well in practice is why every
widely-
used protocol that uses certs has the sender supply them.  The end user's
options are to either have the sender supply all the certs, or to wait for
X.500 (or however the receiver is supposed to find the certs it needs) to
suddenly start working.  I'll put my money on sender-supplies-certs,
thanks.

>>I'll even go so far as to say that it's OK for the receiver to deny
>>verification if the sender doesn't supply all the certificates needed.
>
>You'll be treading on very thin ice if you make this assertion.

Seems to be a sensible way to ensure that things work in the real world.

I guess I'll finish up with a quote from my home page:

  I think a lot of purists would rather have PKI be useless to anyone in
any
  practical terms than to have it made simple enough to use, but
potentially
  "flawed".
         -- Chris Zimman.

Peter.

---

From: "todd glassey" <[email-masked]>
Date: Mon, 30 Jun 2003 06:49:16 -0700

Peter - Tom - in addition to the really powerful set of verification rules
that Tom came up with here (bravo TG!), there is another problem with making
PKI acceptable to the real-world... and that problem is that this type of
verification **mandates** online services and for any number of certificate
based infrastructures.

The problem is that we as commercial users **would** really like to be able
to use x509 PKI's offline, and that also can be done. To meet this need I
would suggest that an OOB validation process using the Telephone (yes a
standard Touch Tone POTS should work just fine)...

All you would have to do is to call the number and key in the finger print
of the cert which the provider could tell you if its valid from them
currently - or could the 'responder' issue a One-Time Token to satisfy some
installer function with this certificate as part of OOB installer practice.

The way to do this is with a local OCSP or CRL responder applet that uses a
soft-token as part of the verification process based on the certs
fingerprint... or somesuch.

This simple addition to the technology base totally makes x509 certs capable
of being used offline as well as the basis of a stand-alone process...

Just my two cents

Todd Glassey

----- Original Message ----- 
From: "Tom Gindin" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Sunday, June 29, 2003 7:14 PM
Subject: Acquisition Problem Solved for some certs? (Was: Re: RFC 3280: same
certificate in a certification path)

>                       nd.ac.nz (Peter          To:
[email-masked], [email-masked], [email-masked]