From owner-ietf-pkix Wed Jan 1 23:10:32 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h027AWa11824 for ietf-pkix-bks; Wed, 1 Jan 2003 23:10:32 -0800 (PST) Received: from ausyms50.ca.com ([155.35.248.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h027ASo11797 for ; Wed, 1 Jan 2003 23:10:29 -0800 (PST) content-class: urn:content-classes:message Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option) Date: Thu, 2 Jan 2003 18:11:20 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LDAP PKI Schema (was Re: No-op LDAP ;binary option) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Index: AcKwpVnBx4b2bnqaSlOvmQN8ZmEDqABiGzzg From: "Ramsay, Ron" To: "Kurt D. Zeilenga" , "Peter Gietz" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h027ATo11803 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Component matching, however, does not address the problem of returning multiple certificates. That is, if component matching were to be used, and if the entry contains a matching certificate, then all certificates in the entry would be returned. Using subordinate entries ensures only one certificate is returned. Ron. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Tuesday, 31 December 2002 18:38 To: Peter Gietz Cc: ietf-pkix@imc.org Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option) >Nevertheless two different solutions to one problem might be preferable here. My primary objection to standardizing the child entry approach for PKI is that it is a PKI-specific solution to a general problem, component matching of complex attribute values. We should be looking for general solutions to our general problems. Steven's component matching I-D details a general solution which I believe is suitable for standardization. My recommendation is that the PKI "child entry" approach be pursued individually as an Experimental (or possibly Informational) solution to the PKI component matching problem with a note that a more general solution, component matching, is being standardized. Kurt From owner-ietf-pkix Thu Jan 2 09:01:48 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h02H1mg03392 for ietf-pkix-bks; Thu, 2 Jan 2003 09:01:48 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h02H1ko03388 for ; Thu, 2 Jan 2003 09:01:46 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id h02H1a0a097934; Thu, 2 Jan 2003 17:01:40 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030102085547.01d3e8d8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 02 Jan 2003 09:01:25 -0800 To: "Ramsay, Ron" From: "Kurt D. Zeilenga" Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option) Cc: "Peter Gietz" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:11 PM 1/1/2003, Ramsay, Ron wrote: >Component matching, however, does not address the problem of returning multiple certificates. We have a general solution to that general problem in the LDAP matched values control extension [draft-ietf-ldapext-matchedval]. Kurt >Ron. > >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Tuesday, 31 December 2002 18:38 >To: Peter Gietz >Cc: ietf-pkix@imc.org >Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option) > > > > >>Nevertheless two different solutions to one problem might be preferable here. > >My primary objection to standardizing the child entry approach >for PKI is that it is a PKI-specific solution to a general problem, >component matching of complex attribute values. We should be >looking for general solutions to our general problems. Steven's >component matching I-D details a general solution which I believe >is suitable for standardization. > >My recommendation is that the PKI "child entry" approach be >pursued individually as an Experimental (or possibly Informational) >solution to the PKI component matching problem with a note that >a more general solution, component matching, is being standardized. > >Kurt From owner-ietf-pkix Thu Jan 2 11:27:37 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h02JRbZ14433 for ietf-pkix-bks; Thu, 2 Jan 2003 11:27:37 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h02JRao14426 for ; Thu, 2 Jan 2003 11:27:36 -0800 (PST) Received: (qmail 18814 invoked from network); 2 Jan 2003 19:27:16 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.179.117) by woodstock.binhost.com with SMTP; 2 Jan 2003 19:27:16 -0000 Message-Id: <5.2.0.9.2.20030102141317.021b8d58@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 02 Jan 2003 14:27:28 -0500 To: tgindin@us.ibm.com From: Russ Housley Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-03.txt Cc: ietf-pkix@imc.org, jjacoby@rsasecurity.com, pgut001@cs.auckland.ac.nz In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom: RFC 3280 says that subjectAltName extension using the rfc822Name is the way that an email address SHOULD be included in a certificate. I would like to see the text reinforces this, but says that there are certificates that use other placements. Russ At 07:06 PM 12/23/2002 -0500, Tom Gindin wrote: > How about mentioning the other two normal ways of storing the email >address: "This is typically stored in the certificate either within the >subject DN as a value of one of the attributes rfc822mailbox or >emailAddress, or in the subjectAltName extension using the rfc822Name >choice of GeneralName". I've personally never seen anyone use any other >way than those three. > > Tom Gindin > > >pgut001@cs.auckland.ac.nz (Peter Gutmann)@mail.imc.org on 12/20/2002 >09:10:32 PM > >Sent by: owner-ietf-pkix@mail.imc.org > > >To: ietf-pkix@imc.org, jjacoby@rsasecurity.com >cc: >Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-03.txt > > > >Jeff Jacoby writes: > > >Is it necessary to require an exact match for all attributes, particularly > >for such attributes as the email and name attributes? > >In a word, yes. > > >For example, I'm looking for the cert for Bill Williams, but I don't know >if > >the common name is "Bill Williams" or "Will Williams" or "B. Williams", >etc, > >so I might like to try a search on just "Williams" > >How would you specify this? You'd need some sort of general-purpose >pattern- >matching mechanism and then a means of mapping it to every possible backend >that might be used to implement the lookup. The draft specifies a >universal >interface to (conceptually) a basic key-and-value lookup engine, which >doesn't >extend to general pattern-matching. If you need anything more than this >(for >example searching on compound attributes and similar things) you should >really >use LDAP. > > >Secondly, the entry for email attribute indicates the value as: > > > > "Subject email address contained in the certificate, typically as an > > rfc882Name attribute > > > >Is it necessary the email attribute be from the certificate. Is it a > >reasonable or likely situation that a certificate store might use the >email > >address as an database index even though it's not actually in the > >certificate? > >I'd never thought of it being done like that, but I can easily change the >text >to accomodate it. How about: > > Subject email address associated with the certificate. This is typically > stored in the certificate as an rfc882Name attribute. > >Peter. From owner-ietf-pkix Thu Jan 2 15:32:19 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h02NWJs29895 for ietf-pkix-bks; Thu, 2 Jan 2003 15:32:19 -0800 (PST) Received: from ausyms50.ca.com ([155.35.248.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h02NWIo29891 for ; Thu, 2 Jan 2003 15:32:18 -0800 (PST) content-class: urn:content-classes:message Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option) Date: Fri, 3 Jan 2003 10:33:09 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LDAP PKI Schema (was Re: No-op LDAP ;binary option) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Index: AcKygKFJiin3OL53QQykr8vpd1d6lwANnz3A From: "Ramsay, Ron" To: "Kurt D. Zeilenga" Cc: "Peter Gietz" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h02NWIo29892 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I know, but is it widely implemented? -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Friday, 3 January 2003 04:01 To: Ramsay, Ron Cc: Peter Gietz; ietf-pkix@imc.org Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option) At 11:11 PM 1/1/2003, Ramsay, Ron wrote: >Component matching, however, does not address the problem of returning multiple certificates. We have a general solution to that general problem in the LDAP matched values control extension [draft-ietf-ldapext-matchedval]. Kurt >Ron. > >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Tuesday, 31 December 2002 18:38 >To: Peter Gietz >Cc: ietf-pkix@imc.org >Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option) > > > > >>Nevertheless two different solutions to one problem might be preferable here. > >My primary objection to standardizing the child entry approach >for PKI is that it is a PKI-specific solution to a general problem, >component matching of complex attribute values. We should be >looking for general solutions to our general problems. Steven's >component matching I-D details a general solution which I believe >is suitable for standardization. > >My recommendation is that the PKI "child entry" approach be >pursued individually as an Experimental (or possibly Informational) >solution to the PKI component matching problem with a note that >a more general solution, component matching, is being standardized. > >Kurt From owner-ietf-pkix Thu Jan 2 16:28:01 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h030S1l05163 for ietf-pkix-bks; Thu, 2 Jan 2003 16:28:01 -0800 (PST) Received: from ausyms50.ca.com ([155.35.248.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h030S0o05158 for ; Thu, 2 Jan 2003 16:28:00 -0800 (PST) content-class: urn:content-classes:message Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option) Date: Fri, 3 Jan 2003 11:28:52 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LDAP PKI Schema (was Re: No-op LDAP ;binary option) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Index: AcKygKFJiin3OL53QQykr8vpd1d6lwANnz3AAAHTxNA= From: "Ramsay, Ron" To: "Kurt D. Zeilenga" Cc: "Peter Gietz" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h030S0o05159 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Actually, it may not matter whether it is widely implemented. Because we wish to use component matching in matched-values, it will probably require any servers implementing matched-values to be rewritten to allow component-match in matched-values. -----Original Message----- From: Ramsay, Ron Sent: Friday, 3 January 2003 10:33 To: Kurt D. Zeilenga Cc: Peter Gietz; ietf-pkix@imc.org Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option) I know, but is it widely implemented? -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Friday, 3 January 2003 04:01 To: Ramsay, Ron Cc: Peter Gietz; ietf-pkix@imc.org Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option) At 11:11 PM 1/1/2003, Ramsay, Ron wrote: >Component matching, however, does not address the problem of returning multiple certificates. We have a general solution to that general problem in the LDAP matched values control extension [draft-ietf-ldapext-matchedval]. Kurt >Ron. > >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Tuesday, 31 December 2002 18:38 >To: Peter Gietz >Cc: ietf-pkix@imc.org >Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option) > > > > >>Nevertheless two different solutions to one problem might be preferable here. > >My primary objection to standardizing the child entry approach >for PKI is that it is a PKI-specific solution to a general problem, >component matching of complex attribute values. We should be >looking for general solutions to our general problems. Steven's >component matching I-D details a general solution which I believe >is suitable for standardization. > >My recommendation is that the PKI "child entry" approach be >pursued individually as an Experimental (or possibly Informational) >solution to the PKI component matching problem with a note that >a more general solution, component matching, is being standardized. > >Kurt From owner-ietf-pkix Thu Jan 2 16:43:40 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h030hed06984 for ietf-pkix-bks; Thu, 2 Jan 2003 16:43:40 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h030hco06977 for ; Thu, 2 Jan 2003 16:43:38 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id h030hX0a099764; Fri, 3 Jan 2003 00:43:34 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030102154220.030316b0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 02 Jan 2003 16:43:22 -0800 To: "Ramsay, Ron" From: "Kurt D. Zeilenga" Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option) Cc: "Peter Gietz" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 03:33 PM 1/2/2003, Ramsay, Ron wrote: >I know, but is it widely implemented? Given that it is still a work in progress, I hope not! But there are early implementations which have provided the operational experience that the approach is general useful and otherwise suitable for standardization. Same is true for component matching. I hope the IESG will approve both soon. Kurt >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Friday, 3 January 2003 04:01 >To: Ramsay, Ron >Cc: Peter Gietz; ietf-pkix@imc.org >Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option) > > >At 11:11 PM 1/1/2003, Ramsay, Ron wrote: >>Component matching, however, does not address the problem of returning multiple certificates. > >We have a general solution to that general problem in the LDAP >matched values control extension [draft-ietf-ldapext-matchedval]. > >Kurt > > >>Ron. >> >>-----Original Message----- >>From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >>Sent: Tuesday, 31 December 2002 18:38 >>To: Peter Gietz >>Cc: ietf-pkix@imc.org >>Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option) >> >> >> >> >>>Nevertheless two different solutions to one problem might be preferable here. >> >>My primary objection to standardizing the child entry approach >>for PKI is that it is a PKI-specific solution to a general problem, >>component matching of complex attribute values. We should be >>looking for general solutions to our general problems. Steven's >>component matching I-D details a general solution which I believe >>is suitable for standardization. >> >>My recommendation is that the PKI "child entry" approach be >>pursued individually as an Experimental (or possibly Informational) >>solution to the PKI component matching problem with a note that >>a more general solution, component matching, is being standardized. >> >>Kurt From owner-ietf-pkix Fri Jan 3 05:32:04 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03DW4M08446 for ietf-pkix-bks; Fri, 3 Jan 2003 05:32:04 -0800 (PST) Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03DVxo08435 for ; Fri, 3 Jan 2003 05:32:00 -0800 (PST) Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by maile.telia.com (8.12.5/8.12.5) with SMTP id h03DVnFg009260; Fri, 3 Jan 2003 14:31:52 +0100 (CET) X-Original-Recipient: ietf-pkix@imc.org Message-ID: <009101c2b32c$384082c0$0500a8c0@arport> From: "Anders Rundgren" To: , "Alice Sturgeon" Cc: "Denis Pinkas" , , Subject: RFC and then...? draft-ietf-pkix-warranty-extn-01.txt Date: Fri, 3 Jan 2003 14:29:57 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008E_01C2B334.9753D480" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_008E_01C2B334.9753D480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alice et al. To create a standard in the IT-sector it is actually rather easy, and = I'm sure that you without too much troubles can get the warranty = extension through the IETF processes. But, the real problem is [always] to get any major use of a standard. In this particular case the "critical mass" problem is very hard as it = requires both CAs, core software makers, and application makers to think = this is a great idea. Unless VeriSign, and similar market-leaders have = expressed some support for this extension, I think it will from a = usage-point of view fail, because why would anybody implement a = non-technical ("soft") option that only a minor percentage of CAs are = likely to support? Another problem is that this option is anything but trivial to implement = in a useful way. If this is going to be transparently supported by = interactive client/browser-side signatures, featuring pop-up dialogs = etc, this probably even creeps into the core signature API and = processes. Added to that we have the principal difficulties mentioned by me and = Denis. A CA liability extension OTOH is an unilateral CA-decision to deploy, = that since it should just be like an in-line agreement, does not require = any application-level RP-software support. When I think of it, the only = reasonable place for a liability extension is in a CA certificate, as it = is during the "trust installation/CA acceptance" phase, you should be = made aware of CA conditions. To have different liabilities in = EE-certificates would be counterproductive, as it would then require the = same kind of extensive and also slightly "yucky" software support, as = imposed by the warranty-extension. Best Anders Rundgren Senior Internet e-Commerce Architect=20 ------=_NextPart_000_008E_01C2B334.9753D480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <= ![if !supportEmptyParas]>
Alice et al.
 
To create a standard in the IT-sector = it is=20 actually rather easy, and I'm sure = that you=20 without too much troubles can get the warranty extension through the = IETF=20 processes.
 
But, the real problem is [always] to = get any major=20 use of a standard.
 
In this particular case the "critical = mass" problem=20 is very hard as it requires both CAs, core software makers, and = application makers to think this is a great idea.  Unless VeriSign, = and=20 similar market-leaders have expressed some support for this extension, I = think=20 it will from a usage-point of view fail, because why would = anybody=20 implement a non-technical ("soft") option that only a minor = percentage=20 of CAs are likely to support?
 
Another problem is that this option = is anything=20 but trivial to implement in a useful way.  If this is going to = be=20 transparently supported by interactive client/browser-side signatures, = featuring=20 pop-up dialogs etc, this probably even creeps into the core signature = API and=20 processes.
 
Added to that we have the principal = difficulties=20 mentioned by me and Denis.
 
A CA liability extension OTOH is an = unilateral=20 CA-decision to deploy, that since it should just be like an in-line = agreement,=20 does not require any application-level RP-software support.  When I = think=20 of it, the only reasonable place for a liability extension is in a = CA=20 certificate, as it is during the "trust installation/CA acceptance" = phase,=20 you should be made aware of CA conditions.  To have different = liabilities=20 in EE-certificates would be counterproductive, as it would then require = the same=20 kind of extensive and also slightly "yucky" software support, as = imposed by=20 the warranty-extension.

Best
Anders=20 Rundgren
Senior Internet e-Commerce Architect =
------=_NextPart_000_008E_01C2B334.9753D480-- From owner-ietf-pkix Fri Jan 3 07:19:46 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03FJkI18407 for ietf-pkix-bks; Fri, 3 Jan 2003 07:19:46 -0800 (PST) Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03FJjo18402 for ; Fri, 3 Jan 2003 07:19:45 -0800 (PST) Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by maile.telia.com (8.12.5/8.12.5) with SMTP id h03FJjCO005226; Fri, 3 Jan 2003 16:19:45 +0100 (CET) X-Original-Recipient: ietf-pkix@imc.org Message-ID: <00fa01c2b33b$4a16dd50$0500a8c0@arport> From: "Anders Rundgren" To: , References: Subject: CA Liability vs. Warranty in practice / draft-ietf-pkix-warranty-extn-01.txt Date: Fri, 3 Jan 2003 16:17:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alice, Assume that an RP has suffered from a CA certification error. Assume the RP has trusted a faulty purchase order which costed them (approximately) $10000 to cancel. 1. What would loosely be the practical difference for the RP between a CA warranty of $25000 and a CA liability of $25000? 2. And if these were ZERO? 3. And if the certification error was due to an imposter? Without nailing such basics firmly, I can't really see the "thin line" that seems to be dividing us. I believe I'm not alone having problems with warranties for indirect damages rather than for the product itself. Cheers, Anders Rundgren Senior Internet e-Commerce Architect From owner-ietf-pkix Fri Jan 3 07:37:13 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03FbDY21365 for ietf-pkix-bks; Fri, 3 Jan 2003 07:37:13 -0800 (PST) Received: from mail.slb.com (nammta01.sugar-land.nam.slb.com [163.188.150.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03Fb9o21294 for ; Fri, 3 Jan 2003 07:37:09 -0800 (PST) Received: from conversion-daemon.nammta01.sugar-land.nam.slb.com by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) id <0H8500A019WFT5@nammta01.sugar-land.nam.slb.com> for ietf-pkix@imc.org; Fri, 03 Jan 2003 15:37:04 +0000 (GMT) Received: from namems01.sugar-land.oilfield.slb.com (namems01.sugar-land.oilfield.slb.com [163.188.150.131]) by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) with ESMTP id <0H8500C2FA1D2L@nammta01.sugar-land.nam.slb.com> for ietf-pkix@imc.org; Fri, 03 Jan 2003 15:36:49 +0000 (GMT) Received: from conversion-daemon.namems01.sugar-land.oilfield.slb.com by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov 1 2002)) id <0H8500K019WF7W@namems01.sugar-land.oilfield.slb.com> for ietf-pkix@imc.org; Fri, 03 Jan 2003 15:36:48 +0000 (GMT) Received: from SCHLUMBE-HJ7VF7.HOUSTON-OMH (vpnpool851.houston.sinet.slb.com [163.188.127.83]) by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov 1 2002)) with ESMTP id <0H8500HAI9WJKH@namems01.sugar-land.oilfield.slb.com>; Fri, 03 Jan 2003 15:33:57 +0000 (GMT) Date: Fri, 03 Jan 2003 10:34:52 -0500 From: Mitchell Arnone Subject: RE: Offline Root CA with valid CRL hierachie In-reply-to: X-Sender: marnone@pop.parsippany.sns.slb.com To: Ambarish Malpani , "David P. Kemp" , ietf-pkix@imc.org Message-id: <5.1.1.1.2.20030102083604.0497d280@pop.parsippany.sns.slb.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <5.1.1.1.2.20021230193725.04ad1ab8@pop.parsippany.sns.slb.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ambarish, I completely agree with you. This is an ongoing issue when designing and building secure and reliable PKI implementations. How often a client or service provider (both as relying parties) retrieves an updated CRL is dependant on the intended use of the PKI. It all comes down to risk mitigation and associated costs. If you are protecting highly sensitive information then maybe you need to support frequent checking of CRLs and if this is the case then maybe you need to deploy a LDAP farm fronted by some sort of HA device or maybe you deploy a smaller scale LDAP deployment and push certificate status checking to an OCSP responder which too may be integrated into an HA solution. However, this can become very costly and if the cost outweighs the value of the information being protected, then there needs to be a balancing act between cost and risk. Relying parties, especially service providers, need to be configurable allowing an administrator to determine the frequency in which an updated CRL is fetched. There may be a situation where different relying parties have different intervals, based on risk. In addition, administrators must be able to issue a command to the service front end (that is responsible for CRL checking) telling it to go out and fetch a new CRL immediately. This is important for these cases when there is an emergency revocation early in the validity period of a CRL. In most CP/CPS documents, reference is made to emergency certificate revocation and notification of relying parties in such cases. However, if the relying party either cannot or does not effect an immediate retrieval of an update CRL, then emergency revocation procedures are useless. Mitch At 04:52 PM 12/31/2002, Ambarish Malpani wrote: >Hi Mitchell, > As a CA, you can tell the RP (relying party) that it is >responsible for fetching the latest CRL. If you then give it >no way of knowing when to get a new CRL, any serious security >client would keep checking for a new CRL *every* time it needed >to validate a certificate/certification path. > >As a root CA, it is very unlikely that your directory could handle >the load you would get from every client trying to get your latest >CRL for every certificate that chains up to you (*distribution* is >the real scalability problem with CRLs - as opposed to OCSP - not >generation). > >Regards, >Ambarish > >--------------------------------------------------------------------- >Ambarish Malpani 650.759.9045 >Malpani Consulting Services ambarish@malpani.biz >http://www.malpani.biz > > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Mitchell Arnone > > Sent: Monday, December 30, 2002 5:13 PM > > To: David P. Kemp; ietf-pkix@imc.org > > Subject: Re: Offline Root CA with valid CRL hierachie > > > > > > > > Dave, > > > > This sounds like a very complex technical solution that > > circumvents proper > > procedures designed to maintain a significantly high level of > > assurance. The Root CA is the root of trust and therefore must > > live up to > > the highest level of assurance attested to by a particular PKI. > > > > CRLs must be generated on the date and at the time they become > > effective. Predicting contents of a CRL and generating them in advance > > leaves much room and opportunity to render a PKI untrustworthy. > > > > A CRL can be generated by an off-line Root CA where the next > > update can be > > one day, one month or even one year from the date contained in > > "thisUpdate". Depending on this setting, and assuming that no > > subordinate > > CA certificates have been revoked prior to the normally scheduled update > > period, the off-line Root CA can be brought on-line allowing it > > to generate > > and publish a fresh CRL. In the event that a subordinate CA > > certificate is > > revoked, obviously the Root CA must brought on-line to do so and > > immediately following the revocation, the Root CA can generate > > and publish > > an updated CRL. This is the proper way to handle an Off-line Root CA. > > > > The burden of obtaining a current CRL is on the Relying Party > > where it must > > periodically refresh its CRL regardless of whether the "nextUpdate" has > > been reached or not. A Relying Party can flush its cache at prescribed > > intervals and then retrieve a new (updated) CRL as required. > > > > Mitch > > > > At 11:01 AM 12/30/2002, David P. Kemp wrote: > > > > >Because revocation of a signing CA should be very rare event, the > > >offline root can take advantage of a "long pipeline" to minimize > > >the human effort required to transport disks of CRLs to an online > > >repository. The root could pre-generate, say, one week's worth of > > >empty daily CRLs (where nextUpdate = thisUpdate + 1 day) and put > > >the 7 CRLs on media. The repository would then be responsible > > >for doling out the correct CRL each day and not publishing any > > >CRL for which thisUpdate is in the future. > > > > > >In the event of a CA compromise, the pipeline would need to be > > >flushed - future CRLs in the repository would be destroyed and > > >the root CA would generate a new batch of CRLs on media. > > > > > >This assumes that compromise of the online repository (allowing > > >access to CRLs up to 7 days in the future) is a much less serious > > >event than compromise of the offline root CA. I believe that > > >assumption is valid and supportable. > > > > > >Dave > > > > > > > > > > > > > > >Al Arsenault wrote: > > > > > > > > Okay, I'm a little confused here. This problem isn't really > > all that hard > > > > to solve. My comments/questions are in-line, prefaced by my initials, > > > "AWA". > > > > > > > > ----- Original Message ----- > > > > From: "Haaino Beljaars" > > > > To: "Mark Scherling" > > > > Cc: > > > > Sent: Monday, December 23, 2002 6:36 AM > > > > Subject: Re: Offline Root CA with valid CRL hierachie > > > > > > > > > > > > > > > You can still publish a CRL for an off-line CA. You will need to > > > > > establish > > > > > > a fairly long expiry time for the CRL if you do not plan to bring > > > the CA > > > > > > on-line often. In many cases the Root CA is off-line and > > only used to > > > > > issue > > > > > > new intermediary CAs or revoke intermediary CAs. You will need to > > > > > establish > > > > > > a very good procedure for startup and shutdown of the root CA (two > > > > person > > > > > > control, locked in a safe, two person combination on the safe, > > > > documenting > > > > > > each time the CA is removed, etc. ) The reason for > > documenting the > > > > > process > > > > > > is for audit purposes. > > > > > > > > > > > > You will also need to document in your CP that the CA is > > off-line and > > > > that > > > > > > the onus is on the relying party to verify that an > > intermediary CA is > > > > > still > > > > > > valid. > > > > > > > > > > > > > AWA: Let's first clarify terms. What, exactly, do you mean > > by "off-line > > > > CA"? To me, that term means that the CA is not connected to a larger > > > > network (specifically, it's not connected to the Internet or > > larger telecom > > > > network through which it can be accessed). It's still > > running, locked in > > > > its secure facility somewhere. That is, start-up/shut-down is not an > > > issue; > > > > it's already running. Is that what you mean, or is there > > something else? > > > > > > > > > I agree that you still publish a valid CRL for an offline > > Root CA. The > > > > > problem is the following, > > > > > example: I issue an CRL with the Root CA with a validity of > > for example a > > > > > month, and after > > > > > issuing the CRL I take it offline. During that month, for > > example after > > > > two > > > > > weeks, one of the > > > > > intermediate CA's is compromised and I have to revoke that CA. > > > > > According to the specs I can only issue a CRL which has a > > validity time > > > > that > > > > > starts after > > > > > current one. > > > > > > > > AWA: I'm not sure you're interpreting RFC 3280 correctly. Paragraph > > > > 5.1.2.5 starts: > > > > > > > > 5.1.2.5 Next Update > > > > > > > > This field indicates the date by which the next CRL will be issued. > > > > The next CRL could be issued before the indicated date, but it will > > > > not be issued any later than the indicated date. CRL > > issuers SHOULD > > > > issue CRLs with a nextUpdate time equal to or later than > > all previous > > > > CRLs. nextUpdate may be encoded as UTCTime or GeneralizedTime. > > > > > > > > That is, you can only issue a CRL whose "thisUpdate" time is > > later than the > > > > previous one, and whose nextUpdate time is equal to or later > > than those on > > > > previous CRLs (although that latter part is not required). There's no > > > > reason why you have to wait until the current CRL expires to > > issue the new > > > > one. > > > > > > > > >This means in practise that I have a valid intermediate CA for > > > > > over two weeks, > > > > > but in reality that intermediate CA is revoked. How can I > > let everybody > > > > know > > > > > during that > > > > > two week period that the intermediate CA is compromised, taking in > > > > > account:"Conforming > > > > > applications are NOT REQUIRED to support processing of delta CRLs, > > > > indirect > > > > > CRLs, or CRLs > > > > > with a scope other than all certificates issued by one CA"? > > > > > > > > > > > > > AWA: Okay, here's how I've solved this problem in the past. > > The root CA, > > > > while off-line, is running in its secure facility. When it > > is necessary to > > > > revoke an intermediate CA, the root CA is accessed to create > > a new CRL. > > > > This CRL is dumped to some medium, either burned onto a CD or > > put onto a > > > > floppy. This medium is then hand-carried (the term we used > > to use was > > > "sent > > > > via sneaker-net") to a server that is on the network. It can > > be either > > > made > > > > available as a CRL from, e.g., an LDAP repository; or it can > > be provided to > > > > an OCSP responder. > > > > > > > > The rest is up to your revocation policy. If you rely only on CRLs, > > > and you > > > > allow users to cache CRLs until the end of their validity > > period (e.g., > > > > until their "nextUpdate" time), then yes, you have in your scenario a > > > > two-week window of vulnerability where users think an > > intermediate CA is > > > > good but it's really not. That's a risk you take by relying > > only on static > > > > CRLs with that long a validity period. (Of course, one would hope that > > > > revocation of an intermediate CA would be an extremely rare > > event, so the > > > > overall system risk/cost tradeoff may be acceptable, but...) > > > > > > > > On the other hand, you can use an OCSP-based system, where > > users query the > > > > responder and will discover that the intermediate CA has been > > revoked the > > > > first time they query its status. OR you can use CRLs with a > > shorter life > > > > cycle. Depending on what you're willing to pay in "human > > capital" costs, > > > > there's no reason you can't have the off-line CA issue a new CRL - > > > generally > > > > identical to the previous one - as often as you want; e.g., > > every day, > > > every > > > > 4 hours, whatever. It just costs you to have the human move > > the medium - > > > > floppy, CD - from the off-line CA to the network-connected > > > repository. It's > > > > not that hard. > > > > > > > > > Best regards, > > > > > Haaino > > > > > > > > > > > > > Hope this helps. > > > > > > > > Al Arsenault > > > > Chief Security Architect > > > > Diversinet Corp. > > > > *********************************************************** > > Mitchell Arnone > > Managing Consultant > > SchlumbergerSema > > Technical Consulting Practice, Northeast Region > > Network & Infrastructure Solutions > > > > marnone@parsippany.sns.slb.com > > www.slb.com/nws > > > > 35 Waterview Blvd. > > Suite 210 > > Parsippany, NJ 07054-1200 > > USA > > > > Phone +1 410-579-8691 > > Mobile +1 443-864-1590 > > > > *********************************************************** Mitchell Arnone Managing Consultant SchlumbergerSema Technical Consulting Practice, Northeast Region Network & Infrastructure Solutions marnone@parsippany.sns.slb.com www.slb.com/nws 35 Waterview Blvd. Suite 210 Parsippany, NJ 07054-1200 USA Phone +1 410-579-8691 Mobile +1 443-864-1590 From owner-ietf-pkix Fri Jan 3 07:57:25 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03FvPW23035 for ietf-pkix-bks; Fri, 3 Jan 2003 07:57:25 -0800 (PST) Received: from mail.slb.com (nammta01.sugar-land.nam.slb.com [163.188.150.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03FvMo23030 for ; Fri, 3 Jan 2003 07:57:24 -0800 (PST) Received: from conversion-daemon.nammta01.sugar-land.nam.slb.com by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) id <0H8500901AXXST@nammta01.sugar-land.nam.slb.com> for ietf-pkix@imc.org; Fri, 03 Jan 2003 15:57:19 +0000 (GMT) Received: from namems01.sugar-land.oilfield.slb.com (namems01.sugar-land.oilfield.slb.com [163.188.150.131]) by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) with ESMTP id <0H85004XDAZJTT@nammta01.sugar-land.nam.slb.com> for ietf-pkix@imc.org; Fri, 03 Jan 2003 15:57:19 +0000 (GMT) Received: from conversion-daemon.namems01.sugar-land.oilfield.slb.com by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov 1 2002)) id <0H8500K019WF7W@namems01.sugar-land.oilfield.slb.com> for ietf-pkix@imc.org; Fri, 03 Jan 2003 15:57:19 +0000 (GMT) Received: from SCHLUMBE-HJ7VF7.HOUSTON-OMH (vpnpool851.houston.sinet.slb.com [163.188.127.83]) by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov 1 2002)) with ESMTP id <0H8500F5TAY7N8@namems01.sugar-land.oilfield.slb.com>; Fri, 03 Jan 2003 15:56:36 +0000 (GMT) Date: Fri, 03 Jan 2003 10:57:28 -0500 From: Mitchell Arnone Subject: RE: Offline Root CA with valid CRL hierachie In-reply-to: <001c01c2b0e5$42b60660$a200a8c0@Chokhani> X-Sender: marnone@pop.parsippany.sns.slb.com To: Santosh Chokhani , ietf-pkix@imc.org Message-id: <5.1.1.1.2.20030103103527.02248150@pop.parsippany.sns.slb.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <5.1.1.1.2.20021230193725.04ad1ab8@pop.parsippany.sns.slb.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh, In todays world, CRL publication is very straight forward. The idea presented by Dave would require additional functionality built into the CA to: 1-publish not only the current CRL but many others in advance then 2-procedures must be developed on who, how, when and where those CRLs will be stored and managed and then 3-some other process/procedure must put into place to replace expired CRLs with the "current" one and 4-there must be even more procedures describing what to do if there is a CA revocation... like destroying all existing CRLs and generating a list of new ones. The complexity comes in adding numerous new procedures which simply may not be necessary. These procedures, as described below, are manual and if we are to support a secure and reliable infrastructure, the human element must be reduced if not eliminated and to do so, major revisions to CA system could be required. I am struggling to see how publishing 30 one-day CRLs and storing them on some off-line media is more secure than publishing a single 30 day CRL. The reaction to a CA revocation will be the same in both scenarios because the ROOT CA will have to be brought on-line to execute the revocation process and produce new updated CRLs before going back off-line. Mitch At 10:57 AM 12/31/2002, Santosh Chokhani wrote: >Mitch: > >What I interpreted from Dave's e-mail is as follows: > >1. For operational security and operational workload reasons, we may not >want to bring the off-line Root on-line to generate the CRL too often. > >2. For security reasons, we also want the Root CRL to have a relatively >current nextUpdate (vice one month or one year from now). > >3. To meet these two, the root CA generates a bunch of CRLs in advance with >thisUpdate not of the current time, but desired times in the future and >nextUpdate also of various desired times in the future. > >4. One can put these CRLs on portable media and control them under the same >physical and procedural controls that Root CA and associated private key >activation is controlled. > >5. Most of the time, a CA will not be revoked and hence the proper portable >medium can be carried to the repository and CRL published. > >6. If a CA is revoked, root CA will be booted up, all the portable media >will be erased and root CA will generate a bunch of new CRLs using step 3. > >This does not sound technically complex to me. It does require some >procedural controls for additional items, namely portable media for the >future CRLs. > >-----Original Message----- >From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On >Behalf Of Mitchell Arnone >Sent: Monday, December 30, 2002 8:13 PM >To: David P. Kemp; ietf-pkix@imc.org >Subject: Re: Offline Root CA with valid CRL hierachie > > > >Dave, > >This sounds like a very complex technical solution that circumvents proper >procedures designed to maintain a significantly high level of >assurance. The Root CA is the root of trust and therefore must live up to >the highest level of assurance attested to by a particular PKI. > >CRLs must be generated on the date and at the time they become >effective. Predicting contents of a CRL and generating them in advance >leaves much room and opportunity to render a PKI untrustworthy. > >A CRL can be generated by an off-line Root CA where the next update can be >one day, one month or even one year from the date contained in >"thisUpdate". Depending on this setting, and assuming that no subordinate >CA certificates have been revoked prior to the normally scheduled update >period, the off-line Root CA can be brought on-line allowing it to generate >and publish a fresh CRL. In the event that a subordinate CA certificate is >revoked, obviously the Root CA must brought on-line to do so and >immediately following the revocation, the Root CA can generate and publish >an updated CRL. This is the proper way to handle an Off-line Root CA. > >The burden of obtaining a current CRL is on the Relying Party where it must >periodically refresh its CRL regardless of whether the "nextUpdate" has >been reached or not. A Relying Party can flush its cache at prescribed >intervals and then retrieve a new (updated) CRL as required. > >Mitch > >At 11:01 AM 12/30/2002, David P. Kemp wrote: > > >Because revocation of a signing CA should be very rare event, the > >offline root can take advantage of a "long pipeline" to minimize the > >human effort required to transport disks of CRLs to an online > >repository. The root could pre-generate, say, one week's worth of > >empty daily CRLs (where nextUpdate = thisUpdate + 1 day) and put the 7 > >CRLs on media. The repository would then be responsible for doling out > >the correct CRL each day and not publishing any CRL for which > >thisUpdate is in the future. > > > >In the event of a CA compromise, the pipeline would need to be flushed > >- future CRLs in the repository would be destroyed and the root CA > >would generate a new batch of CRLs on media. > > > >This assumes that compromise of the online repository (allowing access > >to CRLs up to 7 days in the future) is a much less serious event than > >compromise of the offline root CA. I believe that assumption is valid > >and supportable. > > > >Dave > > > > > > > > > >Al Arsenault wrote: > > > > > > Okay, I'm a little confused here. This problem isn't really all > > > that hard to solve. My comments/questions are in-line, prefaced by > > > my initials, > > "AWA". > > > > > > ----- Original Message ----- > > > From: "Haaino Beljaars" > > > To: "Mark Scherling" > > > Cc: > > > Sent: Monday, December 23, 2002 6:36 AM > > > Subject: Re: Offline Root CA with valid CRL hierachie > > > > > > > > > > > > You can still publish a CRL for an off-line CA. You will need > > > > > to > > > > establish > > > > > a fairly long expiry time for the CRL if you do not plan to > > > > > bring > > the CA > > > > > on-line often. In many cases the Root CA is off-line and only > > > > > used to > > > > issue > > > > > new intermediary CAs or revoke intermediary CAs. You will need > > > > > to > > > > establish > > > > > a very good procedure for startup and shutdown of the root CA > > > > > (two > > > person > > > > > control, locked in a safe, two person combination on the safe, > > > documenting > > > > > each time the CA is removed, etc. ) The reason for documenting > > > > > the > > > > process > > > > > is for audit purposes. > > > > > > > > > > You will also need to document in your CP that the CA is > > > > > off-line and > > > that > > > > > the onus is on the relying party to verify that an intermediary > > > > > CA is > > > > still > > > > > valid. > > > > > > > > > > AWA: Let's first clarify terms. What, exactly, do you mean by > > > "off-line CA"? To me, that term means that the CA is not connected > > > to a larger network (specifically, it's not connected to the > > > Internet or larger telecom network through which it can be > > > accessed). It's still running, locked in its secure facility > > > somewhere. That is, start-up/shut-down is not an > > issue; > > > it's already running. Is that what you mean, or is there something > > > else? > > > > > > > I agree that you still publish a valid CRL for an offline Root CA. > > > > The problem is the following, > > > > example: I issue an CRL with the Root CA with a validity of for > > > > example a month, and after issuing the CRL I take it offline. > > > > During that month, for example after > > > two > > > > weeks, one of the > > > > intermediate CA's is compromised and I have to revoke that CA. > > > > According to the specs I can only issue a CRL which has a validity > > > > time > > > that > > > > starts after > > > > current one. > > > > > > AWA: I'm not sure you're interpreting RFC 3280 correctly. > > > Paragraph 5.1.2.5 starts: > > > > > > 5.1.2.5 Next Update > > > > > > This field indicates the date by which the next CRL will be issued. > > > The next CRL could be issued before the indicated date, but it will > > > not be issued any later than the indicated date. CRL issuers SHOULD > > > issue CRLs with a nextUpdate time equal to or later than all previous > > > CRLs. nextUpdate may be encoded as UTCTime or GeneralizedTime. > > > > > > That is, you can only issue a CRL whose "thisUpdate" time is later > > > than the previous one, and whose nextUpdate time is equal to or > > > later than those on previous CRLs (although that latter part is not > > > required). There's no reason why you have to wait until the current > > > CRL expires to issue the new one. > > > > > > >This means in practise that I have a valid intermediate CA for > > > >over two weeks, but in reality that intermediate CA is revoked. > > > >How can I let everybody > > > know > > > > during that > > > > two week period that the intermediate CA is compromised, taking in > > > > account:"Conforming applications are NOT REQUIRED to support > > > > processing of delta CRLs, > > > indirect > > > > CRLs, or CRLs > > > > with a scope other than all certificates issued by one CA"? > > > > > > > > > > AWA: Okay, here's how I've solved this problem in the past. The > > > root CA, while off-line, is running in its secure facility. When it > > > is necessary to revoke an intermediate CA, the root CA is accessed > > > to create a new CRL. This CRL is dumped to some medium, either > > > burned onto a CD or put onto a floppy. This medium is then > > > hand-carried (the term we used to use was > > "sent > > > via sneaker-net") to a server that is on the network. It can be > > > either > > made > > > available as a CRL from, e.g., an LDAP repository; or it can be > > > provided to an OCSP responder. > > > > > > The rest is up to your revocation policy. If you rely only on CRLs, > > and you > > > allow users to cache CRLs until the end of their validity period > > > (e.g., until their "nextUpdate" time), then yes, you have in your > > > scenario a two-week window of vulnerability where users think an > > > intermediate CA is good but it's really not. That's a risk you take > > > by relying only on static CRLs with that long a validity period. (Of > > > course, one would hope that revocation of an intermediate CA would > > > be an extremely rare event, so the overall system risk/cost tradeoff > > > may be acceptable, but...) > > > > > > On the other hand, you can use an OCSP-based system, where users > > > query the responder and will discover that the intermediate CA has > > > been revoked the first time they query its status. OR you can use > > > CRLs with a shorter life cycle. Depending on what you're willing to > > > pay in "human capital" costs, there's no reason you can't have the > > > off-line CA issue a new CRL - > > generally > > > identical to the previous one - as often as you want; e.g., every > > > day, > > every > > > 4 hours, whatever. It just costs you to have the human move the > > > medium - floppy, CD - from the off-line CA to the network-connected > > repository. It's > > > not that hard. > > > > > > > Best regards, > > > > Haaino > > > > > > > > > > Hope this helps. > > > > > > Al Arsenault > > > Chief Security Architect > > > Diversinet Corp. > >*********************************************************** >Mitchell Arnone >Managing Consultant >SchlumbergerSema >Technical Consulting Practice, Northeast Region >Network & Infrastructure Solutions > >marnone@parsippany.sns.slb.com >www.slb.com/nws > >35 Waterview Blvd. >Suite 210 >Parsippany, NJ 07054-1200 >USA > >Phone +1 410-579-8691 >Mobile +1 443-864-1590 *********************************************************** Mitchell Arnone Managing Consultant SchlumbergerSema Technical Consulting Practice, Northeast Region Network & Infrastructure Solutions marnone@parsippany.sns.slb.com www.slb.com/nws 35 Waterview Blvd. Suite 210 Parsippany, NJ 07054-1200 USA Phone +1 410-579-8691 Mobile +1 443-864-1590 From owner-ietf-pkix Fri Jan 3 08:45:52 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03GjqE24636 for ietf-pkix-bks; Fri, 3 Jan 2003 08:45:52 -0800 (PST) Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03Gjoo24632 for ; Fri, 3 Jan 2003 08:45:50 -0800 (PST) Received: from sydney.East.Sun.COM ([129.148.9.16]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22415; Fri, 3 Jan 2003 09:45:51 -0700 (MST) Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h03GjpQ20606; Fri, 3 Jan 2003 11:45:51 -0500 (EST) Message-ID: <3E15BDF7.B8ABFD0A@sun.com> Date: Fri, 03 Jan 2003 11:44:39 -0500 From: Steve Hanna X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mitchell Arnone CC: Santosh Chokhani , ietf-pkix@imc.org Subject: Re: Offline Root CA with valid CRL hierachie References: <5.1.1.1.2.20021230193725.04ad1ab8@pop.parsippany.sns.slb.com> <5.1.1.1.2.20030103103527.02248150@pop.parsippany.sns.slb.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mitchell Arnone wrote: > I am struggling to see how publishing 30 one-day CRLs and > storing them on some off-line media is more secure than > publishing a single 30 day CRL. The difference arises if an attacker can interfere with the distribution of new CRLs (replacing the new ones with old ones, etc.). It's generally much easier to compromise an online web or directory server than it is to compromise an offline CA, so this is a very real concern. In this case, publishing a 30 day CRL allows revoked certs to continue to work for up to 30 days. Publishing 30 one-day CRLs (one at a time, ensuring that later ones are not published prematurely) means that the worst an attacker can do is block all CRLs (Denial Of Service). They can't make a revoked cert work for more than 1 day. As you say, pre-issuing CRLs adds some complexity and is not supported by most CA software. I suggest two alternative solutions: 1) Have the offline CA use a separate CRL issuer that can be easily activated. The CRL issuer can issue CRLs every day. 2) Use OCSP. Update the OCSP responder promptly when a cert is revoked. Both of these solutions are well supported by the standards and don't require any special mechanisms. Steve Hanna From owner-ietf-pkix Fri Jan 3 08:58:37 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03GwbR25136 for ietf-pkix-bks; Fri, 3 Jan 2003 08:58:37 -0800 (PST) Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03Gwao25132 for ; Fri, 3 Jan 2003 08:58:36 -0800 (PST) Received: from Chokhani ([12.91.131.215]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030103165832.FKHH12483.mtiwmhc12.worldnet.att.net@Chokhani> for ; Fri, 3 Jan 2003 16:58:32 +0000 From: "Santosh Chokhani" To: Subject: RE: Offline Root CA with valid CRL hierachie Date: Fri, 3 Jan 2003 11:59:04 -0500 Message-ID: <005a01c2b349$6ca19af0$a200a8c0@Chokhani> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E15BDF7.B8ABFD0A@sun.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve: While CRL issuer may be well supported by the Standards, many commercial products do not handle indirect CRL well. Separately, some RP (client side software) require the CRL to be signed by the same key as the certificate with no regard for re-key or separate keys for certificate and CRL signing. -----Original Message----- From: Steve Hanna [mailto:steve.hanna@sun.com] Sent: Friday, January 03, 2003 11:45 AM To: Mitchell Arnone Cc: Santosh Chokhani; ietf-pkix@imc.org Subject: Re: Offline Root CA with valid CRL hierachie Mitchell Arnone wrote: > I am struggling to see how publishing 30 one-day CRLs and storing them > on some off-line media is more secure than publishing a single 30 day > CRL. The difference arises if an attacker can interfere with the distribution of new CRLs (replacing the new ones with old ones, etc.). It's generally much easier to compromise an online web or directory server than it is to compromise an offline CA, so this is a very real concern. In this case, publishing a 30 day CRL allows revoked certs to continue to work for up to 30 days. Publishing 30 one-day CRLs (one at a time, ensuring that later ones are not published prematurely) means that the worst an attacker can do is block all CRLs (Denial Of Service). They can't make a revoked cert work for more than 1 day. As you say, pre-issuing CRLs adds some complexity and is not supported by most CA software. I suggest two alternative solutions: 1) Have the offline CA use a separate CRL issuer that can be easily activated. The CRL issuer can issue CRLs every day. 2) Use OCSP. Update the OCSP responder promptly when a cert is revoked. Both of these solutions are well supported by the standards and don't require any special mechanisms. Steve Hanna From owner-ietf-pkix Fri Jan 3 08:49:22 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03GnMu24834 for ietf-pkix-bks; Fri, 3 Jan 2003 08:49:22 -0800 (PST) Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03GnLo24830 for ; Fri, 3 Jan 2003 08:49:21 -0800 (PST) Received: from Chokhani ([12.91.131.215]) by mtiwmhc13.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030103164910.ZUHL20003.mtiwmhc13.worldnet.att.net@Chokhani> for ; Fri, 3 Jan 2003 16:49:10 +0000 From: "Santosh Chokhani" To: Subject: RE: Offline Root CA with valid CRL hierachie Date: Fri, 3 Jan 2003 11:49:42 -0500 Message-ID: <005101c2b348$1d7e2a20$a200a8c0@Chokhani> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <5.1.1.1.2.20030103103527.02248150@pop.parsippany.sns.slb.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h03GnMo24831 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mitch: Please see responses in-line in []. -----Original Message----- From: Mitchell Arnone [mailto:marnone@parsippany.sns.slb.com] Sent: Friday, January 03, 2003 10:57 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: Offline Root CA with valid CRL hierachie Santosh, In todays world, CRL publication is very straight forward. The idea presented by Dave would require additional functionality built into the CA to: 1-publish not only the current CRL but many others in advance [My scheme calls for publishing CRLs one at a time, not many others] then 2-procedures must be developed on who, how, when and where those CRLs will be stored and managed [My proposal was for those who control the private key and/or cryptographic module and associated private key activation data will do this] and then 3-some other process/procedure must put into place to replace expired CRLs with the "current" one [If the CA is truly off-line, you will need to carry the CRL to network connected directory any way. You just take the CRL in the same medium as you would otherwise] and 4-there must be even more procedures describing what to do if there is a CA revocation... like destroying all existing CRLs and generating a list of new ones. [This simple to do. What you get in return is security and operational convenience] The complexity comes in adding numerous new procedures which simply may not be necessary. These procedures, as described below, are manual and if we are to support a secure and reliable infrastructure, the human element must be reduced if not eliminated and to do so, major revisions to CA system could be required. I am struggling to see how publishing 30 one-day CRLs and storing them on some off-line media is more secure than publishing a single 30 day CRL. The reaction to a CA revocation will be the same in both scenarios because the ROOT CA will have to be brought on-line to execute the revocation process and produce new updated CRLs before going back off-line. [The reason it is more secure is that if you issue a CRL whose nextUpdate is thirty days later, then if anything happens during those thirty days, you are vulnerable to old CRL replay attack. The only way to mitigate that risk is to trust both the directory and the communication pipe you as RP build to it. With the approach I suggest, the window of vulnerability is one day since the CRL gets to the directory daily. If any day, a CA needs to be revoked, you create new CRLS. Since no one had those pregenerated CRLs, you are not vulnerable to their use] Mitch At 10:57 AM 12/31/2002, Santosh Chokhani wrote: >Mitch: > >What I interpreted from Dave's e-mail is as follows: > >1. For operational security and operational workload reasons, we may >not want to bring the off-line Root on-line to generate the CRL too >often. > >2. For security reasons, we also want the Root CRL to have a >relatively current nextUpdate (vice one month or one year from now). > >3. To meet these two, the root CA generates a bunch of CRLs in advance >with thisUpdate not of the current time, but desired times in the >future and nextUpdate also of various desired times in the future. > >4. One can put these CRLs on portable media and control them under the >same physical and procedural controls that Root CA and associated >private key activation is controlled. > >5. Most of the time, a CA will not be revoked and hence the proper >portable medium can be carried to the repository and CRL published. > >6. If a CA is revoked, root CA will be booted up, all the portable >media will be erased and root CA will generate a bunch of new CRLs >using step 3. > >This does not sound technically complex to me. It does require some >procedural controls for additional items, namely portable media for the >future CRLs. > >-----Original Message----- >From: owner-ietf-pkix@mail.imc.org >[mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Mitchell Arnone >Sent: Monday, December 30, 2002 8:13 PM >To: David P. Kemp; ietf-pkix@imc.org >Subject: Re: Offline Root CA with valid CRL hierachie > > > >Dave, > >This sounds like a very complex technical solution that circumvents >proper procedures designed to maintain a significantly high level of >assurance. The Root CA is the root of trust and therefore must live up >to the highest level of assurance attested to by a particular PKI. > >CRLs must be generated on the date and at the time they become >effective. Predicting contents of a CRL and generating them in advance >leaves much room and opportunity to render a PKI untrustworthy. > >A CRL can be generated by an off-line Root CA where the next update can >be one day, one month or even one year from the date contained in >"thisUpdate". Depending on this setting, and assuming that no >subordinate CA certificates have been revoked prior to the normally >scheduled update period, the off-line Root CA can be brought on-line >allowing it to generate and publish a fresh CRL. In the event that a >subordinate CA certificate is revoked, obviously the Root CA must >brought on-line to do so and immediately following the revocation, the >Root CA can generate and publish an updated CRL. This is the proper >way to handle an Off-line Root CA. > >The burden of obtaining a current CRL is on the Relying Party where it >must periodically refresh its CRL regardless of whether the >"nextUpdate" has been reached or not. A Relying Party can flush its >cache at prescribed intervals and then retrieve a new (updated) CRL as >required. > >Mitch > >At 11:01 AM 12/30/2002, David P. Kemp wrote: > > >Because revocation of a signing CA should be very rare event, the > >offline root can take advantage of a "long pipeline" to minimize the > >human effort required to transport disks of CRLs to an online > >repository. The root could pre-generate, say, one week's worth of > >empty daily CRLs (where nextUpdate = thisUpdate + 1 day) and put the > >7 CRLs on media. The repository would then be responsible for doling > >out the correct CRL each day and not publishing any CRL for which > >thisUpdate is in the future. > > > >In the event of a CA compromise, the pipeline would need to be > >flushed > >- future CRLs in the repository would be destroyed and the root CA > >would generate a new batch of CRLs on media. > > > >This assumes that compromise of the online repository (allowing > >access to CRLs up to 7 days in the future) is a much less serious > >event than compromise of the offline root CA. I believe that > >assumption is valid and supportable. > > > >Dave > > > > > > > > > >Al Arsenault wrote: > > > > > > Okay, I'm a little confused here. This problem isn't really all > > > that hard to solve. My comments/questions are in-line, prefaced by > > > my initials, > > "AWA". > > > > > > ----- Original Message ----- > > > From: "Haaino Beljaars" > > > To: "Mark Scherling" > > > Cc: > > > Sent: Monday, December 23, 2002 6:36 AM > > > Subject: Re: Offline Root CA with valid CRL hierachie > > > > > > > > > > > > You can still publish a CRL for an off-line CA. You will need > > > > > to > > > > establish > > > > > a fairly long expiry time for the CRL if you do not plan to > > > > > bring > > the CA > > > > > on-line often. In many cases the Root CA is off-line and only > > > > > used to > > > > issue > > > > > new intermediary CAs or revoke intermediary CAs. You will > > > > > need to > > > > establish > > > > > a very good procedure for startup and shutdown of the root CA > > > > > (two > > > person > > > > > control, locked in a safe, two person combination on the safe, > > > documenting > > > > > each time the CA is removed, etc. ) The reason for > > > > > documenting the > > > > process > > > > > is for audit purposes. > > > > > > > > > > You will also need to document in your CP that the CA is > > > > > off-line and > > > that > > > > > the onus is on the relying party to verify that an > > > > > intermediary CA is > > > > still > > > > > valid. > > > > > > > > > > AWA: Let's first clarify terms. What, exactly, do you mean by > > > "off-line CA"? To me, that term means that the CA is not > > > connected to a larger network (specifically, it's not connected to > > > the Internet or larger telecom network through which it can be > > > accessed). It's still running, locked in its secure facility > > > somewhere. That is, start-up/shut-down is not an > > issue; > > > it's already running. Is that what you mean, or is there > > > something else? > > > > > > > I agree that you still publish a valid CRL for an offline Root > > > > CA. The problem is the following, > > > > example: I issue an CRL with the Root CA with a validity of for > > > > example a month, and after issuing the CRL I take it offline. > > > > During that month, for example after > > > two > > > > weeks, one of the > > > > intermediate CA's is compromised and I have to revoke that CA. > > > > According to the specs I can only issue a CRL which has a > > > > validity time > > > that > > > > starts after > > > > current one. > > > > > > AWA: I'm not sure you're interpreting RFC 3280 correctly. > > > Paragraph 5.1.2.5 starts: > > > > > > 5.1.2.5 Next Update > > > > > > This field indicates the date by which the next CRL will be issued. > > > The next CRL could be issued before the indicated date, but it will > > > not be issued any later than the indicated date. CRL issuers SHOULD > > > issue CRLs with a nextUpdate time equal to or later than all previous > > > CRLs. nextUpdate may be encoded as UTCTime or GeneralizedTime. > > > > > > That is, you can only issue a CRL whose "thisUpdate" time is later > > > than the previous one, and whose nextUpdate time is equal to or > > > later than those on previous CRLs (although that latter part is > > > not required). There's no reason why you have to wait until the > > > current CRL expires to issue the new one. > > > > > > >This means in practise that I have a valid intermediate CA for > > > >over two weeks, but in reality that intermediate CA is revoked. > > > >How can I let everybody > > > know > > > > during that > > > > two week period that the intermediate CA is compromised, taking > > > > in account:"Conforming applications are NOT REQUIRED to support > > > > processing of delta CRLs, > > > indirect > > > > CRLs, or CRLs > > > > with a scope other than all certificates issued by one CA"? > > > > > > > > > > AWA: Okay, here's how I've solved this problem in the past. The > > > root CA, while off-line, is running in its secure facility. When > > > it is necessary to revoke an intermediate CA, the root CA is > > > accessed to create a new CRL. This CRL is dumped to some medium, > > > either burned onto a CD or put onto a floppy. This medium is then > > > hand-carried (the term we used to use was > > "sent > > > via sneaker-net") to a server that is on the network. It can be > > > either > > made > > > available as a CRL from, e.g., an LDAP repository; or it can be > > > provided to an OCSP responder. > > > > > > The rest is up to your revocation policy. If you rely only on > > > CRLs, > > and you > > > allow users to cache CRLs until the end of their validity period > > > (e.g., until their "nextUpdate" time), then yes, you have in your > > > scenario a two-week window of vulnerability where users think an > > > intermediate CA is good but it's really not. That's a risk you > > > take by relying only on static CRLs with that long a validity > > > period. (Of course, one would hope that revocation of an > > > intermediate CA would be an extremely rare event, so the overall > > > system risk/cost tradeoff may be acceptable, but...) > > > > > > On the other hand, you can use an OCSP-based system, where users > > > query the responder and will discover that the intermediate CA has > > > been revoked the first time they query its status. OR you can use > > > CRLs with a shorter life cycle. Depending on what you're willing > > > to pay in "human capital" costs, there's no reason you can't have > > > the off-line CA issue a new CRL - > > generally > > > identical to the previous one - as often as you want; e.g., every > > > day, > > every > > > 4 hours, whatever. It just costs you to have the human move the > > > medium - floppy, CD - from the off-line CA to the > > > network-connected > > repository. It's > > > not that hard. > > > > > > > Best regards, > > > > Haaino > > > > > > > > > > Hope this helps. > > > > > > Al Arsenault > > > Chief Security Architect > > > Diversinet Corp. > >*********************************************************** >Mitchell Arnone >Managing Consultant >SchlumbergerSema >Technical Consulting Practice, Northeast Region >Network & Infrastructure Solutions > >marnone@parsippany.sns.slb.com >www.slb.com/nws > >35 Waterview Blvd. >Suite 210 >Parsippany, NJ 07054-1200 >USA > >Phone +1 410-579-8691 >Mobile +1 443-864-1590 *********************************************************** Mitchell Arnone Managing Consultant SchlumbergerSema Technical Consulting Practice, Northeast Region Network & Infrastructure Solutions marnone@parsippany.sns.slb.com www.slb.com/nws 35 Waterview Blvd. Suite 210 Parsippany, NJ 07054-1200 USA Phone +1 410-579-8691 Mobile +1 443-864-1590 From owner-ietf-pkix Fri Jan 3 10:11:57 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03IBv300597 for ietf-pkix-bks; Fri, 3 Jan 2003 10:11:57 -0800 (PST) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03IBpo00593 for ; Fri, 3 Jan 2003 10:11:51 -0800 (PST) Received: from SJOSEPH (pcp237593pcs.elictc01.md.comcast.net [68.55.160.224]) by mtaout01.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.07 (built Nov 25 2002)) with SMTP id <0H8500AC9H7NAR@mtaout01.icomcast.net> for ietf-pkix@imc.org; Fri, 03 Jan 2003 13:11:48 -0500 (EST) Date: Fri, 03 Jan 2003 13:11:09 -0500 From: Al Arsenault Subject: Re: Offline Root CA with valid CRL hierachie To: Mitchell Arnone , Santosh Chokhani , ietf-pkix@imc.org Message-id: <007b01c2b353$7e342800$6801a8c0@SJOSEPH> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5.1.1.1.2.20021230193725.04ad1ab8@pop.parsippany.sns.slb.com> <5.1.1.1.2.20030103103527.02248150@pop.parsippany.sns.slb.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mitch, While I'm not a big fan of the scheme Dave Kemp suggested, there are a couple of things useful about it. Comments in-line, prefaced by my initials, "AWA". ----- Original Message ----- From: "Mitchell Arnone" To: "Santosh Chokhani" ; Sent: Friday, January 03, 2003 10:57 AM Subject: RE: Offline Root CA with valid CRL hierachie > > Santosh, > > In todays world, CRL publication is very straight forward. The idea > presented by Dave would require additional functionality built into the CA to: > > 1-publish not only the current CRL but many others in advance then > 2-procedures must be developed on who, how, when and where those CRLs will > be stored and managed and then > 3-some other process/procedure must put into place to replace expired CRLs > with the "current" one and > 4-there must be even more procedures describing what to do if there is a CA > revocation... like destroying all existing CRLs and generating a list of > new ones. > > The complexity comes in adding numerous new procedures which simply may not > be necessary. These procedures, as described below, are manual and if we > are to support a secure and reliable infrastructure, the human element must > be reduced if not eliminated and to do so, major revisions to CA system > could be required. AWA: (I firmly believe, based on about 15 years of working with PKIs, that) The human element can *never* be eliminated from a secure and reliable infrastructure. Yes, the human element can be reduced to lower certain types of security risks, and it can certainly be reduced in many places to lower operational costs, but designing a system where an event such as revocation of an intermediate CA can be done with no level of human review at any point is sheer folly. It leads to some really sweet denial of service and other attacks (well, they're sweet from the attacker's view). > > I am struggling to see how publishing 30 one-day CRLs and storing them on > some off-line media is more secure than publishing a single 30 day > CRL. The reaction to a CA revocation will be the same in both scenarios > because the ROOT CA will have to be brought on-line to execute the > revocation process and produce new updated CRLs before going back off-line. > AWA: The difference is the expiration date. With one 30-day CRL, when you have to revoke an intermediate CA on day 10, there is nothing to indicate to any RP that it can't continue to rely on the original CRL, which says that the intermediate CA is good. So for 20 days, you've got RPs believing that a certificate path is good based on checking a "current" CRL, when the cert path is invalid. With 30 one-day CRLs, the CRL expires at the end of each day. When you have to revoke an intermediate CA on day 10, you destroy all the pre-generated CRLs (saying that the intermediate CA is good), and generate new one-day CRLs saying that the intermediate CA is bad. Thus, there's no-way a well-behaved RP could find and use a CRL that says the intermediate CA is good after the date of revocation. Your window of vulnerability is reduced to the rest of that day. Now, that being said, I'm still not a big fan of Dave's proposal. First, I don't know of an auditor anywhere in the world who would allow the root CA's clock to be advanced to pre-generate one-day CRLs for the future, so that approach is pretty much out - you'd have to have all the "thisUpdate" dates being the same. But since revocation of an intermediate CA is (I hope :-) an extremely rare event, it seems to me to be much more efficient to put out a notice using OCSP or some other mechanism when the revocation occurs. I'm not saying Dave's approach couldn't work; it certainly could. And it wouldn't significantly reduce security if the pre-generated CRLs were properly controlled through physical/procedural means. I'm just saying that I don't see any real big advantage to it. > Mitch > Al Arsenault Chief Security Architect Diversinet Corp. From owner-ietf-pkix Fri Jan 3 10:28:37 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03ISbe01072 for ietf-pkix-bks; Fri, 3 Jan 2003 10:28:37 -0800 (PST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03ISVo01062 for ; Fri, 3 Jan 2003 10:28:31 -0800 (PST) Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09187; Fri, 3 Jan 2003 10:28:27 -0800 (PST) Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h03ISMQ29750; Fri, 3 Jan 2003 13:28:23 -0500 (EST) Message-ID: <3E15D5FE.AF979F85@sun.com> Date: Fri, 03 Jan 2003 13:27:10 -0500 From: Steve Hanna X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Santosh Chokhani CC: ietf-pkix@imc.org Subject: Re: Offline Root CA with valid CRL hierachie References: <005a01c2b349$6ca19af0$a200a8c0@Chokhani> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree that there are many products (CAs and RPs) that don't support indirect CRLs yet. That is also true of policy constraints, name constraints, and many other features of RFC 3280. In fact, most RPs don't support revocation checking at all! I hope these deficiencies will be remedied soon as customers start to require RFC 3280 compliant path validation in RFPs. So one of the main advantages of the system you propose is that it can work with RPs that support revocation checking by CRL, but not indirect CRLs or OCSP. I wonder how common that will be. I'm sure there will be some such RPs. -Steve P.S. I see that RFC 3280 RECOMMENDS that RPs support indirect CRLs, but it doesn't REQUIRE them to do so. I hope that support for indirect CRLs will be common. Indirect CRLs have benefits beyond the ability to issue regular CRLs without having to put the CA online or pre-issue CRLs. They also allow several CAs to share a single CRL, which is especially useful for CAs that rarely revoke certificates. Of course, they do require more work for the relying party, since they must validate the CRL issuer's cert. Santosh Chokhani wrote: > > Steve: > > While CRL issuer may be well supported by the Standards, many commercial > products do not handle indirect CRL well. > > Separately, some RP (client side software) require the CRL to be signed by > the same key as the certificate with no regard for re-key or separate keys > for certificate and CRL signing. > > -----Original Message----- > From: Steve Hanna [mailto:steve.hanna@sun.com] > Sent: Friday, January 03, 2003 11:45 AM > To: Mitchell Arnone > Cc: Santosh Chokhani; ietf-pkix@imc.org > Subject: Re: Offline Root CA with valid CRL hierachie > > Mitchell Arnone wrote: > > I am struggling to see how publishing 30 one-day CRLs and storing them > > on some off-line media is more secure than publishing a single 30 day > > CRL. > > The difference arises if an attacker can interfere with > the distribution of new CRLs (replacing the new ones with > old ones, etc.). It's generally much easier to compromise > an online web or directory server than it is to compromise > an offline CA, so this is a very real concern. > > In this case, publishing a 30 day CRL allows revoked certs > to continue to work for up to 30 days. Publishing 30 one-day CRLs (one at a > time, ensuring that later ones are not published > prematurely) means that the worst an attacker can do is block all CRLs > (Denial Of Service). They can't make a revoked cert work for more than 1 > day. > > As you say, pre-issuing CRLs adds some complexity and is > not supported by most CA software. I suggest two alternative > solutions: > > 1) Have the offline CA use a separate CRL issuer that can be > easily activated. The CRL issuer can issue CRLs every day. > > 2) Use OCSP. Update the OCSP responder promptly when a cert > is revoked. > > Both of these solutions are well supported by the standards > and don't require any special mechanisms. > > Steve Hanna From owner-ietf-pkix Fri Jan 3 11:15:17 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03JFHM02654 for ietf-pkix-bks; Fri, 3 Jan 2003 11:15:17 -0800 (PST) Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03JFGo02647 for ; Fri, 3 Jan 2003 11:15:17 -0800 (PST) Received: from Chokhani ([12.91.132.21]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030103191512.NGJY9286.mtiwmhc11.worldnet.att.net@Chokhani> for ; Fri, 3 Jan 2003 19:15:12 +0000 From: "Santosh Chokhani" To: Subject: RE: Offline Root CA with valid CRL hierachie Date: Fri, 3 Jan 2003 14:15:44 -0500 Message-ID: <007601c2b35c$8414e440$a200a8c0@Chokhani> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <5.1.1.1.2.20030103135113.0221a7e8@pop.parsippany.sns.slb.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h03JFHo02649 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mitch: OCSP for Root raises its own issue in terms of Responder trust and responder revocation (if a certificate based approach is used (vice trust anchor)) checking. -----Original Message----- From: Mitchell Arnone [mailto:marnone@parsippany.sns.slb.com] Sent: Friday, January 03, 2003 2:11 PM To: Al Arsenault; Santosh Chokhani; ietf-pkix@imc.org Subject: Re: Offline Root CA with valid CRL hierachie All points raised on this issue have been well stated. I do believe that Dave's approach could work but my concern is that I too do not see any real advantage to it. The 30 day CRL might be OK if the directories are secured and scaled properly and the 30 1day CRLs might be OK if the stack of pre-generated CRLs are secured and published properly. I just think there is a better solution the likes of which others on this list have already commented. Personally I like the OCSP approach but even that does not mitigate the need for an effective CRL publishing strategy. Thanks Mitch At 01:11 PM 1/3/2003, Al Arsenault wrote: >I'm not saying Dave's approach couldn't work; it certainly could. And >it wouldn't significantly reduce security if the pre-generated CRLs >were properly controlled through physical/procedural means. I'm just >saying that I don't see any real big advantage to it. *********************************************************** Mitchell Arnone Managing Consultant SchlumbergerSema Technical Consulting Practice, Northeast Region Network & Infrastructure Solutions marnone@parsippany.sns.slb.com www.slb.com/nws 35 Waterview Blvd. Suite 210 Parsippany, NJ 07054-1200 USA Phone +1 410-579-8691 Mobile +1 443-864-1590 From owner-ietf-pkix Fri Jan 3 11:10:52 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03JAqg02411 for ietf-pkix-bks; Fri, 3 Jan 2003 11:10:52 -0800 (PST) Received: from mail.slb.com (nammta01.sugar-land.nam.slb.com [163.188.150.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03JAno02403 for ; Fri, 3 Jan 2003 11:10:49 -0800 (PST) Received: from conversion-daemon.nammta01.sugar-land.nam.slb.com by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) id <0H8500301JX2KB@nammta01.sugar-land.nam.slb.com> for ietf-pkix@imc.org; Fri, 03 Jan 2003 19:10:52 +0000 (GMT) Received: from namems01.sugar-land.oilfield.slb.com (namems01.sugar-land.oilfield.slb.com [163.188.150.131]) by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) with ESMTP id <0H8500I2WJXWU2@nammta01.sugar-land.nam.slb.com> for ietf-pkix@imc.org; Fri, 03 Jan 2003 19:10:44 +0000 (GMT) Received: from conversion-daemon.namems01.sugar-land.oilfield.slb.com by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov 1 2002)) id <0H8500K01JCY09@namems01.sugar-land.oilfield.slb.com> for ietf-pkix@imc.org; Fri, 03 Jan 2003 19:10:43 +0000 (GMT) Received: from SCHLUMBE-HJ7VF7.HOUSTON-OMH (vpnpool851.houston.sinet.slb.com [163.188.127.83]) by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov 1 2002)) with ESMTP id <0H8500MJYJWJ9Z@namems01.sugar-land.oilfield.slb.com>; Fri, 03 Jan 2003 19:09:56 +0000 (GMT) Date: Fri, 03 Jan 2003 14:10:51 -0500 From: Mitchell Arnone Subject: Re: Offline Root CA with valid CRL hierachie In-reply-to: <007b01c2b353$7e342800$6801a8c0@SJOSEPH> X-Sender: marnone@pop.parsippany.sns.slb.com To: Al Arsenault , Santosh Chokhani , ietf-pkix@imc.org Message-id: <5.1.1.1.2.20030103135113.0221a7e8@pop.parsippany.sns.slb.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <5.1.1.1.2.20021230193725.04ad1ab8@pop.parsippany.sns.slb.com> <5.1.1.1.2.20030103103527.02248150@pop.parsippany.sns.slb.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All points raised on this issue have been well stated. I do believe that Dave's approach could work but my concern is that I too do not see any real advantage to it. The 30 day CRL might be OK if the directories are secured and scaled properly and the 30 1day CRLs might be OK if the stack of pre-generated CRLs are secured and published properly. I just think there is a better solution the likes of which others on this list have already commented. Personally I like the OCSP approach but even that does not mitigate the need for an effective CRL publishing strategy. Thanks Mitch At 01:11 PM 1/3/2003, Al Arsenault wrote: >I'm not saying Dave's approach couldn't work; it certainly could. And it >wouldn't significantly reduce security if the pre-generated CRLs were >properly controlled through physical/procedural means. I'm just saying that >I don't see any real big advantage to it. *********************************************************** Mitchell Arnone Managing Consultant SchlumbergerSema Technical Consulting Practice, Northeast Region Network & Infrastructure Solutions marnone@parsippany.sns.slb.com www.slb.com/nws 35 Waterview Blvd. Suite 210 Parsippany, NJ 07054-1200 USA Phone +1 410-579-8691 Mobile +1 443-864-1590 From owner-ietf-pkix Fri Jan 3 11:09:59 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03J9xF02366 for ietf-pkix-bks; Fri, 3 Jan 2003 11:09:59 -0800 (PST) Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03J9xo02362 for ; Fri, 3 Jan 2003 11:09:59 -0800 (PST) Received: from Chokhani ([12.91.132.21]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030103190955.IVFW12483.mtiwmhc12.worldnet.att.net@Chokhani> for ; Fri, 3 Jan 2003 19:09:55 +0000 From: "Santosh Chokhani" To: Subject: RE: Offline Root CA with valid CRL hierachie Date: Fri, 3 Jan 2003 14:10:26 -0500 Message-ID: <007501c2b35b$c685ab80$a200a8c0@Chokhani> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E15D5FE.AF979F85@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h03J9xo02363 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve: I am thoroughly confused. First, what I am proposing will work if the RP is using indirect CRL. I am making a modest assumption that an RP that can process indirect CRL can also process full and complete CRL. In terms of OCSP, if your solution is OCSP only, I still think the approach I suggest will be a good way to supply the revocation information to the OCSP responders, specially if there are many of them or if you want to the convenience of distributing the revocation information over untrusted networks. Again I am making a modest assumption that the OCSP Responders should get their revocation information from the issuer. This being off-line Root, it is not going to be the OCSP Responder for itself. How the OCSP Responder for off-line root revocation should be architected is a separate topic with its own nuances. -----Original Message----- From: Steve Hanna [mailto:steve.hanna@sun.com] Sent: Friday, January 03, 2003 1:27 PM To: Santosh Chokhani Cc: ietf-pkix@imc.org Subject: Re: Offline Root CA with valid CRL hierachie I agree that there are many products (CAs and RPs) that don't support indirect CRLs yet. That is also true of policy constraints, name constraints, and many other features of RFC 3280. In fact, most RPs don't support revocation checking at all! I hope these deficiencies will be remedied soon as customers start to require RFC 3280 compliant path validation in RFPs. So one of the main advantages of the system you propose is that it can work with RPs that support revocation checking by CRL, but not indirect CRLs or OCSP. I wonder how common that will be. I'm sure there will be some such RPs. -Steve P.S. I see that RFC 3280 RECOMMENDS that RPs support indirect CRLs, but it doesn't REQUIRE them to do so. I hope that support for indirect CRLs will be common. Indirect CRLs have benefits beyond the ability to issue regular CRLs without having to put the CA online or pre-issue CRLs. They also allow several CAs to share a single CRL, which is especially useful for CAs that rarely revoke certificates. Of course, they do require more work for the relying party, since they must validate the CRL issuer's cert. Santosh Chokhani wrote: > > Steve: > > While CRL issuer may be well supported by the Standards, many > commercial products do not handle indirect CRL well. > > Separately, some RP (client side software) require the CRL to be > signed by the same key as the certificate with no regard for re-key or > separate keys for certificate and CRL signing. > > -----Original Message----- > From: Steve Hanna [mailto:steve.hanna@sun.com] > Sent: Friday, January 03, 2003 11:45 AM > To: Mitchell Arnone > Cc: Santosh Chokhani; ietf-pkix@imc.org > Subject: Re: Offline Root CA with valid CRL hierachie > > Mitchell Arnone wrote: > > I am struggling to see how publishing 30 one-day CRLs and storing > > them on some off-line media is more secure than publishing a single > > 30 day CRL. > > The difference arises if an attacker can interfere with > the distribution of new CRLs (replacing the new ones with > old ones, etc.). It's generally much easier to compromise > an online web or directory server than it is to compromise > an offline CA, so this is a very real concern. > > In this case, publishing a 30 day CRL allows revoked certs > to continue to work for up to 30 days. Publishing 30 one-day CRLs (one > at a time, ensuring that later ones are not published > prematurely) means that the worst an attacker can do is block all CRLs > (Denial Of Service). They can't make a revoked cert work for more than > 1 day. > > As you say, pre-issuing CRLs adds some complexity and is > not supported by most CA software. I suggest two alternative > solutions: > > 1) Have the offline CA use a separate CRL issuer that can be > easily activated. The CRL issuer can issue CRLs every day. > > 2) Use OCSP. Update the OCSP responder promptly when a cert > is revoked. > > Both of these solutions are well supported by the standards and don't > require any special mechanisms. > > Steve Hanna From owner-ietf-pkix Fri Jan 3 11:35:08 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03JZ8r05283 for ietf-pkix-bks; Fri, 3 Jan 2003 11:35:08 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03JZ5o05272 for ; Fri, 3 Jan 2003 11:35:05 -0800 (PST) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h03JZ6Zx030116; Fri, 3 Jan 2003 14:35:06 -0500 Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h03Jcmv3026706; Fri, 3 Jan 2003 12:38:48 -0700 Importance: Normal Sensitivity: Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-03.txt To: Russ Housley Cc: ietf-pkix@imc.org, jjacoby@rsasecurity.com, pgut001@cs.auckland.ac.nz X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Tom Gindin" Date: Fri, 3 Jan 2003 14:34:38 -0500 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11 +SPRs MIAS5EXFG4, MIAS5AUFPV and DHAG4Y6R7W, MATTEST |November 8th, 2002) at 01/03/2003 02:35:05 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ: Of course I have no objection to mentioning a preference for subjectAltName over subject for e-mail addresses. I just thought that anybody actually implementing something which extracts e-mail addresses from certificates would be helped by knowing all the places which are used in large numbers of certificates, not just the approved ones. In the earlier wording ("an rfc822Name attribute") I wasn't sure whether implementors would interpret this as the rfc822mailbox directory attribute or the rfc822Name component of GeneralName, anyway. Tom Gindin Russ Housley on 01/02/2003 02:27:28 PM To: Tom Gindin/Watson/IBM@IBMUS cc: ietf-pkix@imc.org, jjacoby@rsasecurity.com, pgut001@cs.auckland.ac.nz Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-03.txt Tom: RFC 3280 says that subjectAltName extension using the rfc822Name is the way that an email address SHOULD be included in a certificate. I would like to see the text reinforces this, but says that there are certificates that use other placements. Russ At 07:06 PM 12/23/2002 -0500, Tom Gindin wrote: > How about mentioning the other two normal ways of storing the email >address: "This is typically stored in the certificate either within the >subject DN as a value of one of the attributes rfc822mailbox or >emailAddress, or in the subjectAltName extension using the rfc822Name >choice of GeneralName". I've personally never seen anyone use any other >way than those three. > > Tom Gindin > > >pgut001@cs.auckland.ac.nz (Peter Gutmann)@mail.imc.org on 12/20/2002 >09:10:32 PM > >Sent by: owner-ietf-pkix@mail.imc.org > > >To: ietf-pkix@imc.org, jjacoby@rsasecurity.com >cc: >Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-03.txt > > > >Jeff Jacoby writes: > > >Is it necessary to require an exact match for all attributes, particularly > >for such attributes as the email and name attributes? > >In a word, yes. > > >For example, I'm looking for the cert for Bill Williams, but I don't know >if > >the common name is "Bill Williams" or "Will Williams" or "B. Williams", >etc, > >so I might like to try a search on just "Williams" > >How would you specify this? You'd need some sort of general-purpose >pattern- >matching mechanism and then a means of mapping it to every possible backend >that might be used to implement the lookup. The draft specifies a >universal >interface to (conceptually) a basic key-and-value lookup engine, which >doesn't >extend to general pattern-matching. If you need anything more than this >(for >example searching on compound attributes and similar things) you should >really >use LDAP. > > >Secondly, the entry for email attribute indicates the value as: > > > > "Subject email address contained in the certificate, typically as an > > rfc882Name attribute > > > >Is it necessary the email attribute be from the certificate. Is it a > >reasonable or likely situation that a certificate store might use the >email > >address as an database index even though it's not actually in the > >certificate? > >I'd never thought of it being done like that, but I can easily change the >text >to accomodate it. How about: > > Subject email address associated with the certificate. This is typically > stored in the certificate as an rfc882Name attribute. > >Peter. From owner-ietf-pkix Fri Jan 3 11:43:53 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03JhrA05983 for ietf-pkix-bks; Fri, 3 Jan 2003 11:43:53 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03Jhqo05979 for ; Fri, 3 Jan 2003 11:43:52 -0800 (PST) Received: from sydney.East.Sun.COM ([129.148.9.16]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00914; Fri, 3 Jan 2003 12:43:53 -0700 (MST) Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h03JhrQ06574; Fri, 3 Jan 2003 14:43:53 -0500 (EST) Message-ID: <3E15E7B1.C94384AE@sun.com> Date: Fri, 03 Jan 2003 14:42:41 -0500 From: Steve Hanna X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Santosh Chokhani CC: ietf-pkix@imc.org Subject: Re: Offline Root CA with valid CRL hierachie References: <007501c2b35b$c685ab80$a200a8c0@Chokhani> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh Chokhani wrote: > I am thoroughly confused. First, what I am proposing will work > if the RP is using indirect CRL. I am making a modest assumption > that an RP that can process indirect CRL can also process full and > complete CRL. Right. The primary benefit of pre-issued CRLs over indirect CRLs or OCSP is that pre-issued CRLs work with any RP that can process CRLs (any RFC 3280 compliant RP) whereas the others require support for features not required by RFC 3280. > In terms of OCSP, if your solution is OCSP only, I still > think the approach I suggest will be a good way to supply the > revocation information to the OCSP responders, specially if > there are many of them or if you want to the convenience of > distributing the revocation information over untrusted networks. I don't know much about how people generally supply revocation information to OCSP responders. Certainly, I expect that your system would work fine. But I expect that many OCSP responders would support indirect CRLs, so that might also be a solution. And some people might just use SSH. I don't know. > How the OCSP Responder for off-line root revocation should be > architected is a separate topic with its own nuances. I didn't think we were discussing how to revoke a root. As you say, that's a separate topic. Let's leave it aside for now, unless there's some pressing need to address it. -Steve From owner-ietf-pkix Fri Jan 3 13:20:48 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03LKmg11877 for ietf-pkix-bks; Fri, 3 Jan 2003 13:20:48 -0800 (PST) Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03LKlo11873 for ; Fri, 3 Jan 2003 13:20:47 -0800 (PST) Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.5/8.12.5) with SMTP id h03LKeZp028130; Fri, 3 Jan 2003 13:20:43 -0800 From: "Ambarish Malpani" To: "Mitchell Arnone" , "Al Arsenault" , "Santosh Chokhani" , Subject: RE: Offline Root CA with valid CRL hierachie Date: Fri, 3 Jan 2003 13:20:49 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5.1.1.1.2.20030103135113.0221a7e8@pop.parsippany.sns.slb.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mitch, With OCSP, you can get around most of the CRL publishing issues. One of the features I added to the Valicert OCSP responder (VA), was to allow it (under operator control), to accept expired CRLs for a fixed amount of time. If the CA is operating the VA, it can issue a single CRL and have the VA trust it for as long as he wishes to - for example issue the CRL for a day, but have the responder trust it for 30. If a new revocation needs to happen, you publish the new CRL to the VA, which now starts trusting the new CRL (and no longer depends on the old one). It is also perfectly possible to have the VA run on its own data and not rely on the CA software for revocation data at all - I know at least one CA that chose to operate in that way (even though they were operating both the CA and the VA themselves). Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani 650.759.9045 Malpani Consulting Services ambarish@malpani.biz http://www.malpani.biz > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Mitchell Arnone > Sent: Friday, January 03, 2003 11:11 AM > To: Al Arsenault; Santosh Chokhani; ietf-pkix@imc.org > Subject: Re: Offline Root CA with valid CRL hierachie > > > > All points raised on this issue have been well stated. I do believe that > Dave's approach could work but my concern is that I too do not > see any real > advantage to it. The 30 day CRL might be OK if the directories > are secured > and scaled properly and the 30 1day CRLs might be OK if the stack of > pre-generated CRLs are secured and published properly. I just > think there > is a better solution the likes of which others on this list have already > commented. Personally I like the OCSP approach but even that does not > mitigate the need for an effective CRL publishing strategy. > > Thanks > > Mitch > > At 01:11 PM 1/3/2003, Al Arsenault wrote: > >I'm not saying Dave's approach couldn't work; it certainly could. And it > >wouldn't significantly reduce security if the pre-generated CRLs were > >properly controlled through physical/procedural means. I'm just > saying that > >I don't see any real big advantage to it. > > *********************************************************** > Mitchell Arnone > Managing Consultant > SchlumbergerSema > Technical Consulting Practice, Northeast Region > Network & Infrastructure Solutions > > marnone@parsippany.sns.slb.com > www.slb.com/nws > > 35 Waterview Blvd. > Suite 210 > Parsippany, NJ 07054-1200 > USA > > Phone +1 410-579-8691 > Mobile +1 443-864-1590 > > From owner-ietf-pkix Fri Jan 3 12:28:26 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03KSQ907881 for ietf-pkix-bks; Fri, 3 Jan 2003 12:28:26 -0800 (PST) Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03KSPo07875 for ; Fri, 3 Jan 2003 12:28:25 -0800 (PST) Received: from Chokhani ([12.91.132.91]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030103202821.PEDC9286.mtiwmhc11.worldnet.att.net@Chokhani> for ; Fri, 3 Jan 2003 20:28:21 +0000 From: "Santosh Chokhani" To: Subject: RE: Offline Root CA with valid CRL hierachie Date: Fri, 3 Jan 2003 15:28:53 -0500 Message-ID: <000e01c2b366$bbed4380$5b845b0c@Chokhani> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E15E7B1.C94384AE@sun.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve: The question is not of Root revocation, but of establishing trust in and checking the revocation status (if the trust is certificate based) of the OCSP Responder itself. In the other comments, I do not see an area where you disagree with me. If you do, please point that out to me. -----Original Message----- From: Steve Hanna [mailto:steve.hanna@sun.com] Sent: Friday, January 03, 2003 2:43 PM To: Santosh Chokhani Cc: ietf-pkix@imc.org Subject: Re: Offline Root CA with valid CRL hierachie Santosh Chokhani wrote: > I am thoroughly confused. First, what I am proposing will work if the > RP is using indirect CRL. I am making a modest assumption that an RP > that can process indirect CRL can also process full and complete CRL. Right. The primary benefit of pre-issued CRLs over indirect CRLs or OCSP is that pre-issued CRLs work with any RP that can process CRLs (any RFC 3280 compliant RP) whereas the others require support for features not required by RFC 3280. > In terms of OCSP, if your solution is OCSP only, I still think the > approach I suggest will be a good way to supply the revocation > information to the OCSP responders, specially if there are many of > them or if you want to the convenience of distributing the revocation > information over untrusted networks. I don't know much about how people generally supply revocation information to OCSP responders. Certainly, I expect that your system would work fine. But I expect that many OCSP responders would support indirect CRLs, so that might also be a solution. And some people might just use SSH. I don't know. > How the OCSP Responder for off-line root revocation should be > architected is a separate topic with its own nuances. I didn't think we were discussing how to revoke a root. As you say, that's a separate topic. Let's leave it aside for now, unless there's some pressing need to address it. -Steve From owner-ietf-pkix Fri Jan 3 14:19:22 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03MJM918105 for ietf-pkix-bks; Fri, 3 Jan 2003 14:19:22 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h03MJLo18101 for ; Fri, 3 Jan 2003 14:19:21 -0800 (PST) Received: (qmail 4298 invoked from network); 3 Jan 2003 22:19:03 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.161.121) by woodstock.binhost.com with SMTP; 3 Jan 2003 22:19:03 -0000 Message-Id: <5.2.0.9.2.20030103170608.028bcaa8@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 03 Jan 2003 17:18:54 -0500 To: Kurt@OpenLDAP.org From: Russ Housley Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option) Cc: Peter.Gietz@daasi.de, ietf-pkix@imc.org In-Reply-To: <5.2.0.9.0.20021230223309.01dc1a40@127.0.0.1> References: <3E0C719B.2080705@daasi.de> <000901c29759$9f4d1df0$a518200a@osmium.mtwav.adacel.com.au> <3DE6E706.4050102@stroeder.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt: I must voice my disagreement with this approach, again. This approach adds complexity to the PKI client. In the long run, a PKI client must look in two places to locate a certificate. The client cannot know if the PKI "child entry" approach or the component matching approach was used by the administrator posting the information. As a result, the PKI client must first look in the userCertificate attribute of the subject entry. If the PKI client does not find the expected certificate, then it must search for child entries. I want to pick one or the other, not live with checking both for the foreseeable future. If we pick the PKI "child entry" approach, then this should be the only way that certificates are stored. This means a standards track document, not an informational or experimental one. If we pick the component matching approach, then we can write the standards track document now, but we will have to wait for development and deployment of updated software. WE MUST PICK ONE APPROACH, NOT TWO! Russ At 11:37 PM 12/30/2002 -0800, Kurt D. Zeilenga wrote: >My recommendation is that the PKI "child entry" approach be >pursued individually as an Experimental (or possibly Informational) >solution to the PKI component matching problem with a note that >a more general solution, component matching, is being standardized. From owner-ietf-pkix Fri Jan 3 14:15:20 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03MFKc18051 for ietf-pkix-bks; Fri, 3 Jan 2003 14:15:20 -0800 (PST) Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03MFJo18047 for ; Fri, 3 Jan 2003 14:15:19 -0800 (PST) Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by mailb.telia.com (8.12.5/8.12.5) with SMTP id h03MFIGS005997 for ; Fri, 3 Jan 2003 23:15:18 +0100 (CET) X-Original-Recipient: Message-ID: <00be01c2b375$5764e210$0500a8c0@arport> From: "Anders Rundgren" To: Subject: "Web Services" PKI RFC Date: Fri, 3 Jan 2003 23:13:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear all, I am interested in creating an RFC (or similar) for a certificate- profile matching the needs of the emerging "Web Services" technology. The major reason for creating a specific profile is that Web Services are plug-and-play while plain-vanilla X.509 is not. Some initial work has already been carried out but I would like to get in contact with other people who: - Know SQL, XML, Java, X.509, and to some extent ASN.1 - Are genuinely interested in PKI-enabling business systems - See user- and market-acceptance as the #1 issue Exactly where the possible result will land is still open, it could be in OASIS as well as this seems to be the "Home of Web Services". Anders Rundgren Senior Internet e-Commerce Architect +46 70 - 627 74 37 (CET 9.00-21.00) From owner-ietf-pkix Fri Jan 3 17:32:08 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h041W8a02255 for ietf-pkix-bks; Fri, 3 Jan 2003 17:32:08 -0800 (PST) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h041W6o02251 for ; Fri, 3 Jan 2003 17:32:06 -0800 (PST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h041W3bT024728; Sat, 4 Jan 2003 14:32:03 +1300 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h041W2719281; Sat, 4 Jan 2003 14:32:02 +1300 Date: Sat, 4 Jan 2003 14:32:02 +1300 Message-Id: <200301040132.h041W2719281@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: housley@vigilsec.com, tgindin@us.ibm.com Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-03.txt Cc: ietf-pkix@imc.org, jjacoby@rsasecurity.com, pgut001@cs.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Tom Gindin" writes: >Of course I have no objection to mentioning a preference for subjectAltName >over subject for e-mail addresses. I just thought that anybody actually >implementing something which extracts e-mail addresses from certificates >would be helped by knowing all the places which are used in large numbers of >certificates, not just the approved ones. In the earlier wording ("an >rfc822Name attribute") I wasn't sure whether implementors would interpret >this as the rfc822mailbox directory attribute or the rfc822Name component of >GeneralName, anyway. I've actually reworded it to use mostly a very generic "email address associated with the cert" (someone pointed out that there doesn't actually have to be an email address in the cert for it to be associated with one). The intent was never to provide an exhaustive enumeration of all possible places it could be hidden, just to say that it was whatever address(es) were associated with the cert. Peter. From owner-ietf-pkix Fri Jan 3 18:00:08 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h04208g03462 for ietf-pkix-bks; Fri, 3 Jan 2003 18:00:08 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h04207o03458 for ; Fri, 3 Jan 2003 18:00:07 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id h042040a009710; Sat, 4 Jan 2003 02:00:05 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030103171102.024f3360@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 03 Jan 2003 17:59:51 -0800 To: Russ Housley From: "Kurt D. Zeilenga" Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option) Cc: Peter.Gietz@daasi.de, ietf-pkix@imc.org In-Reply-To: <5.2.0.9.2.20030103170608.028bcaa8@mail.binhost.com> References: <5.2.0.9.0.20021230223309.01dc1a40@127.0.0.1> <3E0C719B.2080705@daasi.de> <000901c29759$9f4d1df0$a518200a@osmium.mtwav.adacel.com.au> <3DE6E706.4050102@stroeder.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here are my recommendations to the PKIX WG: The PKIX WG should not take on engineering of a PKI-specific solution to the certificate matching / returning problems which draft-klasen-ldap-x509certificate-schema. General solutions suitable for standardization exist to resolve these problems. The PKIX WG should, as part of its PKI LDAPv3 applicability statement work, detail requirements of PKI implementations to support: a) existing LDAP PKI schema (as revised by PKIX WG) b) component matching rule extension c) matched values control extension The PKIX WG should revise the LDAPv3 PKI Schema in a manner which preserves existing interoperability (e.g., add missing matching rules to userCertificate and friends, fix up reference to X.509, etc.). At 02:18 PM 1/3/2003, Russ Housley wrote: >I must voice my disagreement with this approach, again. Let me rephrase the part I think you object to: I have no objection to the proponents of draft-klasen-ldap-x509certificate-schema continuing to pursuing their work on an individual basis. In its current form, I would oppose publication as a non-Experimental RFC. As an Experimental RFC, I would ask that an IESG Note be added to the document clarifying that the document details an alternative to existing and future IETF standards which implementors should favor. Kurt From owner-ietf-pkix Sat Jan 4 08:43:57 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h04Ghvh18149 for ietf-pkix-bks; Sat, 4 Jan 2003 08:43:57 -0800 (PST) Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h04Ghuo18144 for ; Sat, 4 Jan 2003 08:43:57 -0800 (PST) Received: from mail3.magma.ca (mail3.magma.ca [206.191.0.221]) by mx1.magmacom.com (Magma's Mail Server) with ESMTP id h04Ghv1t017490; Sat, 4 Jan 2003 11:43:57 -0500 (EST) Received: from asturgeonpc (ssm-on50-158.netcom.ca [142.154.169.30]) by mail3.magma.ca (Magma's Mail Server) with SMTP id h04Ghuh9013381; Sat, 4 Jan 2003 11:43:56 -0500 (EST) Reply-To: From: "Alice Sturgeon" To: "Anders Rundgren" , Subject: RE: "Web Services" PKI RFC Date: Sat, 4 Jan 2003 11:47:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <00be01c2b375$5764e210$0500a8c0@arport> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Anders, FYI, ISO/IEC JTC 1 is initiating a 'study period' to consider whether JTC 1 and its sub-committees should work on standardization in the area of Web services. This is at the point of soliciting interest from the national bodies that participate in JTC 1. We should know probably by the end of January whether there is sufficient interest to go ahead with this. If we do, then there would clearly be synergy on this issue between JTC 1 and any work by IETF. I volunteered to participate because it is of interest to me. Concerning your call for interest, I would say 'yes' to the last two points (genuine interest in PKI-enabling business systems and consider user/market acceptance as the number one issue), but not the first (except for the X.509 part). I will let you know the outcome of the JTC 1 initiative. Alice Alice Sturgeon Chair Canadian Advisory Committee - Information Technology Security ISO/IEC JTC1 SC 27 and System Policy Architect SPYRUS Phone: 613-232-2350 Cell: 613-291-0331 -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Anders Rundgren Sent: January 3, 2003 5:13 PM To: ietf-pkix@imc.org Subject: "Web Services" PKI RFC Dear a