[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IETF-PKIX] Comment on PKIX-1
David, I agree with the additional phrase that you'd like added.
mailto:firstname.lastname@example.org Tel: (613) 247-3181
http://www.entrust.com Fax: (613) 247-3690
Orchestrating Enterprise Security
>From: Simonetti David[SMTP:simonetti_david@BAH.COM]
>Sent: December 1, 1997 9:33 AM
>Subject: Re: [IETF-PKIX] Comment on PKIX-1
>Sharon et al,
>I agree with you, and also agree with the text proposed by Tim Polk
>which is largely similar to that used in the ISO draft cert management
>standard. I was surprised when the revision of X.509 posted in October
>did not address the defect report that you generated which was accepted
>I do recommend one additional statement be added which I had discussed
>with you, Sharon, at a previous time:
>"If this extension is flagged critical and a certificate using system
>does not recognize the extension field type, then the system must
>consider the certificate invalid."
>Most might not think that there is merit in this statement, since it is
>basically the blanket statement that appears in X.509 for processing
>critical extensions. However, the conflicting opinion is that even if
>the extension is critical and cannot be processed, the processing system
>can always default to the full CRL published by the CA. I do not agree
>with this reasoning, and it is absolutely not true when the defect
>report text is entered into X.509. Hence, I recommend that it be made
>Sharon Boeyen wrote:
>> There already is a defect report issued against X.509. There was lengthy
>> debate on the X.500 list prior to submission of that defect report (back
>> about 10 months ago now) and at that time the consensus on the X.509
>> list was that the full CRL WAS still required UNLESS all certificates
>> issued by a CA contained the crlDistributionPoints extension as critical
>> AND the crlDistributionPoints themselves (as a set) addressed all
>> revocation reasons and all certificates issued by the CA. The defect
>> report only addresses that case because it was the only case the group
>> felt was a defect.
>> Why do we think that those that opposed loosening the restrictions 10
>> months ago would support it now? and what has changed in that time?
>> I still have paper copies of some of the email interactions from that
>> earlier discussion (I probably deleted the soft copies) if you're
>> interested in the nature of the debate back then. I was quite surprised
>> that more people who are on both lists didn't participate in the
>> discussion at that time.
>> Sharon Boeyen
>> Entrust Technologies
>> mailto:email@example.com Tel: (613) 247-3181
>> http://www.entrust.com Fax: (613) 247-3690
>> Orchestrating Enterprise Security
>> >From: Warwick Ford[SMTP:firstname.lastname@example.org]
>> >Sent: November 30, 1997 3:51 PM
>> >To: Sharon Boeyen; IETF-PKIX@LISTS.TANDEM.COM
>> >Subject: Re: [IETF-PKIX] Comment on PKIX-1
>> >I have discussed this issue, from the X.509 perspective, with Hoyt. He
>> >concurs with me that the fault lies in the X.509 text, in permitting one
>> >interpret that "in order to conform to X.509, a CA MUST also publish a
>> >CRL at the CA entry". This is certainly not the intent. Whether or not a
>> >CA publishes a CRL is a matter of policy. Under some policies (e.g., SET
>> >Cardholder) CRLs may never be used. Furthermore, other revocation schemes
>> >may well replace CRLs in some environments soon. We shall clarify this in
>> >a defect report at the first opportunity.
>> >Therefore, there is no need, stemming from this argument, to permit the
>> >Distribution Points extension to be critical. Given the interoperability
>> >problems that would result from making this extension critical, I see good
>> >reason to keep Part I as is.
>> >At 11:25 AM 11/28/97 -0500, Sharon Boeyen wrote:
>> >>In a final runthrough of the PKIX-1 text I noticed what I believe to be
>> >>an overlooked error.
>> >>For crlDistributionPoints PKIX-1 currently mandates that this extension
>> >>be non-critical. Surely it needs to allow that this be optionally made
>> >>If they are non-critical, then in order to conform to X.509, a CA MUST
>> >>also publish a full CRL at the CA entry, in addition to the individual
>> >>distribution points CRLs.
>> >>It is ONLY when all certs issued by a CA have the CRL Distribution
>> >>Points extension CRITICAL, that duplication of the crl info at the CA
>> >>entry as a single monstrous CRL is optional.
>> >>This is, I believe, the ONLY scaleable way to issue revocation lists
>> >>today and PKIX-1 should not mandate that it be disallowed.
>> >>Sorry for this coming in so late, but I only caught it in my final
>> >>Tim, I noticed a few minor editorials (typos etc) that I'll forward to
>> >>you separately.
>> >>Sharon Boeyen
>> >>Entrust Technologies
>> >>mailto:email@example.com Tel: (613) 247-3181
>> >>http://www.entrust.com Fax: (613) 247-3690
>> >> Orchestrating Enterprise Security
>> >>Attachment Converted: "c:\eudora\attach\%-1%Body_Rtf.rtf.ent.ent"
>> >>Attachment Converted: "c:\eudora\attach\%-1%Body_Txt.txt.ent.ent"
>> >Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>> > firstname.lastname@example.org; Tel: (617)492 2816 x225; Fax: (617)661 0716