Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt

[Dale Gustafson <daleg@xxxxxxxxxxx>]

I think I agree with Marc :-)

Also, the standard should not preclude service providers from performing some
type of "synchronous" read of the CA database entry for the certificate in
question before returning the current cert-status within it's response.  It's
probably not a good idea to create a protocol that makes two distinctly different
services appear to be the same:

 1) read current CA cert-status
 2) read CRL(s), copies of CA data, etc.

BTW, are there other documents that present the big picture with respect to how
OCSP will scale over time?  I suspect that no matter how this is implemented
there will be a lot of wasted bandpass if clients always have to poll  for
cert-status.  Most OCSP transactions will result in "dry polls" that return no
new information to the cert user (e.g., cert-status hasn't changed since the last
time it was checked).

Intuitively, for OCSP to scale effectively there also needs to be a way to
proactively deliver cert-status updates to users of all kinds.  Presumably, such
updates would only be created/sent when a cert-status actually changes.  I assume
a push capability for cert-status could be the subject of another document
if/when appropriate.

Regards,

Dale Gustafson
Datakey, Inc.
407 West Travelers Trail
Burnsville, MN 55337
612.808.2360
612.890.2726 fax


------------------------
Marc Branchaud wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
>
> Content-Type: text/plain; charset=us-ascii
>
> Ambarish Malpani <ambarish@valicert.com> scrawled:
> >
> > Hi Marc,
> >     I don't agree with your first sentence. A CA might have a policy of
> > only updating its database periodically (for example because it keeps
> > the database itself offline and a read-only copy online). In that case,
> > even a responder that has direct access to the CAs database, might
> > still want to set nextUpdate.
> >
>
> It seems we have a different idea of what "direct access" means.  I won't
> debate that here, but consider that the meaning of nextUpdate in this case is
> different than it is in the CRL world.  In this case, there's no possibility
> of fresh information being available before nextUpdate.  As such, a client
> might get confused and apply CRL-like semantics to the value, and might try
> to query the responder before nextUpdate even though there's no way that any
> new information will be returned.
>
> I'm not saying that this "update period" information is unimportant or
> useless.  But stuffing it into a field that is to be interpreted the same
> way as a CRL's nextUpdate value is wrong.
>
> > In a spec like this, I would rather tell people what it means if they
> > do something rather than dictate policy to them.
> >
>
> I agree completely.  That's why I'm arguing so much about this stuff.
> nextUpdate has to be made clear or it will get misinterpreted and people
> will get burned by it.
>
>                 Marc
>
> +------------------------------------------------------------------------+
>  Marc Branchaud                                  \/
>  Chief PKI Architect                             /\CERT INTERNATIONAL INC.
>  marcnarc@xcert.com        PKI References page:              www.xcert.com
>  604-640-6227          www.xcert.com/~marcnarc/PKI/
> +------------------------------------------------------------------------+
>   PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
>
> iQB1AwUBNUpTS1rdFXNdDxPlAQHtwQMAlk3n1JOSr7Qjn/oWHF4ndBPPOcQr/2xn
> boOytgmivp0uoufW9tFS1hWubO8gAD4UJ5EbeZV7qu8Y1uQ4d5Xcl5ulG587v/0K
> fwcrXYR89qZvM9pK9D+WIo2GuVZyXFIa
> =Obaz
> -----END PGP SIGNATURE-----