I cannot
see why anyone would not agree with this.
The GTA infrastructure uses emergency CRLs at the root level. It is up to the relying party on
whether they check certificate status information by retrieving CRLs or using
an OCSP service, and their decision will be based on their own needs. We recommend that they use OCSP
specifically to ensure that the latest information is available (and expect
that most of the internal relying parties to use this).
Regards,
Liaquat
-----Original
Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]On
Behalf Of Roger Younglove
Sent: 15 June 2001 20:00
To: Santosh Chokhani
Cc: ietf-pkix@xxxxxxx
Subject: RE: delta CRLs - NR
assumptions
I agree with
Santosh, as long as the CP/CPS spells out how the CRLs/ delta CRLs are
published the it incumbent upon on the Relying Party to use them as they see
fit.
At 01:33 PM 06/15/2001 , Santosh Chokhani wrote:
I do not see much of any problem with
delta CRL. A CA can communicate current revocation information as
complete or as incremental.
It is up to the relying parties and the CP/CPS to determine how current the
revocation information needs to be.
Delta CRL is good mechanism. It makes lot of engineering
sense. If a CA or CP/CPS wants all relying parties to use information as
of certain time, they can do so by issuing CRLs and/or delta CRLs at define
times.
-----Original Message-----
From: Phillip Hallam-Baker [mailto:pbaker@xxxxxxxxxxxx]
Sent: Friday, June 15, 2001 12:36 PM
To: 'Denis Pinkas'; Manger, James H
Cc: ietf-pkix@xxxxxxx
Subject: RE: delta CRLs - NR assumptions
> I see a problem here. If you use delta-CRls,
I see lots of problems if you use delta CRLs. A veritable sea of troubles
bringing waves of misery and destruction upon an unhappy world.
If you want to ban anything to prevent this woe, then ban delta
CRLs, this
solution would have the considerable advantage of reducing the
size of the
RFC by several dead trees.
It is simply not possible to ban emergency CRLs. Nor do I accept
the premise
that consistency is more desirable than correct answers. If an
OCSP service
reacts on the basis of continuously updated real time data then it
will
inevitably give answers that are different (i.e. right more often)
to those
that an application relying on stale CRL data will give. Call such
behaviour
'inconsistent' if you like.
Phill
--------
TTFN
Roger W. Younglove, CISSP
Distinguished Member of Consulting Staff
Lucent Worldwide
Services--Information Security
100 Galleria
Officentre, Ste. 220
Southfield, MI 48034-8428
Numeric page: 888.935.6755
E-mail page:
page_roger_younglove@xxxxxxx
eFax number: 413.425.5368
www.lucent.com/netcare