[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt comments)
Title: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt comments)
Sharon,
Thanks
for shining some light on the X.509 delta CRL discussions. So it actually
IS
the
intent of X.509 to permit a dCRL to reference multiple base CRLs? That was
the
interpretation that I placed on the words from section
9 X.509 Ed. 4 draft v6:
"A dCRL may
also be an indirect CRL in that it may contain updated revocation
information
related to base CRLs issued by one or more than one
authorities."
I was beginning
to think I had misinterpreted the text.
Let me see if I
can figure out how these multiple base CRLs are referenced in a
dCRL.
From X.509
Section 9 : "A dCRL includes either a deltaCRLIndicator or a crlScope
extension
to indicate the base revocation information that is
being updated with this dCRL."
But the
deltaCRLIndicator extension references the base CRL
issuer only by
implication,
i.e. it is
assumed that the base CRL issuer is the same as the dCRL
issuer.
So
if a dCRL references multiple base
CRLs, it must do so via the baseRevocationInfo
component of
the crlScope extension.
From X.509 Section 9
: "Because of the
potential for conflicting information a CRL shall
not contain both
the deltaCRLIndicator extension and a crlScope
extension with the
baseRevocationInfo component."
So a
dCRL that references multiple base CRLs cannot include the deltaCRLIndicator
extension.
-
Sharon, is that right?
I
don't see anywhere in draft-ietf-pkix-new-part1-05 where it says that a delta
CRL must be
identified by a deltaCRLIndicator extension. It
does say that "The delta CRL indicator is
a
critical CRL extension that identifies a CRL as being a delta
CRL." This appears to be
a
sufficient condition, but not a necessary condition, for the CRL to be
interpreted as a
delta
CRL. So a PKIX-profile-compliant CRL-issuer could use the crlScope
extension rather
than
the deltaCRLIndicator extension to identify delta CRLs?
- Russ, is that
right?
From draft-ietf-pkix-new-part1-05 section 5.2.4:
"Both the delta CRL and the complete CRL
MUST include the CRL
number extension (see sec. 5.2.3). The CRL number
extension in the
delta CRL and the complete CRL MUST contain the same value.
"
But in order for the CRL number extension in the delta CRL and in the
complete CRL to
contain the same value, there would have to be only one base
CRL per delta CRL or
there would have to be multiple CRL number extensions in
the delta CRL (without a good
way of matching them to the base CRLs).
I
guess draft-ietf-pkix-new-part1-05 isn't intended to support multiple base CRLs
per delta CRL.
-
Russ, is that right?
Just musing ......
Regards,
Carlin
____________________________
-
Carlin Covey
Cylink Corporation
Carlin, you are correct. That 'indirect delta' is a new
facility added into the 4th edition X.509. One example that was used in those
discussions was where there might be several CAs operating within a given
domain (perhaps a large multinational organization) and each issues its own
CRLs on a regular basis. Once retrieved, these CRLs may be cached at the
validation step and used until their expiry. However, that multinational may
want to issue a single delta CRL every minute and that CRL would contain
revocation notices for all the CAs within the organization but perhaps only
for the keyCompromise reason. I think you raise an interesting point because
in this type of environment the CA that issues the delta could not issue any
single corresponding base. However, I suspect indirectDeltas are beyond the
scope of what 2459 plans to cover?
Sharon
>