[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Authority Revocation List
Sharon,
In reply to your message of 25 Jun 97, 8:42:
> There seems to still be a few glitches in my email connectivity since
> our move. I did receive your message (I think via the PKIX list) but
> was having trouble with the bull domain yesterday and couldn't send
> mail to or receive mail from it, so I'm not too sure if my original
> response got to the list. I think things are working better today -
> we'll see with this message I guess.
>
I got your original response OK, and this one as your see - thanks.
> >Possibly my confusion lies with this sentence which I say is "out of
> >place"
>
> I do agree that the text could be clearer. My memory is sure not as
> good as it used to be, but think back to the April 96 meeting in
> Geneva. My earlier response (and your questions I believe) are
> assuming that the revocation lists are published in a Directory and
> therefore published in attributes and entries as defined in X.509 and
> X.521. We had a lot of discussion at that meeting about handling
> situations where the directory is not the publication mechanism.
>
> Isn't it the case that if revocation lists are published through some
> other mechanism (files on an http or ftp server for example) that
> there also needs to be a way to differentiate what is contained in the
> revocation list (between end user revocations and CA revocations)?
> Without the X.509 attribute types, wouldn't a revocation list
> published elsewhere be just the CertificateList syntax? In that case,
> the only way to differentiate between the two types of lists is to
> include the issuingDistributionPoint extension and the name field is
> unnecessary. Wasn't this a PKIX requirement at the time? Warwick?
> others?
I can't remember that far back but I had understood that
cRLDistributionPoint and issuingDistributionPoint applied whenever
there was a need to partition CRLs (either by subject community or
by reason) and could well include a DirectoryName for the case where
the part CRL is held in the directory.
However, I can see that it is not necessary where it is partitioned by
CA/End user community and these are held in attributes of the CA entry
as per CRL v1.
>
> If you read the current text with a non directory publication method
> for crls in mind, I think it does make sense.
>
> I'd like to hear from you and others who participated in those Geneva
> discussions though, because as they say - the memory is one of the
> first things to go :-)
>
> >> >
> >> >This is followed by a statement "If this field is absent the CRL shall
> >> >contain entries for all revoked unexpired certificates issued by the
> >> >CRL issuer." (By the way this sentence seems out of place where it is
> >> >after the description of distributionPoint in the X.509 text).
> >> ...
...
> >
> >My understanding from what you are saying and reading the standard is
> >as follows:
> >
> >a) To issue two separate CRLs for users and CAs without using
> >distribution points I must place these in CA entry attributes
> >CertificateRevocationList and AttributeRevocationList with the
> >issuingDistributionPoint containing just the elements
> >onlyContainsUserCerts or onlyContainsCACerts.
>
> If you are publishing your revocation lists in a directory using the
> attribute types defined in X.509, then the issuing distribution point
> extension is superfluous here and not required.
>
This is where I am not sure how the above sentence applies. I read it
to say that if the issuingDistributionPoint ("this field") is absent
then the CRL must be complete. However, I now see that it could also
be read to mean if the distributionPoint component of the
issuingDistributionPoint is absent (but the whole field present) then
the CRL must be complete.
> >b) To do the same using distributionPoints then I also add the
> >distributionPoint name in the issuingDistributionPoint as well as use
> >the certificate extension field cRLDistributionPoint. The
> >CRL and ARL attributes should be used as above but held in the
> >distributionPoint entry.
>
> Yes (again assuming a directory is used).
> >
> >c) With a '97 CRL if the Issuing Distribution Point CRL extension is
> >not present then both User and CA certificate revocations need to be
> >present in the CRL and this is held in the CRL attribute.
>
> No, if you are publishing in the directory you would use the two
> distinct attribute types and only need the distribution point
> extension if you are publishing in distribution point entries.
I now understand this interpretation but this still depends on the
directory being trusted. If I copy the value held in the
AuthorityRevocationList into the CertificateRevocationList without
using this extension then I can fool a user into believing that my
(end user) certificate was not revoked.
Thus, I still prefer my original interpretation that it is the value of
the "onlyContainsCACerts" which decides whether the CRL only contains
CA certificates. Not the fact whether it is placed in the
AuthorityRevocationList or CertificateRevocationList attributes.
However, I see it is reasonable to use these attributes to facilitate
access to the required data.
> >
> >d) With a '93 CRL it is undefined whether CA revocations will be
> >listed in the same CRL as user certificate revocations and hence in the
> >general case both CRL and ARL attributes should be read.
>
> I agree that the text doesn't strictly mandate what you put in each
> attribute, but believe that you would logically put the CA revocations
> in the ARL and user revocations in CRL.
>
I think that it would be worth clarifying the situation for the '93.
Unless it is clearly stated that for a complete list of user and CA
revocations two CRLs need to be retrieved then an '93 implementation
may be fooled into picking up just one CRL and believing that it has
the complete list.
.....
Nick
-------------------------------------
Security & Standards
Suite A
191 Moulsham St.
Chelmsford
Essex
CM2 0LG
U.K.
Tel: +44 1245 495018
Fax: +44 1245 494517