RE: Security section of draft-ietf-pkix-opp-ftp-http

[lars.gu.johansson@xxxxxxxxx]

I get the feeling that we're somehow going in circles with this issue.

In order to solve the inherent problems with CRLs (off-line distribution),
OCSP was introduced. Now the relying party could check the status
of a certificate at any time by a direct question to the CA.

Why then bother with issuing of new CRLs before the old one has
expired? It doesn't sound wise to me. What legal implications will
that have given the situation where a relying party have accepted
a certificate on the basis of a current (but old) CRL? I would say that
this is also a policy issue.

And on top of this, I've also noted a new draft on how to cache OCSP
messages...

Will the circle (ever) be unbroken?

I'm afraid that we'll end up in a situation where every single information
exchanged on the Internet needs a time stamp.

Lars Johansson
Sweden Post

----------
phoffman@imc.org wrote:
>
> At 04:36 PM 4/20/98 -0700, Michael Myers wrote:
> >One the primary reasons a CRL is signed in the first place is to relieve any
> >repository containing them of security requirements.  A certificate
> >processing system determines that a CRL is expired by examining nextUpdate.
> >This value is protected by CA signature, not by presumptions of the
> >functional correctness or assurances provided by the security architecture
> >of the repository.
>
> Absolutely true. And completely unrelated to the security issue I brought up.
>
> >If a repository provides an old CRL instead of a new CRL, then one of two
> >cases will occur.  Either the old CRL is expired (as defined by nextUpdate)
> >with respect to the current system time of the certificate processing
> >software or it isn't.  If it is, an exception condition should be raised.
> >If not, the information in the old CRL is still reliable.
>
> Reliable, but probably incomplete. There are three cases, not just the two
> you describe. The third case, which I describe in my suggested wording for
> the draft, is that a CA has issued a new CRL at a time before the
> nextUpdate of the previous CRL. If the CA issued a new CRL before the
> nextUpdate time of the previous one, it is probably due to additions to the
> list. That is expressly allowed by PKIX part 1.
>
> Let me try this graphically:
>
> CRL(cRLNumber=42, thisUpdate=5/10/98, nextUpdate=6/10/98) has 300 
names on it.
> CRL(cRLNumber=43, thisUpdate=5/15/98, nextUpdate=6/10/98) has 310 
names on it.
>
> A bad HTTP proxy that has a request for the CRL has cached CRL 42. On
> 5/20/98, a request for the CRL comes in, and the proxy sends back CRL 42
> without checking with the main server. The requestor doesn't find the
> desired cert on the list and assumes it hasn't been revoked. However, that
> cert is among the 10 new certs on the list. The nextUpdate is in the
> future, so they have no reason to think that this CRL is stale.
>
> This situation has the same result as the requestor saying "hmm, since the
> nextUpdate on the CRL is in the future, I must have the current CRL," which
> is the wrong interpretation of nextUpdate, as we all know. It won't happen
> if the proxy cache does the right thing, or if there is no proxy cache, but
> if a bad proxy cache does this, there is absolutely no way for the
> requestor to find out about it. Thus, the security warning.
>
> And, yes, this is the same problem with OCSP responses in a bad proxy cache.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>