[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Authority Revocation List
Nick,
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.
Comments interspersed below.
------------------
NOTE: WE'VE MOVED
Sharon Boeyen
Entrust Technologies
750 Heron Road, Suite E08
Ottawa, Ontario Canada K1V 1A7
mailto:boeyen@entrust.com Tel: (613) 247-3181
http://www.entrust.com Fax: (613) 247-3690
Orchestrating Enterprise Security
>----------
>From: Nick Pope[SMTP:pope@secstan.demon.co.uk]
>Sent: June 24, 1997 12:20 PM
>To: Sharon Boeyen
>Cc: 'OSIdirectory@az05.bull.com'; 'ietf-pkix@tandem.com'
>Subject: RE: Authority Revocation List
>
>Sharon
>
>In reply to your message of 24 Jun 97, 10:09:
>
>Thanks for your input.
>
>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?
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).
>>
>> In the version I have this phrase follows the distributionPoint
>> element of the syntax only and has nothing to do with whether crl or
>> arl are included.
>
>This is the same with my copy. However, because the sentence refers to
>"this field" I presumed it applied to the whole
>"issuingDistributionPoint" field. Not to the distributionPoint
>component of that field. Hence I thought it was more appropriate above
>the ASN.1 description. If it applies just to the distributionPoint
>then it imples that onlyContainsCACerts can't be used without
>using distributionPoints.
>
>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.
>
>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.
>
>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.
>
>Am I correct ?
>
>
>
>Nick
>
>
>> Hoyt, I tried to access the bull server to make sure
>> I have the right text and I can't - keep getting errors saying check
>> the address - I used: ftp://ftp.bull.com?
>>
>> Re the "out of place" I'm not sure I agree - this is the description
>> of the extension field to be contained in a revocation list - that is
>> not the same as the description of the crlDistributionPoint object
>> class which describes directory entries holding such lists.
>> >
>> >How is it normally expected to handle CA revocations?
>> >
>> >Is it expected that CRLs normally hold both end user and CA
>> >revocations?
>>
>> We use crl for end-user cert revocation and arl for CA cert revocation
>> - both can be placed in distribution points.
>> >
>> >If it is required to handle CA revocations separately should the CRL be
>> >placed in the Authority Revocation List attribute or should a
>> >distribution point be used?
>> >
>> >Is the Authority Revocation List attribute still relevant ?
>>
>> Yes
>> >
>> >Any views would be welcomed.
>>
>> I'm not sure where the confusion is, but to see the whole picture with
>> respect to distribution points and their use by certificate using
>> systems or relying parties, you need to look at the certificate
>> extension (crlDistributionPoints) and the revocation list extension
>> (issuingDistributionPoint) - both defined in 509. If you are using a
>> directory as a repository for certificates and crls you also need to
>> look at the attribute and object class definitions. For revocation
>> lists this includes both the arl and cxrl defined in X.509 and the
>> certificationAuthority, certificationAuthority-V2, and
>> cRLDistributionPoint object classes defined in X.521.
>>
>>
>> >
>> >Nick Pope
>> >
>> >-------------------------------------
>> >
>> >
>> >Security & Standards
>> >Suite A
>> >191 Moulsham St.
>> >Chelmsford
>> >Essex
>> >CM2 0LG
>> >U.K.
>> >
>> >Tel: +44 1245 495018
>> >Fax: +44 1245 494517
>> >
>
>-------------------------------------
>
>
>Security & Standards
>Suite A
>191 Moulsham St.
>Chelmsford
>Essex
>CM2 0LG
>U.K.
>
>Tel: +44 1245 495018
>Fax: +44 1245 494517
>