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 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 Sat Jan 4 09:11:51 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h04HBp218597 for ietf-pkix-bks; Sat, 4 Jan 2003 09:11:51 -0800 (PST) Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h04HBoo18592 for ; Sat, 4 Jan 2003 09:11:50 -0800 (PST) Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by maila.telia.com (8.12.5/8.12.5) with SMTP id h04HBo3Y008530; Sat, 4 Jan 2003 18:11:50 +0100 (CET) X-Original-Recipient: ietf-pkix@imc.org Message-ID: <016701c2b414$1bee1a90$0500a8c0@arport> From: "Anders Rundgren" To: , References: Subject: Re: "Web Services" PKI RFC Date: Sat, 4 Jan 2003 18:09:57 +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: Thanx Alice, You are the third person indicating interest in this! Maybe Web Services is really as "red hot" as I always claim it is :-) BTW, there are some outstanding warranty-issues to cater for as well... More to read : http://www.verisign.com/netsure "Limited Liability Warranty" (!) Best Anders ----- Original Message ----- From: "Alice Sturgeon" To: "Anders Rundgren" ; Sent: Saturday, January 04, 2003 17:47 Subject: RE: "Web Services" PKI RFC 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 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 Sat Jan 4 09:23:51 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h04HNpC18893 for ietf-pkix-bks; Sat, 4 Jan 2003 09:23:51 -0800 (PST) Received: from mail.hackmasters.net (ppp-217-133-8-148.dialup.tiscali.it [217.133.8.148]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h04HNlo18887 for ; Sat, 4 Jan 2003 09:23:48 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hackmasters.net (Postfix) with ESMTP id 641FFF35C for ; Sat, 4 Jan 2003 18:22:27 +0100 (CET) Received: by mail.hackmasters.net (Postfix, from userid 509) id B8E9CF368; Sat, 4 Jan 2003 18:22:20 +0100 (CET) Received: from hackmasters.net (galadriel.mpnet.hackmasters.net [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id B82FCF35C for ; Sat, 4 Jan 2003 18:22:18 +0100 (CET) Message-ID: <3E1718C7.8040100@hackmasters.net> Date: Sat, 04 Jan 2003 18:24:23 +0100 From: Massimiliano Pala Organization: OpenCA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: OCSP and LDAP Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020405030008000600070108" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020405030008000600070108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, it might be an old question but If you can not answer me I really don't know where to look... Here it is. We are trying to rebuild our OCSPd backend and one of the possibilities was to use the LDAP server to store (besides the issued certificates) informations needed to the OCSPd to build the responses (i.e. at least the status of the certificates). Are there RFCs/raccomandations that will help us in using a good schema for storing this kind of informations and in not making big mistakes ? Thank to you all for all the work you are doing. -- C'you on the bit stream, Massimiliano Pala --o------------------------------------------------------------------------- Massimiliano Pala [OpenCA Project Manager] madwolf@openca.org Tel.: +39 (0)59 270 094 http://www.openca.org Fax: +39 178 221 8225 http://openca.sourceforge.net Mobile: +39 (0)347 7222 365 --------------ms020405030008000600070108 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOZjCC By8wggYXoAMCAQICASwwDQYJKoZIhvcNAQEEBQAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5j aWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9u ZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkG A1UEBhMCSVQwHhcNMDIwNzI0MTUyNjI2WhcNMDMxMjMxMjM1OTU5WjCBqTEaMBgGA1UEAxMR TWFzc2ltaWxpYW5vIFBhbGExNTAzBgNVBAsTLERpcGFydGltZW50byBkaSBJbmdlZ25lcmlh IGRlbGwnSW5mb3JtYXppb25lMRcwFQYDVQQLEw5TZWRlIGRpIE1vZGVuYTEuMCwGA1UEChMl VW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQwgZ8w DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANSesg80BGzryvQlplD0MJ2YWlSEUAZpiFmywpOm l//lWMnhONmC/q0TrO7j9Bb195dNzCMuXFgvV49Sy1iyHAjDhpysFvm/xZbAS3j8prXNN23K S3Oa7Zz2GrQpCHgupCPQL2cy+ARVwwFod2GOSCVoUACkndit964K/bfsGvyLAgMBAAGjggQB MIID/TAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCA/gw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6aSO5yTMPTf9OdcWo 14pKLqEHMDCBtwYDVR0jBIGvMIGsgBRFHaYA4ZfoyU2aaUnZYMiYf4lFA6GBkKSBjTCBijEi MCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMeVW5pbW9yZSBF bnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBkaSBNb2RlbmEg ZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVIIBADBqBglghkgBhvhCAQ0EXRZbUHJvZ2V0 dG8gUG9zdGEgRWxldHRyb25pY2EgU2ljdXJhIA0KVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUg UmVnZ2lvIEVtaWxpYSANCkMuSS5DLkEuSS5BLiANCjAiBgNVHREEGzAZgRdtYWR3b2xmQGhh Y2ttYXN0ZXJzLm5ldDA0BgNVHRIELTArgRNwa2kuY2ljYWlhQHVuaW1vLml0hhRodHRwOi8v cGtpLnVuaW1vLml0LzA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAKGI2h0dHA6Ly9wa2ku dW5pbW8uaXQvY2EvaXNzdWVycy5odG1sMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9wa2ku dW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQQEIxYhaHR0cDovL3BraS51bmlt by5pdC9jcmwvY2FjcmwuY3JsMDAGCWCGSAGG+EIBAwQjFiFodHRwOi8vcGtpLnVuaW1vLml0 L2NybC9jYWNybC5jcmwwKgYJYIZIAYb4QgEHBB0WG2h0dHA6Ly9wa2kudW5pbW8uaXQvcmVu ZXdhbDArBglghkgBhvhCAQgEHhYcaHR0cDovL3BraS51bmltby5pdC9jcHMvMS4xLzCB2QYD VR0gBIHRMIHOMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJv cGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMEEGCisGAQQBqQcCAQEwMzAxBggrBgEFBQcCARYl aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBEBgorBgEEAegTAQEBMDYw NAYIKwYBBQUHAgEWKGh0dHA6Ly9tYWlsLnVuaW1vLml0L2Zpcm1hL2Nwc21vZGVuYS5odG0w DQYJKoZIhvcNAQEEBQADggEBABn8ViNg4MPNRzEFFF4BsmRMP1YbUHbS+NmFvvys0D3xueex Ie6HU+tkv9hz8++0MbLPnRY2qKpZXfWTbIOkrHLGVVHUkiZXFzfxsDMgcB4MWmSmhRVLfPqr RZKAjIevO0JKIksq2xutAUqX5jkqZoGHpPv9JCiSI+cDRqOOW2Fh3JBGkcULKybrdwrSN6+S NoTyTXR+ryeTBUXxu9rIbjrJdH3rKS7rz3ZkP2PKuFOb+Vbp829ALph1SJOLQrUnmJouLOSL oVHW4zJK4zcAiNyMHua3HveLRkVINT9eDBeYBRPdn1k+LqdXqkXiEUPA+EIKeA23F5nQkqxI mVVpaaYwggcvMIIGF6ADAgECAgEsMA0GCSqGSIb3DQEBBAUAMIGKMSIwIAYJKoZIhvcNAQkB FhNwa2kuY2ljYWlhQHVuaW1vLml0MScwJQYDVQQDEx5Vbmltb3JlIEVudGUgZGkgQ2VydGlm aWNhemlvbmUxLjAsBgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWls aWExCzAJBgNVBAYTAklUMB4XDTAyMDcyNDE1MjYyNloXDTAzMTIzMTIzNTk1OVowgakxGjAY BgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMTUwMwYDVQQLEyxEaXBhcnRpbWVudG8gZGkgSW5n ZWduZXJpYSBkZWxsJ0luZm9ybWF6aW9uZTEXMBUGA1UECxMOU2VkZSBkaSBNb2RlbmExLjAs BgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWlsaWExCzAJBgNVBAYT AklUMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUnrIPNARs68r0JaZQ9DCdmFpUhFAG aYhZssKTppf/5VjJ4TjZgv6tE6zu4/QW9feXTcwjLlxYL1ePUstYshwIw4acrBb5v8WWwEt4 /Ka1zTdtyktzmu2c9hq0KQh4LqQj0C9nMvgEVcMBaHdhjkglaFAApJ3YrfeuCv237Br8iwID AQABo4IEATCCA/0wDAYDVR0TAQH/BAIwADARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/ BAQDAgP4MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+mkjuckz D03/TnXFqNeKSi6hBzAwgbcGA1UdIwSBrzCBrIAURR2mAOGX6MlNmmlJ2WDImH+JRQOhgZCk gY0wgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVu aW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkg TW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVSCAQAwagYJYIZIAYb4QgENBF0W W1Byb2dldHRvIFBvc3RhIEVsZXR0cm9uaWNhIFNpY3VyYSANClVuaXZlcnNpdGEnIGRpIE1v ZGVuYSBlIFJlZ2dpbyBFbWlsaWEgDQpDLkkuQy5BLkkuQS4gDQowIgYDVR0RBBswGYEXbWFk d29sZkBoYWNrbWFzdGVycy5uZXQwNAYDVR0SBC0wK4ETcGtpLmNpY2FpYUB1bmltby5pdIYU aHR0cDovL3BraS51bmltby5pdC8wPwYIKwYBBQUHAQEEMzAxMC8GCCsGAQUFBzAChiNodHRw Oi8vcGtpLnVuaW1vLml0L2NhL2lzc3VlcnMuaHRtbDAyBgNVHR8EKzApMCegJaAjhiFodHRw Oi8vcGtpLnVuaW1vLml0L2NybC9jYWNybC5jcmwwMAYJYIZIAYb4QgEEBCMWIWh0dHA6Ly9w a2kudW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQMEIxYhaHR0cDovL3BraS51 bmltby5pdC9jcmwvY2FjcmwuY3JsMCoGCWCGSAGG+EIBBwQdFhtodHRwOi8vcGtpLnVuaW1v Lml0L3JlbmV3YWwwKwYJYIZIAYb4QgEIBB4WHGh0dHA6Ly9wa2kudW5pbW8uaXQvY3BzLzEu MS8wgdkGA1UdIASB0TCBzjBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93 d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYB BQUHAgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRAYKKwYBBAHo EwEBATA2MDQGCCsGAQUFBwIBFihodHRwOi8vbWFpbC51bmltby5pdC9maXJtYS9jcHNtb2Rl bmEuaHRtMA0GCSqGSIb3DQEBBAUAA4IBAQAZ/FYjYODDzUcxBRReAbJkTD9WG1B20vjZhb78 rNA98bnnsSHuh1PrZL/Yc/PvtDGyz50WNqiqWV31k2yDpKxyxlVR1JImVxc38bAzIHAeDFpk poUVS3z6q0WSgIyHrztCSiJLKtsbrQFKl+Y5KmaBh6T7/SQokiPnA0ajjlthYdyQRpHFCysm 63cK0jevkjaE8k10fq8nkwVF8bvayG46yXR96yku6892ZD9jyrhTm/lW6fNvQC6YdUiTi0K1 J5iaLizki6FR1uMySuM3AIjcjB7mtx73i0ZFSDU/XgwXmAUT3Z9ZPi6nV6pF4hFDwPhCCngN txeZ0JKsSJlVaWmmMYIDNjCCAzICAQEwgZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNh aWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEu MCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UE BhMCSVQCASwwCQYFKw4DAhoFAKCCAfswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDMwMTA0MTcyNDIzWjAjBgkqhkiG9w0BCQQxFgQUSdMzFqDHDSReEHAT A0OUTo+Z3hMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaEGCSsGAQQBgjcQBDGB kzCBkDCBijEiMCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMe VW5pbW9yZSBFbnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBk aSBNb2RlbmEgZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVAIBLDCBowYLKoZIhvcNAQkQ AgsxgZOggZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNV BAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0 YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQCASwwDQYJKoZIhvcN AQEBBQAEgYCLW9J3c7zL5LZO0o7PzCQVHerB8bdoM31v0DDCLUFSKaTeHc7vVZYeRhLvoc+K M9O1V/2lFV8ZQ5zzXe1mDLcg/PaqrhjDIXHDYEs0pedgQE8LVA1g/3rfLiAGz9RTqTRcVJB5 UzZHjR7VFqb+wnGt3WEWzJQ9aAJTVpVwlbmCXAAAAAAAAA== --------------ms020405030008000600070108-- From owner-ietf-pkix Sat Jan 4 11:43:26 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h04JhQu26864 for ietf-pkix-bks; Sat, 4 Jan 2003 11:43:26 -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 h04JhPo26860 for ; Sat, 4 Jan 2003 11:43:25 -0800 (PST) Received: (qmail 28843 invoked from network); 4 Jan 2003 19:43:05 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.33.28) by woodstock.binhost.com with SMTP; 4 Jan 2003 19:43:05 -0000 Message-Id: <5.2.0.9.2.20030104143955.025a3e98@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 04 Jan 2003 14:42:25 -0500 To: "Kurt D. Zeilenga" 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.20030103171102.024f3360@127.0.0.1> References: <5.2.0.9.2.20030103170608.028bcaa8@mail.binhost.com> <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"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt: I can support this position, as it sicks one solution for use in the PKIX schema. It picks the certificate matching approach, which is fine with me. It does mean that deployment will require servers and clients to be upgraded. This is also fine with me. The alternative requires client to be upgraded, but not servers. Russ At 05:59 PM 1/3/2003 -0800, Kurt D. Zeilenga wrote: >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 12:45:48 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h04KjmH04625 for ietf-pkix-bks; Sat, 4 Jan 2003 12:45:48 -0800 (PST) Received: from gil.axelero.hu (mail01.axelero.hu [195.228.240.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h04Kjko04618 for ; Sat, 4 Jan 2003 12:45:47 -0800 (PST) Received: from houston (adsl-169-75.adsl-pool.axelero.hu [62.201.75.169]) by mail01.axelero.hu (iPlanet Messaging Server 5.1 HotFix 1.9 (built Dec 3 2002)) with SMTP id <0H8700K0GJ06Y2@mail01.axelero.hu> for ietf-pkix@imc.org; Sat, 04 Jan 2003 21:45:43 +0100 (MET) Date: Sat, 04 Jan 2003 21:45:43 +0100 From: Adam Tresch Subject: RE: OCSP and LDAP In-reply-to: <3E1718C7.8040100@hackmasters.net> To: Massimiliano Pala , PKIX Working Group Reply-to: adam.tresch@quattrosoft.hu Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: multipart/signed; boundary="----=_NextPart_000_0013_01C2B43A.9E8A6CD0"; micalg=SHA1; protocol="application/x-pkcs7-signature" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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_0013_01C2B43A.9E8A6CD0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Massimiliano, if am i right, then the easyest way to retreive the cert status form the actual CRL. You dont need to extand the schema, use only the valid CRL as the source of the info. But, in this case, the CA must issue a new crl after each revocation immediately. Adam -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Massimiliano Pala Sent: Saturday, January 04, 2003 6:24 PM To: ietf-pkix@imc.org Subject: OCSP and LDAP Hi all, it might be an old question but If you can not answer me I really don't know where to look... Here it is. We are trying to rebuild our OCSPd backend and one of the possibilities was to use the LDAP server to store (besides the issued certificates) informations needed to the OCSPd to build the responses (i.e. at least the status of the certificates). Are there RFCs/raccomandations that will help us in using a good schema for storing this kind of informations and in not making big mistakes ? Thank to you all for all the work you are doing. -- C'you on the bit stream, Massimiliano Pala --o----------------------------------------------------------------------- -- Massimiliano Pala [OpenCA Project Manager] madwolf@openca.org Tel.: +39 (0)59 270 094 http://www.openca.org Fax: +39 178 221 8225 http://openca.sourceforge.net Mobile: +39 (0)347 7222 365 ------=_NextPart_000_0013_01C2B43A.9E8A6CD0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHJTCCA44w ggJ2oAMCAQICBQC6vvrPMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkhVMRQwEgYDVQQKEwtR dWF0dHJvc29mdDERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlF1YXR0cm9zb2Z0IENBMB4X DTAyMTIxNjIzMzMwN1oXDTAzMTIxNjIzMzMwN1owgZAxCzAJBgNVBAYTAkhVMRQwEgYDVQQKEwtR dWF0dHJvc29mdDERMA8GA1UECxMIRW1wbG95ZWUxFzAVBgoJkiaJk/IsZAEBEwdhdHJlc2NoMRQw EgYDVQQDEwtBZGFtIFRyZXNjaDEpMCcGCSqGSIb3DQEJARYaYWRhbS50cmVzY2hAcXVhdHRyb3Nv ZnQuaHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJaUVwTsvg1sYmPSGZThAqaLRuLCEBq1 30tOrdBhYhetEwUvn/48HeTvBm6D7yrvzQ9Xa0ITkUJ57JDOliZj8GLtrXFWG2fuyNZ3c+UOW6CY 1hCNaECue8QBQvO7ZltMTXyqVK1rc57fveyr1mDTKX3pUJkfX2hC2TzcuV2e0aJrAgMBAAGjgbIw ga8wDgYDVR0PAQH/BAQDAgUgMBEGCWCGSAGG+EIBAQQEAwIFoDAfBgNVHSMEGDAWgBR3LnB+p+Gk jVMa4mVPrrAVrGpzlzAlBgNVHREEHjAcgRphZGFtLnRyZXNjaEBxdWF0dHJvc29mdC5odTBCBggr BgEFBQcBAQQ2MDQwMgYIKwYBBQUHMAGGJmh0dHA6Ly90aW1idWt0dS5jZW50YXVydXMuaHU6ODAw MC9vY3NwMA0GCSqGSIb3DQEBBQUAA4IBAQB2LKh/tyX3rXyYU58FILr/3r4vPDZI4dqEV8xgfp5w Kg2rcQhAHjBL6FmDuJtTBbGgjGqEua6DF5/l1pYXabwQ80WinY73M/Cde0e8Qr411/VX44q4wb1M RNgeWtMDKiKs5rQCE70WB1M7TjgV4Rxr3kOF2hlbtwMYAhYOao/k9vfrIiwy8t2FoMgJ7hBqJlPv WuxkZQnCH3uBECzECpyFBlrQv3Mf5f+vkLJHK26rey2xapMSrBynG4qXLBMz4T92geV9++hWiPoq ptuOTxVp39BdcRI96csOf157cTjOI/cStwlOy9cuxI+lSTFU7hvKob1FTGeAU02c0rzc1GgdMIID jzCCAnegAwIBAgIFALq++tAwDQYJKoZIhvcNAQEFBQAwTzELMAkGA1UEBhMCSFUxFDASBgNVBAoT C1F1YXR0cm9zb2Z0MREwDwYDVQQLEwhTZWN1cml0eTEXMBUGA1UEAxMOUXVhdHRyb3NvZnQgQ0Ew HhcNMDIxMjE2MjMzMzA3WhcNMDMxMjE2MjMzMzA3WjCBkDELMAkGA1UEBhMCSFUxFDASBgNVBAoT C1F1YXR0cm9zb2Z0MREwDwYDVQQLEwhFbXBsb3llZTEXMBUGCgmSJomT8ixkAQETB2F0cmVzY2gx FDASBgNVBAMTC0FkYW0gVHJlc2NoMSkwJwYJKoZIhvcNAQkBFhphZGFtLnRyZXNjaEBxdWF0dHJv c29mdC5odTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtdEvNmRSSpLBMMHv/FoeJ9GZ6LU9 Mz59dENo/fO6m5WLRA15jKApj5wG1fQKL93u+R+H9YIZ4cNM44XJjgSIxQ8O495iiHl+XrniJLld 0bwWnx77XtGAOGjZi3Re8bC27igvFnDK+mXhQruO7Z9CIuqtu+r6txBd5MRiwRSLnl8CAwEAAaOB szCBsDAPBgNVHQ8BAf8EBQMDB4AAMBEGCWCGSAGG+EIBAQQEAwIFoDAfBgNVHSMEGDAWgBR3LnB+ p+GkjVMa4mVPrrAVrGpzlzAlBgNVHREEHjAcgRphZGFtLnRyZXNjaEBxdWF0dHJvc29mdC5odTBC BggrBgEFBQcBAQQ2MDQwMgYIKwYBBQUHMAGGJmh0dHA6Ly90aW1idWt0dS5jZW50YXVydXMuaHU6 ODAwMC9vY3NwMA0GCSqGSIb3DQEBBQUAA4IBAQAU8wHSSupdfso5O7Lz0PpzDSnti29bzMoCx8nC DgzXGCyQIgP51J7/Ahl/L7qH2Zb5jWnGKWPH7D+tJUpCzDMDTsdYfadolvnNgR9XmW5fhBfgP7bJ yv5VT46GSfSYwjCCIm6F+f2UJhzXt0FRWZmEu1Pu9GFj8znCrhpeVXFKM0iDYOqSPBZUyPgzc4hy autzLGd3gpP6z05gitgH5KhtBPJ5HJ8Ila1Oo00jrShTwnkiY+Eo8DtXAeWC2m0n5P08xgUFGkYe md8O0Xrs6RcIUX+BuLXb7Vm92ArI8jPwAGg2MhcCufXLILD4JgA9UNOdDfwN8ok++bRG3B1FWT8O MYICIjCCAh4CAQEwWDBPMQswCQYDVQQGEwJIVTEUMBIGA1UEChMLUXVhdHRyb3NvZnQxETAPBgNV BAsTCFNlY3VyaXR5MRcwFQYDVQQDEw5RdWF0dHJvc29mdCBDQQIFALq++tAwCQYFKw4DAhoFAKCC ASAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDMwMTA0MjA0NTM4 WjAjBgkqhkiG9w0BCQQxFgQU3vYYbykV5cfODbtdtcLs3+IbY3UwWAYJKoZIhvcNAQkPMUswSTAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4D AhowCgYIKoZIhvcNAgUwZwYJKwYBBAGCNxAEMVowWDBPMQswCQYDVQQGEwJIVTEUMBIGA1UEChML UXVhdHRyb3NvZnQxETAPBgNVBAsTCFNlY3VyaXR5MRcwFQYDVQQDEw5RdWF0dHJvc29mdCBDQQIF ALq++s8wDQYJKoZIhvcNAQEBBQAEgYB2c1HNT/zejVSETmEOL1Ux9XfjlX2SozqFnP7QHfw57R20 sXCvpeRmrWK7IiRfKVYXcZWWZydGvKobKFS1IECF+oqeOieBc88Ivo+nBZwIqXyzd6vpGm05GdcD Q+ViaDFRBBx/zQdwt1h6EcAvuhQ1YeFz1AEYpf9FCfUx+3KuogAAAAAAAA== ------=_NextPart_000_0013_01C2B43A.9E8A6CD0-- From owner-ietf-pkix Sat Jan 4 14:54:51 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h04Mspk17273 for ietf-pkix-bks; Sat, 4 Jan 2003 14:54:51 -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 h04Msoo17269 for ; Sat, 4 Jan 2003 14:54:50 -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 h04MseZp028974; Sat, 4 Jan 2003 14:54:41 -0800 From: "Ambarish Malpani" To: "Massimiliano Pala" , Subject: RE: OCSP and LDAP Date: Sat, 4 Jan 2003 14:54:52 -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: <3E1718C7.8040100@hackmasters.net> 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 Massimiliano, You should seriously consider having your responder work off a CA's CRL, rather than trying to access its database directly. There are a set of reasons why this is a good idea. Here are are few (in no particular order): - CA independence (might not be important for you) - Helps auditability of the VA - Allows better control over replication (where you don't need to rely on LDAP replication - most CAs won't want to replicate the rest of their LDAP data) - Better performance - can keep the revocation data in memory and respond from memory - won't need to also have a LDAP lookup Hope this helps, 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 Massimiliano Pala > Sent: Saturday, January 04, 2003 9:24 AM > To: ietf-pkix@imc.org > Subject: OCSP and LDAP > > > Hi all, > > it might be an old question but If you can not answer me I really > don't know > where to look... Here it is. > > We are trying to rebuild our OCSPd backend and one of the > possibilities was > to use the LDAP server to store (besides the issued certificates) > informations > needed to the OCSPd to build the responses (i.e. at least the > status of the > certificates). > > Are there RFCs/raccomandations that will help us in using a good schema > for storing this kind of informations and in not making big mistakes ? > > Thank to you all for all the work you are doing. > > -- > > C'you on the bit stream, > > Massimiliano Pala > > --o--------------------------------------------------------------- > ---------- > Massimiliano Pala [OpenCA Project Manager] > madwolf@openca.org > Tel.: +39 > (0)59 270 094 > http://www.openca.org Fax: +39 > 178 221 8225 > http://openca.sourceforge.net Mobile: +39 > (0)347 7222 365 > From owner-ietf-pkix Sat Jan 4 21:31:39 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h055Vd721859 for ietf-pkix-bks; Sat, 4 Jan 2003 21:31:39 -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 h055Vbo21854 for ; Sat, 4 Jan 2003 21:31:37 -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 h055VKbT012209; Sun, 5 Jan 2003 18:31:20 +1300 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h055VIh31601; Sun, 5 Jan 2003 18:31:18 +1300 Date: Sun, 5 Jan 2003 18:31:18 +1300 Message-Id: <200301050531.h055VIh31601@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ambarish@malpani.biz, ietf-pkix@imc.org, madwolf@hackmasters.net Subject: RE: OCSP and LDAP Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Ambarish Malpani" writes: >You should seriously consider having your responder work off a CA's CRL, >rather than trying to access its database directly. There are a set of >reasons why this is a good idea. Here are are few (in no particular order): You should seriously consider having your responder work off a CA's database rather than trying to use CRLs. There are a set of reasons why this is a good idea. Here are are few (in no particular order): - Real-time cert status rather than inserting an artificial delay for compatibility with OSI ideology (someone once said that the only reason you'd want to drive an online status protocol from an offline mechanism is if you wanted to emphasise how broken it was [0]). - Much better performance (I have an RFC draft in the works which looks at this which should be out RSN, I hope). You can't build a faster system than the one described in the RFC. (Actually in the process of working on the RFC draft, I've discovered that there are already a surprising number of implementations which work directly from a CA database, some dating back to before OCSP was even an RFC. Standardising this operation, rather than having everyone do their own proprietary version, was one of the motivations for writing the draft). [0] I've lost the source of this quote, if it's yours please let me know so I can attribute it. Hope this helps, Regards, Peter. From owner-ietf-pkix Sat Jan 4 23:53:51 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h057rp207171 for ietf-pkix-bks; Sat, 4 Jan 2003 23:53:51 -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 h057roo07164 for ; Sat, 4 Jan 2003 23:53:50 -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 h057rbZp029126; Sat, 4 Jan 2003 23:53:38 -0800 From: "Ambarish Malpani" To: "Peter Gutmann" , , Subject: RE: OCSP and LDAP Date: Sat, 4 Jan 2003 23:53:50 -0800 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) In-Reply-To: <200301050531.h055VIh31601@medusa01.cs.auckland.ac.nz> 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 Peter, I have still to see a place where using CRLs as the mechanism for letting a VA know of changes in the revocation data has led to poorer performance than having the VA access the CA's database directly. It also allows larger PKIs to deploy responders in multiple remote locations (where they might not want to replicate their CAs databases). 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 Peter Gutmann > Sent: Saturday, January 04, 2003 9:31 PM > To: ambarish@malpani.biz; ietf-pkix@imc.org; madwolf@hackmasters.net > Subject: RE: OCSP and LDAP > > > > "Ambarish Malpani" writes: > > >You should seriously consider having your responder work off a CA's CRL, > >rather than trying to access its database directly. There are a set of > >reasons why this is a good idea. Here are are few (in no > particular order): > > You should seriously consider having your responder work off a > CA's database > rather than trying to use CRLs. There are a set of reasons why > this is a good > idea. Here are are few (in no particular order): > > - Real-time cert status rather than inserting an artificial delay for > compatibility with OSI ideology (someone once said that the only reason > you'd want to drive an online status protocol from an offline mechanism > is if you wanted to emphasise how broken it was [0]). > > - Much better performance (I have an RFC draft in the works which looks at > this which should be out RSN, I hope). You can't build a > faster system than > the one described in the RFC. > > (Actually in the process of working on the RFC draft, I've > discovered that > there are already a surprising number of implementations which > work directly > from a CA database, some dating back to before OCSP was even an RFC. > Standardising this operation, rather than having everyone do their own > proprietary version, was one of the motivations for writing the draft). > > [0] I've lost the source of this quote, if it's yours please let > me know so I > can attribute it. > > Hope this helps, > Regards, > Peter. > From owner-ietf-pkix Sun Jan 5 00:23:59 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h058NxK11319 for ietf-pkix-bks; Sun, 5 Jan 2003 00:23:59 -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 h058Nvo11310 for ; Sun, 5 Jan 2003 00:23:57 -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 h058KGbT013676; Sun, 5 Jan 2003 21:20:16 +1300 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h058KHj00419; Sun, 5 Jan 2003 21:20:17 +1300 Date: Sun, 5 Jan 2003 21:20:17 +1300 Message-Id: <200301050820.h058KHj00419@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ambarish@malpani.biz, ietf-pkix@imc.org, madwolf@hackmasters.net, pgut001@cs.auckland.ac.nz Subject: RE: OCSP and LDAP Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Ambarish Malpani" writes: >I have still to see a place where using CRLs as the mechanism for letting a >VA know of changes in the revocation data has led to poorer performance than >having the VA access the CA's database directly. Most of the CAs I know of issues CRLs a few times a day, some as infrequently as once a day. If I'm doing processing with any kind of value attached to the transaction, I want to know whether the cert is valid right now, not whether it was OK last night when the CRL was issued (substitute "credit card" for "cert" to see why this is important). I have never seen a situation where an offline CRL gives better performance than a real-time check of a live database, unless you happen to catch it just as the CRL is being issued, which (for a 24-hour CRL time) only works about once in 86,400 times. I think one of the reasons why there aren't more complaints about CRLs is because so many apps only pay lip service to revocation checking, so it doesn't really matter if it doesn't work proprely ("We go through the motions because the CA policy requires it"/"It's turned off by default, but we can claim it's there"/"We realise the CRL is almost always out of date, but our accounting processes should catch any problems"/etc are all excuses I've heard). If you build a system where you can tell users that there's a simple online check which guarantees that at the time the check was done the cert was valid (rather than being valid a couple of hours ago) following the credit card model that businesses are used to, perhaps people would lend more weight to the value of checking. Actually, as mentioned in my previous message, implementors are already doing this, and have been doing it for some time, because people care about real-time cert status information, it's just not standardised in any spec (yet :-) so you get a pile of proprietary ways of doing it. Peter. From owner-ietf-pkix Sun Jan 5 01:04:35 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0594Zi15036 for ietf-pkix-bks; Sun, 5 Jan 2003 01:04:35 -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 h0594Xo15030 for ; Sun, 5 Jan 2003 01:04:33 -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 h0594PbT014026; Sun, 5 Jan 2003 22:04:25 +1300 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0594Pq00841; Sun, 5 Jan 2003 22:04:25 +1300 Date: Sun, 5 Jan 2003 22:04:25 +1300 Message-Id: <200301050904.h0594Pq00841@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ambarish@malpani.biz, ietf-pkix@imc.org, madwolf@hackmasters.net Subject: RE: OCSP and LDAP Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I wrote: >I think one of the reasons why there aren't more complaints about CRLs is >because so many apps only pay lip service to revocation checking, so it >doesn't really matter if it doesn't work proprely ("We go through the motions >because the CA policy requires it"/"It's turned off by default, but we can accounting processes should catch any problems"/etc are all excuses I've >heard). Before someone leaps in here with the obvious "Well, DoD PKI users (or something similar) do check CRLs, so they must be OK", what I was referring to was the civilian masses who are expected to adopt PKI at some point. Government users are a special case in that they have infinite resources to throw at a project, can be ordered to use CRLs (or to charge a machine-gun), and various other things that don't apply to the masses. I realise that you can always dig up some user somewhere to illustrate some point ("DoD users use X.400 email, so it must be OK"), but that's not a good example of what the masses are doing. I'm not going to be able to sell X.400 to commercial users on this basis, and a semi-functional validity checking mechanism supplying out-of-date information is also rather a hard sell. When I hear users who do actually care about checking certs (for example ones using them for medical EDI) say things like "We rely for the most part on the hospitals to control access, and in any case it's no worse than the existing paper-based system", I have to worry about how long they'll continue listening to PKI advocates telling them how wonderful it's all going to be... Peter. From owner-ietf-pkix Sun Jan 5 00:58:28 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h058wSS14208 for ietf-pkix-bks; Sun, 5 Jan 2003 00:58:28 -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 h058wQo14200 for ; Sun, 5 Jan 2003 00:58:26 -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 h058wAbT013977; Sun, 5 Jan 2003 21:58:10 +1300 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h058w7c00730; Sun, 5 Jan 2003 21:58:07 +1300 Date: Sun, 5 Jan 2003 21:58:07 +1300 Message-Id: <200301050858.h058w7c00730@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ambarish@malpani.biz, ietf-pkix@imc.org, madwolf@hackmasters.net Subject: RE: OCSP and LDAP Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I wrote: >I think one of the reasons why there aren't more complaints about CRLs is >because so many apps only pay lip service to revocation checking, so it >doesn't really matter if it doesn't work proprely ("We go through the motions >because the CA policy requires it"/"It's turned off by default, but we can accounting processes should catch any problems"/etc are all excuses I've >heard). Before someone leaps in here with the obvious "Well, DoD PKI users (or something similar) do check CRLs, so they must be OK", what I was referring to was the civilian masses who are expected to adopt PKI at some point. Government users are a special case in that they have infinite resources to throw at a project, can be ordered to use CRLs (or to charge a machine-gun), and various other things that don't apply to the masses. I realise that you can always dig up some user somewhere to illustrate some point ("DoD users use X.400 email, so it must be OK"), but that's not a good example of what the masses are doing. I'm not going to be able to sell X.400 to commercial users on this basis, and a semi-functional validity checking mechanism supplying out-of-date information is also rather a hard sell to people. When I hear users who do actually care about checking certs (for example ones using them for medical EDI) say things like "We rely for the most part on the hospitals to control access, and in any case it's no worse than the existing paper-based system", I can see why PKI is a hard-sell. Peter. From owner-ietf-pkix Sun Jan 5 01:46:23 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h059kNd19089 for ietf-pkix-bks; Sun, 5 Jan 2003 01:46:23 -0800 (PST) Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h059kJo19081 for ; Sun, 5 Jan 2003 01:46:20 -0800 (PST) Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by maila.telia.com (8.12.5/8.12.5) with SMTP id h059kC3Y014331; Sun, 5 Jan 2003 10:46:13 +0100 (CET) X-Original-Recipient: ietf-pkix@imc.org Message-ID: <003c01c2b49f$04c2f300$0500a8c0@arport> From: "Anders Rundgren" To: "Peter Gutmann" , , , References: <200301050820.h058KHj00419@medusa01.cs.auckland.ac.nz> Subject: Re: OCSP and LDAP Date: Sun, 5 Jan 2003 10:44:18 +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: I agree with Peter. I don't think OCSP in a not so distant future have to be more technically costly than accessing a web-page. Including a signed answer. Some banks in Sweden believe 20 cents/lookup is a reasonable fee as it is "comparable to putting a stamp on a letter". Personally I don't think the VA-business model has much future as it complicates they way parties interact. It essentially requires two or three global VA-networks in the world to function and that seems very unlikely to happen. It feels like the VA business model is crafted according to the lines of credit-card authorizations, but that is a rather different type of business IMHO. Pardon the slightly orthogonal input, but business & technology do have rather interesting connections... Anders ----- Original Message ----- From: "Peter Gutmann" To: ; ; ; Sent: Sunday, January 05, 2003 09:20 Subject: RE: OCSP and LDAP "Ambarish Malpani" writes: >I have still to see a place where using CRLs as the mechanism for letting a >VA know of changes in the revocation data has led to poorer performance than >having the VA access the CA's database directly. Most of the CAs I know of issues CRLs a few times a day, some as infrequently as once a day. If I'm doing processing with any kind of value attached to the transaction, I want to know whether the cert is valid right now, not whether it was OK last night when the CRL was issued (substitute "credit card" for "cert" to see why this is important). I have never seen a situation where an offline CRL gives better performance than a real-time check of a live database, unless you happen to catch it just as the CRL is being issued, which (for a 24-hour CRL time) only works about once in 86,400 times. I think one of the reasons why there aren't more complaints about CRLs is because so many apps only pay lip service to revocation checking, so it doesn't really matter if it doesn't work proprely ("We go through the motions because the CA policy requires it"/"It's turned off by default, but we can claim it's there"/"We realise the CRL is almost always out of date, but our accounting processes should catch any problems"/etc are all excuses I've heard). If you build a system where you can tell users that there's a simple online check which guarantees that at the time the check was done the cert was valid (rather than being valid a couple of hours ago) following the credit card model that businesses are used to, perhaps people would lend more weight to the value of checking. Actually, as mentioned in my previous message, implementors are already doing this, and have been doing it for some time, because people care about real-time cert status information, it's just not standardised in any spec (yet :-) so you get a pile of proprietary ways of doing it. Peter. From owner-ietf-pkix Sun Jan 5 02:25:42 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05APgp25849 for ietf-pkix-bks; Sun, 5 Jan 2003 02:25:42 -0800 (PST) Received: from mail.hackmasters.net (ppp-217-133-8-148.dialup.tiscali.it [217.133.8.148]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h05APdo25841 for ; Sun, 5 Jan 2003 02:25:39 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hackmasters.net (Postfix) with ESMTP id 2FF3AF356 for ; Sun, 5 Jan 2003 11:24:32 +0100 (CET) Received: by mail.hackmasters.net (Postfix, from userid 509) id 4819CF35C; Sun, 5 Jan 2003 11:24:25 +0100 (CET) Received: from hackmasters.net (galadriel.mpnet.hackmasters.net [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id 110D9F356 for ; Sun, 5 Jan 2003 11:24:23 +0100 (CET) Message-ID: <3E18085A.6010209@hackmasters.net> Date: Sun, 05 Jan 2003 11:26:34 +0100 From: Massimiliano Pala Organization: OpenCA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: OCSP and LDAP References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070109030600000701050208" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070109030600000701050208 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, I am quoting one answer for all as it seems them all share the same vision. Ambarish Malpani wrote: > Hi Massimiliano, > You should seriously consider having your responder work off a > CA's CRL, rather than trying to access its database directly. Well, our approach is towards the usage of an off-line CA so my problem is that usually the CRL could be not up to date to the latest status of the certificate (let's say a user request its certificate to be revoked, from this time to the time the CRL will be issued there could be a time gap during which I want the certificate to be reported as invalid -- let's say with the onHold reason). For this reason I need some more information rather than the only CRL. There is another question about this approach: if the client request the status of one certificate with a serial that is not within the CRL, should not the responder check for it (i.e. its existance?) and if it does not have informations about it return an "unknown" answer ? > There are a set of reasons why this is a good idea. Here are are > few (in no particular order): > > - CA independence (might not be important for you) This is one of the most important reason that drives my questions. > - Helps auditability of the VA > - Allows better control over replication (where you don't need > to rely on LDAP replication - most CAs won't want to > replicate the rest of their LDAP data) > - Better performance - can keep the revocation data in memory and > respond from memory - won't need to also have a LDAP lookup I know, indeed we actually use a single file generated from the certificates' db that is read by the responder and kept in memory, but as the number of certificates grows and in case of a spawning process approach used memory grows and performance drop. IMHO I guess I need the latest CRL and the latest CSL (list of "suspended" certificates -- i.e. certificates that for any reason "could" be revoked but them are not, yet). From your answers I guess there is no reference on how to store this information onto LDAP. Do you think the best method could be storing a single pkcs7 file with all the information into the main ca entry onto LDAP (and when the CA updates the information, the OCSP will update its internal data) or it is best having a field in the user's entry ? Thanks to all of you for your answers. -- C'you, Massimiliano Pala --o------------------------------------------------------------------------- Massimiliano Pala [OpenCA Project Manager] madwolf@openca.org Tel.: +39 (0)59 270 094 http://www.openca.org Fax: +39 178 221 8225 http://openca.sourceforge.net Mobile: +39 (0)347 7222 365 --------------ms070109030600000701050208 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOZjCC By8wggYXoAMCAQICASwwDQYJKoZIhvcNAQEEBQAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5j aWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9u ZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkG A1UEBhMCSVQwHhcNMDIwNzI0MTUyNjI2WhcNMDMxMjMxMjM1OTU5WjCBqTEaMBgGA1UEAxMR TWFzc2ltaWxpYW5vIFBhbGExNTAzBgNVBAsTLERpcGFydGltZW50byBkaSBJbmdlZ25lcmlh IGRlbGwnSW5mb3JtYXppb25lMRcwFQYDVQQLEw5TZWRlIGRpIE1vZGVuYTEuMCwGA1UEChMl VW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQwgZ8w DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANSesg80BGzryvQlplD0MJ2YWlSEUAZpiFmywpOm l//lWMnhONmC/q0TrO7j9Bb195dNzCMuXFgvV49Sy1iyHAjDhpysFvm/xZbAS3j8prXNN23K S3Oa7Zz2GrQpCHgupCPQL2cy+ARVwwFod2GOSCVoUACkndit964K/bfsGvyLAgMBAAGjggQB MIID/TAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCA/gw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6aSO5yTMPTf9OdcWo 14pKLqEHMDCBtwYDVR0jBIGvMIGsgBRFHaYA4ZfoyU2aaUnZYMiYf4lFA6GBkKSBjTCBijEi MCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMeVW5pbW9yZSBF bnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBkaSBNb2RlbmEg ZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVIIBADBqBglghkgBhvhCAQ0EXRZbUHJvZ2V0 dG8gUG9zdGEgRWxldHRyb25pY2EgU2ljdXJhIA0KVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUg UmVnZ2lvIEVtaWxpYSANCkMuSS5DLkEuSS5BLiANCjAiBgNVHREEGzAZgRdtYWR3b2xmQGhh Y2ttYXN0ZXJzLm5ldDA0BgNVHRIELTArgRNwa2kuY2ljYWlhQHVuaW1vLml0hhRodHRwOi8v cGtpLnVuaW1vLml0LzA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAKGI2h0dHA6Ly9wa2ku dW5pbW8uaXQvY2EvaXNzdWVycy5odG1sMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9wa2ku dW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQQEIxYhaHR0cDovL3BraS51bmlt by5pdC9jcmwvY2FjcmwuY3JsMDAGCWCGSAGG+EIBAwQjFiFodHRwOi8vcGtpLnVuaW1vLml0 L2NybC9jYWNybC5jcmwwKgYJYIZIAYb4QgEHBB0WG2h0dHA6Ly9wa2kudW5pbW8uaXQvcmVu ZXdhbDArBglghkgBhvhCAQgEHhYcaHR0cDovL3BraS51bmltby5pdC9jcHMvMS4xLzCB2QYD VR0gBIHRMIHOMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJv cGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMEEGCisGAQQBqQcCAQEwMzAxBggrBgEFBQcCARYl aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBEBgorBgEEAegTAQEBMDYw NAYIKwYBBQUHAgEWKGh0dHA6Ly9tYWlsLnVuaW1vLml0L2Zpcm1hL2Nwc21vZGVuYS5odG0w DQYJKoZIhvcNAQEEBQADggEBABn8ViNg4MPNRzEFFF4BsmRMP1YbUHbS+NmFvvys0D3xueex Ie6HU+tkv9hz8++0MbLPnRY2qKpZXfWTbIOkrHLGVVHUkiZXFzfxsDMgcB4MWmSmhRVLfPqr RZKAjIevO0JKIksq2xutAUqX5jkqZoGHpPv9JCiSI+cDRqOOW2Fh3JBGkcULKybrdwrSN6+S NoTyTXR+ryeTBUXxu9rIbjrJdH3rKS7rz3ZkP2PKuFOb+Vbp829ALph1SJOLQrUnmJouLOSL oVHW4zJK4zcAiNyMHua3HveLRkVINT9eDBeYBRPdn1k+LqdXqkXiEUPA+EIKeA23F5nQkqxI mVVpaaYwggcvMIIGF6ADAgECAgEsMA0GCSqGSIb3DQEBBAUAMIGKMSIwIAYJKoZIhvcNAQkB FhNwa2kuY2ljYWlhQHVuaW1vLml0MScwJQYDVQQDEx5Vbmltb3JlIEVudGUgZGkgQ2VydGlm aWNhemlvbmUxLjAsBgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWls aWExCzAJBgNVBAYTAklUMB4XDTAyMDcyNDE1MjYyNloXDTAzMTIzMTIzNTk1OVowgakxGjAY BgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMTUwMwYDVQQLEyxEaXBhcnRpbWVudG8gZGkgSW5n ZWduZXJpYSBkZWxsJ0luZm9ybWF6aW9uZTEXMBUGA1UECxMOU2VkZSBkaSBNb2RlbmExLjAs BgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWlsaWExCzAJBgNVBAYT AklUMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUnrIPNARs68r0JaZQ9DCdmFpUhFAG aYhZssKTppf/5VjJ4TjZgv6tE6zu4/QW9feXTcwjLlxYL1ePUstYshwIw4acrBb5v8WWwEt4 /Ka1zTdtyktzmu2c9hq0KQh4LqQj0C9nMvgEVcMBaHdhjkglaFAApJ3YrfeuCv237Br8iwID AQABo4IEATCCA/0wDAYDVR0TAQH/BAIwADARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/ BAQDAgP4MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+mkjuckz D03/TnXFqNeKSi6hBzAwgbcGA1UdIwSBrzCBrIAURR2mAOGX6MlNmmlJ2WDImH+JRQOhgZCk gY0wgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVu aW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkg TW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVSCAQAwagYJYIZIAYb4QgENBF0W W1Byb2dldHRvIFBvc3RhIEVsZXR0cm9uaWNhIFNpY3VyYSANClVuaXZlcnNpdGEnIGRpIE1v ZGVuYSBlIFJlZ2dpbyBFbWlsaWEgDQpDLkkuQy5BLkkuQS4gDQowIgYDVR0RBBswGYEXbWFk d29sZkBoYWNrbWFzdGVycy5uZXQwNAYDVR0SBC0wK4ETcGtpLmNpY2FpYUB1bmltby5pdIYU aHR0cDovL3BraS51bmltby5pdC8wPwYIKwYBBQUHAQEEMzAxMC8GCCsGAQUFBzAChiNodHRw Oi8vcGtpLnVuaW1vLml0L2NhL2lzc3VlcnMuaHRtbDAyBgNVHR8EKzApMCegJaAjhiFodHRw Oi8vcGtpLnVuaW1vLml0L2NybC9jYWNybC5jcmwwMAYJYIZIAYb4QgEEBCMWIWh0dHA6Ly9w a2kudW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQMEIxYhaHR0cDovL3BraS51 bmltby5pdC9jcmwvY2FjcmwuY3JsMCoGCWCGSAGG+EIBBwQdFhtodHRwOi8vcGtpLnVuaW1v Lml0L3JlbmV3YWwwKwYJYIZIAYb4QgEIBB4WHGh0dHA6Ly9wa2kudW5pbW8uaXQvY3BzLzEu MS8wgdkGA1UdIASB0TCBzjBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93 d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYB BQUHAgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRAYKKwYBBAHo EwEBATA2MDQGCCsGAQUFBwIBFihodHRwOi8vbWFpbC51bmltby5pdC9maXJtYS9jcHNtb2Rl bmEuaHRtMA0GCSqGSIb3DQEBBAUAA4IBAQAZ/FYjYODDzUcxBRReAbJkTD9WG1B20vjZhb78 rNA98bnnsSHuh1PrZL/Yc/PvtDGyz50WNqiqWV31k2yDpKxyxlVR1JImVxc38bAzIHAeDFpk poUVS3z6q0WSgIyHrztCSiJLKtsbrQFKl+Y5KmaBh6T7/SQokiPnA0ajjlthYdyQRpHFCysm 63cK0jevkjaE8k10fq8nkwVF8bvayG46yXR96yku6892ZD9jyrhTm/lW6fNvQC6YdUiTi0K1 J5iaLizki6FR1uMySuM3AIjcjB7mtx73i0ZFSDU/XgwXmAUT3Z9ZPi6nV6pF4hFDwPhCCngN txeZ0JKsSJlVaWmmMYIDNjCCAzICAQEwgZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNh aWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEu MCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UE BhMCSVQCASwwCQYFKw4DAhoFAKCCAfswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDMwMTA1MTAyNjM0WjAjBgkqhkiG9w0BCQQxFgQUgWIROJlgSgOwC4pM u/KuTcDHE70wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaEGCSsGAQQBgjcQBDGB kzCBkDCBijEiMCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMe VW5pbW9yZSBFbnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBk aSBNb2RlbmEgZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVAIBLDCBowYLKoZIhvcNAQkQ AgsxgZOggZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNV BAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0 YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQCASwwDQYJKoZIhvcN AQEBBQAEgYBLXrS93IFJAtuOfwRU6UvoxdGxtTldSWaxTYMNtAecQFMIiNfjs86vfoE1RkOp B5EyrnOAGGIDTmPRax4f0egHlJ0/7NheF0RWk47xVFpoX5+PPH1KVtgYYBgy5gXghr1gCuIP S+VWViOXSmYrOGvPL64r21ZFsGYreCzS1dhgXgAAAAAAAA== --------------ms070109030600000701050208-- From owner-ietf-pkix Sun Jan 5 06:50:51 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05Eopm25886 for ietf-pkix-bks; Sun, 5 Jan 2003 06:50:51 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h05Eono25874 for ; Sun, 5 Jan 2003 06:50:49 -0800 (PST) Subject: Re: OCSP and LDAP To: "Anders Rundgren" Cc: ambarish@malpani.biz, ietf-pkix@imc.org, madwolf@hackmasters.net, owner-ietf-pkix@mail.imc.org, "Peter Gutmann" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Sun, 5 Jan 2003 07:52:32 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/05/2003 09:52:45 AM 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: but as been discussed in other venues ... it is not only the cost ... but also who pays (how does the money flow). does a consumer pay for checking a merchant's certificate as part of access the merchant's website .... which might otherwise be free access? A merchant (as the relying party) might pay when checking the status of a consumer's certificate .... but does a consumer (as the relying party) pay when checking the status of a merchant's certificate.. Also ... as in other merchant/consumer e-commerce discussions .... a merchant's interest in the status (real-time or not) of a consumer's certificate is only incidental to whether the bank says that the merchant gets paid. now the other business flow as a certificate, offline, stale paradigm is pushed towards an online, real-time model .... there is a question of what point does the paradigm switch. In the original offline credit-card paradigm .... the transition to online, real-time .... bypassed the real-time checking on whether the offline, stale credential was still good ... and/or whether the stale assertions in the offline credential was still good .... but whether the real-time assertions were valid. The model in the certificate ... is that there are some assertions that are inserted into a stale, static certificate at some time in the past .... and for OCSP ... you do real-time checks to see if the stale, static past assertions still hold. The model that credit-cards went to .... was doing real-time checks on real-time assertions ... not real-time checks on real-time stale, static assertions. The distinction is that the payment card paradigm in moving to online ... bypassed the intermediate paradigm of real-time checks on past, stale, historic, static assertions (contined in the certificate) .... and went directly to real-time checks on current, real-time assertions, aka the credit-card industry in transitioning to online .... could have continued to preserve the offline paradigm with real time checks (like OCSP does for certificates) .... which is equivalent to a real-time check to see if the consumer still has a valid account. However, the payment card industry in transitioning to online discovered that they could significantly leverage the utility of having real-time, online checking .... that instead of having real-time, online checking of stale, static information .... significantly increase the utility of having real-time checking of real-time information. So the credit-card industry skipped the OCSP-analogous step of having a real-time infrastructure for checking of stale, static data (aka does an account still exist), and significantly improved the utility of having an online, real-time infrastructure ... and performing real-time checking of what the merchant is really interested in .... will they get paid. An issue is whether the value of having a real-time online infrastructure is significantly depreciated if it is just being applied to checking status of static, stale information .... when for effectively the same infrastructure costs .... it can be used for real-time, online checking of real-time dynamic information (under the assumption that real-time checking of real-time dynamic information tends to have more value than real-time checking of static, stale information). ... i believe that the charge/chost at supermarket check-out for debit card transaction doing real-time checking for sufficient funds for the transaction (rather than just checking if the account still exists) as well as scheduling the transaction .... the charge/cost for both/combined ... is on the order of your projected lookup costs. If the online, real-time validation of real-time dynamic assertion (rather the real-time validation of static, stale assertion) can be bundled with the actual execution of real transaction .... and be bundled for essentially the same cost of doing just online, real-time lookup of static, stale data .... then it would imply that static, stale data paradigm would be somewhat redundant and superfulous in an online, real-time environment. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm anders.rundgren@telia.com on 1/5/2002 2:44 am wrote: I agree with Peter. I don't think OCSP in a not so distant future have to be more technically costly than accessing a web-page. Including a signed answer. Some banks in Sweden believe 20 cents/lookup is a reasonable fee as it is "comparable to putting a stamp on a letter". Personally I don't think the VA-business model has much future as it complicates they way parties interact. It essentially requires two or three global VA-networks in the world to function and that seems very unlikely to happen. It feels like the VA business model is crafted according to the lines of credit-card authorizations, but that is a rather different type of business IMHO. Pardon the slightly orthogonal input, but business & technology do have rather interesting connections... Anders From owner-ietf-pkix Sun Jan 5 08:28:50 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05GSog03815 for ietf-pkix-bks; Sun, 5 Jan 2003 08:28:50 -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 h05GSno03811 for ; Sun, 5 Jan 2003 08:28:49 -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 h05GSWZp005467; Sun, 5 Jan 2003 08:28:32 -0800 From: "Ambarish Malpani" To: "Peter Gutmann" , , Subject: RE: OCSP and LDAP Date: Sun, 5 Jan 2003 08:28:46 -0800 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) In-Reply-To: <200301050820.h058KHj00419@medusa01.cs.auckland.ac.nz> 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 Peter, One of the things that I didn't mention in my original mail, but that I think I had said on this list before, is that we do allow our VA to use its own data to indicate that a certificate is revoked/suspended if the VA knows that a certificate has been revoked/suspended, but the CA has not had a chance to indicate that. 3 other issues: a. When people try to keep their CAs offline, they not only want keep the CAs signing key offline, but also its database. Having the responder access the CAs database means that some of the CAs data now needs to be online. b. If you want to locate VAs at multiple remote locations and you have the VA access the CAs database, it needs to access that database from remote locations. c. Most CA operators are prefectly happy to combine the capablity above (of temporary suspension at the VA) and the fact that a VA can accept a CRL issued at any time, to deal with the issue of needing to revoke/suspend a cert while a CA is offline. Hope this helps, 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 Peter Gutmann > Sent: Sunday, January 05, 2003 12:20 AM > To: ambarish@malpani.biz; ietf-pkix@imc.org; madwolf@hackmasters.net; > pgut001@cs.auckland.ac.nz > Subject: RE: OCSP and LDAP > > > > "Ambarish Malpani" writes: > > >I have still to see a place where using CRLs as the mechanism > for letting a > >VA know of changes in the revocation data has led to poorer > performance than > >having the VA access the CA's database directly. > > Most of the CAs I know of issues CRLs a few times a day, some as > infrequently > as once a day. If I'm doing processing with any kind of value > attached to the > transaction, I want to know whether the cert is valid right now, > not whether > it was OK last night when the CRL was issued (substitute "credit card" for > "cert" to see why this is important). I have never seen a > situation where an > offline CRL gives better performance than a real-time check of a live > database, unless you happen to catch it just as the CRL is being > issued, which > (for a 24-hour CRL time) only works about once in 86,400 times. > > I think one of the reasons why there aren't more complaints about CRLs is > because so many apps only pay lip service to revocation checking, so it > doesn't really matter if it doesn't work proprely ("We go through > the motions > because the CA policy requires it"/"It's turned off by default, but we can > claim it's there"/"We realise the CRL is almost always out of > date, but our > accounting processes should catch any problems"/etc are all excuses I've > heard). If you build a system where you can tell users that > there's a simple > online check which guarantees that at the time the check was done > the cert was > valid (rather than being valid a couple of hours ago) following the credit > card model that businesses are used to, perhaps people would lend > more weight > to the value of checking. Actually, as mentioned in my previous message, > implementors are already doing this, and have been doing it for some time, > because people care about real-time cert status information, it's just not > standardised in any spec (yet :-) so you get a pile of proprietary ways of > doing it. > > Peter. > From owner-ietf-pkix Sun Jan 5 08:31:04 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05GV4V04047 for ietf-pkix-bks; Sun, 5 Jan 2003 08:31:04 -0800 (PST) Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h05GUxo04023; Sun, 5 Jan 2003 08:31:00 -0800 (PST) Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by mailf.telia.com (8.12.5/8.12.5) with SMTP id h05GUcTk009808; Sun, 5 Jan 2003 17:30:38 +0100 (CET) X-Original-Recipient: owner-ietf-pkix@mail.imc.org Message-ID: <001401c2b4d7$846e1390$0500a8c0@arport> From: "Anders Rundgren" To: Cc: , , , , "Peter Gutmann" References: Subject: Re: OCSP and LDAP Date: Sun, 5 Jan 2003 17:28:43 +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: Ok Lynn, I believe we have heard this one a couple times before or so :-) But, there *is* (believe it or not) a world *outside* of payment- transactions. Like e-governments having citizens typically using TTP-issued certificates _authenticating_ to various services. In case you want to respond to this, make a _SHORT_ note why OCSP would _NOT_ fit (=be redundant in) the scenario above. Now I must go back to my rost, it is time to party :-) Anders ----- Original Message ----- From: To: "Anders Rundgren" Cc: ; ; ; ; "Peter Gutmann" Sent: Sunday, January 05, 2003 15:52 Subject: Re: OCSP and LDAP but as been discussed in other venues ... it is not only the cost ... but also who pays (how does the money flow). does a consumer pay for checking a merchant's certificate as part of access the merchant's website .... which might otherwise be free access? A merchant (as the relying party) might pay when checking the status of a consumer's certificate .... but does a consumer (as the relying party) pay when checking the status of a merchant's certificate.. Also ... as in other merchant/consumer e-commerce discussions .... a merchant's interest in the status (real-time or not) of a consumer's certificate is only incidental to whether the bank says that the merchant gets paid. now the other business flow as a certificate, offline, stale paradigm is pushed towards an online, real-time model .... there is a question of what point does the paradigm switch. In the original offline credit-card paradigm .... the transition to online, real-time .... bypassed the real-time checking on whether the offline, stale credential was still good ... and/or whether the stale assertions in the offline credential was still good .... but whether the real-time assertions were valid. The model in the certificate ... is that there are some assertions that are inserted into a stale, static certificate at some time in the past .... and for OCSP ... you do real-time checks to see if the stale, static past assertions still hold. The model that credit-cards went to .... was doing real-time checks on real-time assertions ... not real-time checks on real-time stale, static assertions. The distinction is that the payment card paradigm in moving to online ... bypassed the intermediate paradigm of real-time checks on past, stale, historic, static assertions (contined in the certificate) .... and went directly to real-time checks on current, real-time assertions, aka the credit-card industry in transitioning to online .... could have continued to preserve the offline paradigm with real time checks (like OCSP does for certificates) .... which is equivalent to a real-time check to see if the consumer still has a valid account. However, the payment card industry in transitioning to online discovered that they could significantly leverage the utility of having real-time, online checking .... that instead of having real-time, online checking of stale, static information .... significantly increase the utility of having real-time checking of real-time information. So the credit-card industry skipped the OCSP-analogous step of having a real-time infrastructure for checking of stale, static data (aka does an account still exist), and significantly improved the utility of having an online, real-time infrastructure ... and performing real-time checking of what the merchant is really interested in .... will they get paid. An issue is whether the value of having a real-time online infrastructure is significantly depreciated if it is just being applied to checking status of static, stale information .... when for effectively the same infrastructure costs .... it can be used for real-time, online checking of real-time dynamic information (under the assumption that real-time checking of real-time dynamic information tends to have more value than real-time checking of static, stale information). ... i believe that the charge/chost at supermarket check-out for debit card transaction doing real-time checking for sufficient funds for the transaction (rather than just checking if the account still exists) as well as scheduling the transaction .... the charge/cost for both/combined ... is on the order of your projected lookup costs. If the online, real-time validation of real-time dynamic assertion (rather the real-time validation of static, stale assertion) can be bundled with the actual execution of real transaction .... and be bundled for essentially the same cost of doing just online, real-time lookup of static, stale data .... then it would imply that static, stale data paradigm would be somewhat redundant and superfulous in an online, real-time environment. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm anders.rundgren@telia.com on 1/5/2002 2:44 am wrote: I agree with Peter. I don't think OCSP in a not so distant future have to be more technically costly than accessing a web-page. Including a signed answer. Some banks in Sweden believe 20 cents/lookup is a reasonable fee as it is "comparable to putting a stamp on a letter". Personally I don't think the VA-business model has much future as it complicates they way parties interact. It essentially requires two or three global VA-networks in the world to function and that seems very unlikely to happen. It feels like the VA business model is crafted according to the lines of credit-card authorizations, but that is a rather different type of business IMHO. Pardon the slightly orthogonal input, but business & technology do have rather interesting connections... Anders From owner-ietf-pkix Sun Jan 5 09:53:30 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05HrUl09365 for ietf-pkix-bks; Sun, 5 Jan 2003 09:53:30 -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 h05HrTo09361 for ; Sun, 5 Jan 2003 09:53:29 -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 h05HrDZp005498; Sun, 5 Jan 2003 09:53:14 -0800 From: "Ambarish Malpani" To: "Peter Gutmann" , , Subject: RE: OCSP and LDAP Date: Sun, 5 Jan 2003 09:53:27 -0800 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) In-Reply-To: <200301050820.h058KHj00419@medusa01.cs.auckland.ac.nz> 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 Peter, I agree completely with the statements that people don't really use CRLs and that getting up to date information to all clients via CRLs is hard. I, too, wish people would just use OCSP and move on with things. That was the whole idea behind doing Valicert. As I explained before - using CRLs as a mechanism for getting snapshots from the CA, ability to accept emergency CRLs and the ability to revoke/suspend at the VA give people all the benefits of OCSP without needing to change their CA or have their VA tied into the CA/need access to the CAs database. 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 Peter Gutmann > Sent: Sunday, January 05, 2003 12:20 AM > To: ambarish@malpani.biz; ietf-pkix@imc.org; madwolf@hackmasters.net; > pgut001@cs.auckland.ac.nz > Subject: RE: OCSP and LDAP > > > > "Ambarish Malpani" writes: > > >I have still to see a place where using CRLs as the mechanism > for letting a > >VA know of changes in the revocation data has led to poorer > performance than > >having the VA access the CA's database directly. > > Most of the CAs I know of issues CRLs a few times a day, some as > infrequently > as once a day. If I'm doing processing with any kind of value > attached to the > transaction, I want to know whether the cert is valid right now, > not whether > it was OK last night when the CRL was issued (substitute "credit card" for > "cert" to see why this is important). I have never seen a > situation where an > offline CRL gives better performance than a real-time check of a live > database, unless you happen to catch it just as the CRL is being > issued, which > (for a 24-hour CRL time) only works about once in 86,400 times. > > I think one of the reasons why there aren't more complaints about CRLs is > because so many apps only pay lip service to revocation checking, so it > doesn't really matter if it doesn't work proprely ("We go through > the motions > because the CA policy requires it"/"It's turned off by default, but we can > claim it's there"/"We realise the CRL is almost always out of > date, but our > accounting processes should catch any problems"/etc are all excuses I've > heard). If you build a system where you can tell users that > there's a simple > online check which guarantees that at the time the check was done > the cert was > valid (rather than being valid a couple of hours ago) following the credit > card model that businesses are used to, perhaps people would lend > more weight > to the value of checking. Actually, as mentioned in my previous message, > implementors are already doing this, and have been doing it for some time, > because people care about real-time cert status information, it's just not > standardised in any spec (yet :-) so you get a pile of proprietary ways of > doing it. > > Peter. > From owner-ietf-pkix Sun Jan 5 11:15:47 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05JFlc17287 for ietf-pkix-bks; Sun, 5 Jan 2003 11:15:47 -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 h05JFjo17278 for ; Sun, 5 Jan 2003 11:15:45 -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 h05JFZZp005527; Sun, 5 Jan 2003 11:15:35 -0800 From: "Ambarish Malpani" To: , "IETF PKIX" Subject: RE: OCSP and LDAP Date: Sun, 5 Jan 2003 11:15: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: 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 Lynn, Not sure why you associate OCSP with stale information. The responder can have as current information as you choose to provide it. Once again, I believe it makes sense to have the interaction between the CA and the VA be CRLs. If there is more current information you have (than is present in the CRL), it makes sense to have that information at the VA for use until a new CRL is produced. Ambarish P.S. We have also had people use their OCSP responder to provide more than just certificate revocation information (eg. payment authorization) using extensions to OCSP. --------------------------------------------------------------------- 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 > lynn.wheeler@firstdata.com > Sent: Sunday, January 05, 2003 6:53 AM > To: Anders Rundgren > Cc: ambarish@malpani.biz; ietf-pkix@imc.org; madwolf@hackmasters.net; > owner-ietf-pkix@mail.imc.org; Peter Gutmann > Subject: Re: OCSP and LDAP > > > > > but as been discussed in other venues ... it is not only the cost ... but > also who pays (how does the money flow). does a consumer pay for > checking a > merchant's certificate as part of access the merchant's website .... which > might otherwise be free access? A merchant (as the relying party) > might pay > when checking the status of a consumer's certificate .... but does a > consumer (as the relying party) pay when checking the status of a > merchant's certificate.. Also ... as in other merchant/consumer > e-commerce > discussions .... a merchant's interest in the status (real-time or not) of > a consumer's certificate is only incidental to whether the bank says that > the merchant gets paid. > > now the other business flow as a certificate, offline, stale paradigm is > pushed towards an online, real-time model .... there is a question of what > point does the paradigm switch. In the original offline credit-card > paradigm .... the transition to online, real-time .... bypassed the > real-time checking on whether the offline, stale credential was still good > ... and/or whether the stale assertions in the offline credential > was still > good .... but whether the real-time assertions were valid. > > The model in the certificate ... is that there are some > assertions that are > inserted into a stale, static certificate at some time in the > past .... and > for OCSP ... you do real-time checks to see if the stale, static past > assertions still hold. The model that credit-cards went to .... was doing > real-time checks on real-time assertions ... not real-time checks on > real-time stale, static assertions. > > The distinction is that the payment card paradigm in moving to online ... > bypassed the intermediate paradigm of real-time checks on past, stale, > historic, static assertions (contined in the certificate) .... and went > directly to real-time checks on current, real-time assertions, aka the > credit-card industry in transitioning to online .... could have continued > to preserve the offline paradigm with real time checks (like OCSP does for > certificates) .... which is equivalent to a real-time check to see if the > consumer still has a valid account. However, the payment card industry in > transitioning to online discovered that they could significantly leverage > the utility of having real-time, online checking .... that instead of > having real-time, online checking of stale, static information .... > significantly increase the utility of having real-time checking of > real-time information. > > So the credit-card industry skipped the OCSP-analogous step of having a > real-time infrastructure for checking of stale, static data (aka does an > account still exist), and significantly improved the utility of having an > online, real-time infrastructure ... and performing real-time checking of > what the merchant is really interested in .... will they get > paid. An issue > is whether the value of having a real-time online infrastructure is > significantly depreciated if it is just being applied to checking > status of > static, stale information .... when for effectively the same > infrastructure > costs .... it can be used for real-time, online checking of real-time > dynamic information (under the assumption that real-time checking of > real-time dynamic information tends to have more value than real-time > checking of static, stale information). > > ... i believe that the charge/chost at supermarket check-out for > debit card > transaction doing real-time checking for sufficient funds for the > transaction (rather than just checking if the account still exists) > as well as scheduling the transaction .... the charge/cost for > both/combined ... is on the order of your projected lookup costs. > > If the online, real-time validation of real-time dynamic assertion (rather > the real-time validation of static, stale assertion) can be bundled with > the actual execution of real transaction .... and be bundled for > essentially the same cost of doing just online, real-time lookup > of static, > stale data .... then it would imply that static, stale data paradigm would > be somewhat redundant and superfulous in an online, real-time environment. > > -- > Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm > > > anders.rundgren@telia.com on 1/5/2002 2:44 am wrote: > > I agree with Peter. > > I don't think OCSP in a not so distant future have to be more technically > costly than accessing a web-page. Including a signed answer. > > Some banks in Sweden believe 20 cents/lookup is a reasonable fee as it is > "comparable to putting a stamp on a letter". > > Personally I don't think the VA-business model has much future as it > complicates they way parties interact. It essentially requires two or > three global VA-networks in the world to function and that seems very > unlikely to happen. It feels like the VA business model is crafted > according to the lines of credit-card authorizations, but that is a rather > different type of business IMHO. > > Pardon the slightly orthogonal input, but business & technology do have > rather interesting connections... > > Anders > > > From owner-ietf-pkix Sun Jan 5 13:43:21 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05LhLf02240 for ietf-pkix-bks; Sun, 5 Jan 2003 13:43:21 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h05LhKo02234 for ; Sun, 5 Jan 2003 13:43:20 -0800 (PST) Subject: RE: OCSP and LDAP To: "Ambarish Malpani" Cc: "IETF PKIX" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Sun, 5 Jan 2003 14:45:14 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/05/2003 04:45:17 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: the thesis was that OCSP could provide a status indication as to the staleness of the static information in a certificate designed for offline operation. an online service can provide almost any level of real-time, fresh, dynamic, and/or aggregated information. For a value business operation using online, real-time, fresh, dynamic, and/or aggregated information (that is a superset of the stale, static information in a certicate designed for offline operation) ... then both the certificate becomes redundant and superfluous and therefor an OCSP transaction as to the degree of staleness of the stale, static information becomes superfluous. furthermore ... it has been trivial to show that for an operation involving transfer of money .... that the actual transaction for the transfer of money can be piggy-backed with the online, real-time, fresh, dynamic and/or aggregated information operation ... at effectively no additional cost .... and that then both a certificate and any OCSP are redundant and superluous. I can have online, real-time, fresh, dynamic, and/or aggregated information operation. Such information is a superset of offline, static, stale certificate-based information. If i'm using the online, real-time, fresh, dynamic, and/or aggregated information .... then the offline, static, stale certificate-based information is redundant and superfluous. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm "Ambarish Malpani" , biz> "IETF PKIX" Sent by: cc: owner-ietf-pkix@ma Subject: RE: OCSP and LDAP il.imc.org 01/05/2003 12:15 PM Hi Lynn, Not sure why you associate OCSP with stale information. The responder can have as current information as you choose to provide it. Once again, I believe it makes sense to have the interaction between the CA and the VA be CRLs. If there is more current information you have (than is present in the CRL), it makes sense to have that information at the VA for use until a new CRL is produced. Ambarish P.S. We have also had people use their OCSP responder to provide more than just certificate revocation information (eg. payment authorization) using extensions to OCSP. --------------------------------------------------------------------- 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 > lynn.wheeler@firstdata.com > Sent: Sunday, January 05, 2003 6:53 AM > To: Anders Rundgren > Cc: ambarish@malpani.biz; ietf-pkix@imc.org; madwolf@hackmasters.net; > owner-ietf-pkix@mail.imc.org; Peter Gutmann > Subject: Re: OCSP and LDAP > > > > > but as been discussed in other venues ... it is not only the cost ... but > also who pays (how does the money flow). does a consumer pay for > checking a > merchant's certificate as part of access the merchant's website .... which > might otherwise be free access? A merchant (as the relying party) > might pay > when checking the status of a consumer's certificate .... but does a > consumer (as the relying party) pay when checking the status of a > merchant's certificate.. Also ... as in other merchant/consumer > e-commerce > discussions .... a merchant's interest in the status (real-time or not) of > a consumer's certificate is only incidental to whether the bank says that > the merchant gets paid. > > now the other business flow as a certificate, offline, stale paradigm is > pushed towards an online, real-time model .... there is a question of what > point does the paradigm switch. In the original offline credit-card > paradigm .... the transition to online, real-time .... bypassed the > real-time checking on whether the offline, stale credential was still good > ... and/or whether the stale assertions in the offline credential > was still > good .... but whether the real-time assertions were valid. > > The model in the certificate ... is that there are some > assertions that are > inserted into a stale, static certificate at some time in the > past .... and > for OCSP ... you do real-time checks to see if the stale, static past > assertions still hold. The model that credit-cards went to .... was doing > real-time checks on real-time assertions ... not real-time checks on > real-time stale, static assertions. > > The distinction is that the payment card paradigm in moving to online ... > bypassed the intermediate paradigm of real-time checks on past, stale, > historic, static assertions (contined in the certificate) .... and went > directly to real-time checks on current, real-time assertions, aka the > credit-card industry in transitioning to online .... could have continued > to preserve the offline paradigm with real time checks (like OCSP does for > certificates) .... which is equivalent to a real-time check to see if the > consumer still has a valid account. However, the payment card industry in > transitioning to online discovered that they could significantly leverage > the utility of having real-time, online checking .... that instead of > having real-time, online checking of stale, static information .... > significantly increase the utility of having real-time checking of > real-time information. > > So the credit-card industry skipped the OCSP-analogous step of having a > real-time infrastructure for checking of stale, static data (aka does an > account still exist), and significantly improved the utility of having an > online, real-time infrastructure ... and performing real-time checking of > what the merchant is really interested in .... will they get > paid. An issue > is whether the value of having a real-time online infrastructure is > significantly depreciated if it is just being applied to checking > status of > static, stale information .... when for effectively the same > infrastructure > costs .... it can be used for real-time, online checking of real-time > dynamic information (under the assumption that real-time checking of > real-time dynamic information tends to have more value than real-time > checking of static, stale information). > > ... i believe that the charge/chost at supermarket check-out for > debit card > transaction doing real-time checking for sufficient funds for the > transaction (rather than just checking if the account still exists) > as well as scheduling the transaction .... the charge/cost for > both/combined ... is on the order of your projected lookup costs. > > If the online, real-time validation of real-time dynamic assertion (rather > the real-time validation of static, stale assertion) can be bundled with > the actual execution of real transaction .... and be bundled for > essentially the same cost of doing just online, real-time lookup > of static, > stale data .... then it would imply that static, stale data paradigm would > be somewhat redundant and superfulous in an online, real-time environment. > > -- > Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm > > > anders.rundgren@telia.com on 1/5/2002 2:44 am wrote: > > I agree with Peter. > > I don't think OCSP in a not so distant future have to be more technically > costly than accessing a web-page. Including a signed answer. > > Some banks in Sweden believe 20 cents/lookup is a reasonable fee as it is > "comparable to putting a stamp on a letter". > > Personally I don't think the VA-business model has much future as it > complicates they way parties interact. It essentially requires two or > three global VA-networks in the world to function and that seems very > unlikely to happen. It feels like the VA business model is crafted > according to the lines of credit-card authorizations, but that is a rather > different type of business IMHO. > > Pardon the slightly orthogonal input, but business & technology do have > rather interesting connections... > > Anders > > > From owner-ietf-pkix Sun Jan 5 13:31:30 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05LVUd01417 for ietf-pkix-bks; Sun, 5 Jan 2003 13:31:30 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h05LVTo01406 for ; Sun, 5 Jan 2003 13:31:29 -0800 (PST) Subject: RE: OCSP and LDAP To: "Ambarish Malpani" Cc: "IETF PKIX" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Sun, 5 Jan 2003 14:01:25 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/05/2003 04:33:26 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: the certificate typically contains some assertions (age, address, name, address, affiliation, etc) .... OCSP & CRLs are about the degree of possible staleness of the assertions/information contianed in the certificate .... not actual information itself because the information is certified in the certificate ... at some time in the past .... by definition ... you aren't going to see dynamic information .... information in a certificate is about static information as of the time the certificate is created. OCSP & CRLs doesn't represent actual information .... it represents information about possibly how stale the static information is ... not the static information itself. so a characteristic of the certificate offline paradigm is static information as of some point in the past. Online, real-time OCSP ... doesn't provide current &/or dynamic information .... it just provides some indication of how stale the static information in the certificate is. An online, real-time infrastructure has the opportunity to transition to providing online, real-time, current, & dynamic information .... not limiting itself as to an opinion as to the degree of staleness contained in the static certificate. The business issue .... is that going to the trouble & expensive of having an online, real-time infrastructure .... can be leveraged to provide real-time, online (& dynamic) information. So as in some other scenario (non payment card) .... was the issue of gov. granting business licenses of various kinds. The brain-dead translation is to give them a gov. signed certificate representing that offline, paper license. Now people that want timely information in the non-electronic world .... go to online, real-time ... by calling and/or visiting the various agencies (better business bureau, local gov. office, etc) and check on the status of the license. Actually what most people do when doing real-time checks on a business .... isn't just that the business license is still valid ... but how many complaints, what kind of complaints, what kind of recommendations, disposition of complaints, any fines, etc. If they are going to all the trouble of having a real-time check .... they aren't after the OCSP version .... if they are going to all the trouble of a real-time check ... they want the real-time, dynamic data version of the informattion (not the old fashion, offline, static & possibly stale version of the data). My assertions has not been that certificates (offline, static, stale information) are useless .... my assertions have been that if you are going to the trouble of having a real-time, online infrastructure .... that the value of that real-time online infrastructure is significantly enhanced by offering higher value information .... like real-time dynamic information. It isn't limited to the payment industry (lets say all electronic commerce) or licensing (all gov. sanction activities) .... I claim that for nearly all certification scenarios involving online, real-time ... the infrastructure goes to the trouble of having real-time dynamic data. Lets take another example ... driver's license. If you get stopped .... the typical real-time, online response isn't about whether the license is revoked or not (that is trivial subset) .... it is how many traffic citations/warrents are outstanding .... number of parking tickets, and potentially some number of other pieces of real-time, dynamic information. The issue isn't whether offline, static, stale certified infomration is useless. The issue is that in going to the trouble of having online, real-time facilities .... there is the ability and the value proposition to support online, teal-time dynamic information ... rather than offline, static stale information. All instances that I can think of where somebody is going to the trouble of some real-time, online checking .... they are getting real-time dynamic information ... not just a simple opinion about the possible degree of staleness of static, offline information. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm "Ambarish Malpani" To: , ni.biz> cc: Subject: RE: OCSP and LDAP 01/05/2003 12:15 PM Hi Lynn, Not sure why you associate OCSP with stale information. The responder can have as current information as you choose to provide it. Once again, I believe it makes sense to have the interaction between the CA and the VA be CRLs. If there is more current information you have (than is present in the CRL), it makes sense to have that information at the VA for use until a new CRL is produced. Ambarish P.S. We have also had people use their OCSP responder to provide more than just certificate revocation information (eg. payment authorization) using extensions to OCSP. --------------------------------------------------------------------- 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 > lynn.wheeler@firstdata.com > Sent: Sunday, January 05, 2003 6:53 AM > To: Anders Rundgren > Cc: ambarish@malpani.biz; ietf-pkix@imc.org; madwolf@hackmasters.net; > owner-ietf-pkix@mail.imc.org; Peter Gutmann > Subject: Re: OCSP and LDAP > > > > > but as been discussed in other venues ... it is not only the cost ... but > also who pays (how does the money flow). does a consumer pay for > checking a > merchant's certificate as part of access the merchant's website .... which > might otherwise be free access? A merchant (as the relying party) > might pay > when checking the status of a consumer's certificate .... but does a > consumer (as the relying party) pay when checking the status of a > merchant's certificate.. Also ... as in other merchant/consumer > e-commerce > discussions .... a merchant's interest in the status (real-time or not) of > a consumer's certificate is only incidental to whether the bank says that > the merchant gets paid. > > now the other business flow as a certificate, offline, stale paradigm is > pushed towards an online, real-time model .... there is a question of what > point does the paradigm switch. In the original offline credit-card > paradigm .... the transition to online, real-time .... bypassed the > real-time checking on whether the offline, stale credential was still good > ... and/or whether the stale assertions in the offline credential > was still > good .... but whether the real-time assertions were valid. > > The model in the certificate ... is that there are some > assertions that are > inserted into a stale, static certificate at some time in the > past .... and > for OCSP ... you do real-time checks to see if the stale, static past > assertions still hold. The model that credit-cards went to .... was doing > real-time checks on real-time assertions ... not real-time checks on > real-time stale, static assertions. > > The distinction is that the payment card paradigm in moving to online ... > bypassed the intermediate paradigm of real-time checks on past, stale, > historic, static assertions (contined in the certificate) .... and went > directly to real-time checks on current, real-time assertions, aka the > credit-card industry in transitioning to online .... could have continued > to preserve the offline paradigm with real time checks (like OCSP does for > certificates) .... which is equivalent to a real-time check to see if the > consumer still has a valid account. However, the payment card industry in > transitioning to online discovered that they could significantly leverage > the utility of having real-time, online checking .... that instead of > having real-time, online checking of stale, static information .... > significantly increase the utility of having real-time checking of > real-time information. > > So the credit-card industry skipped the OCSP-analogous step of having a > real-time infrastructure for checking of stale, static data (aka does an > account still exist), and significantly improved the utility of having an > online, real-time infrastructure ... and performing real-time checking of > what the merchant is really interested in .... will they get > paid. An issue > is whether the value of having a real-time online infrastructure is > significantly depreciated if it is just being applied to checking > status of > static, stale information .... when for effectively the same > infrastructure > costs .... it can be used for real-time, online checking of real-time > dynamic information (under the assumption that real-time checking of > real-time dynamic information tends to have more value than real-time > checking of static, stale information). > > ... i believe that the charge/chost at supermarket check-out for > debit card > transaction doing real-time checking for sufficient funds for the > transaction (rather than just checking if the account still exists) > as well as scheduling the transaction .... the charge/cost for > both/combined ... is on the order of your projected lookup costs. > > If the online, real-time validation of real-time dynamic assertion (rather > the real-time validation of static, stale assertion) can be bundled with > the actual execution of real transaction .... and be bundled for > essentially the same cost of doing just online, real-time lookup > of static, > stale data .... then it would imply that static, stale data paradigm would > be somewhat redundant and superfulous in an online, real-time environment. > > -- > Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm > > > anders.rundgren@telia.com on 1/5/2002 2:44 am wrote: > > I agree with Peter. > > I don't think OCSP in a not so distant future have to be more technically > costly than accessing a web-page. Including a signed answer. > > Some banks in Sweden believe 20 cents/lookup is a reasonable fee as it is > "comparable to putting a stamp on a letter". > > Personally I don't think the VA-business model has much future as it > complicates they way parties interact. It essentially requires two or > three global VA-networks in the world to function and that seems very > unlikely to happen. It feels like the VA business model is crafted > according to the lines of credit-card authorizations, but that is a rather > different type of business IMHO. > > Pardon the slightly orthogonal input, but business & technology do have > rather interesting connections... > > Anders > > > From owner-ietf-pkix Sun Jan 5 13:31:31 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05LVVw01420 for ietf-pkix-bks; Sun, 5 Jan 2003 13:31:31 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h05LVTo01409 for ; Sun, 5 Jan 2003 13:31:30 -0800 (PST) Subject: OCSP value proposition To: "Anders Rundgren" Cc: ambarish@malpani.biz, ietf-pkix@imc.org, madwolf@hackmasters.net, owner-ietf-pkix@mail.imc.org, "Peter Gutmann" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Sun, 5 Jan 2003 14:33:18 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/05/2003 04:33:27 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: ok, i'm a RP sitting here with a credential that contains some certified static, stale information .... that was designed to support an offline paradigm. The RP believes there is some business/value operation involved which has some risk issues with the staleness of the information in the certificate. A OCSP transaction provides the RP with some feeling as to the degree of staleness .... in theory to better mitigate risks associated with the value operation. My assertions are 1) a online transaction can provide real-time, fresh, dynamic, and aggregated information (which is a superset of the stale static information contained in the certificate) for approximately the same cost as a transaction about the staleness of the static certificate information. furthermore nearly every business/value operation in existence has some form of real-time, fresh, dynamic and aggregated information (for those mired in certificate paradigm ... view the online, real-time response containing this information as a one-time, immediately expiring certificate). 2) the superset of the stale, static information with real-time, fresh, dynamic, and aggregated information provides better quality risk management than an opinion as to the staleness of the certificate static information (at effectively the same cost). 3) given the same cost .... and greater value information for better risk management .... the cost/benefit analysis would nearly always benefit the real-time, fresh, dynamic aggregated response of an opinion about the degree of static information staleness. 4) the real-time, fresh, dynamic and aggregated information potentially provides the ability to piggy-back an actual business transaction as part of the underlying online operation (for little or not additional cost) .... this is the payment scenario. 5) for cost/benefit of risk management associated with real-time, fresh, aggregated, and/or dynamic may represent such a compelling business justification that all operations become online. For environment with all online operations, using real-time, fresh, aggregated, and dynamic information, then an offline certificate with static, stale information (that is a subset of real-time, fresh, aggregated and dynamic information) become totally redundant and superfluous. Certificates are at least redundant and superfluous for those transactions involving real-time, fresh, aggregated, and/or dynamic operations (if RP is getting the real-time superset information ... then the stale, static, subset information isn't needed). So the question I believe was a value proposition for OCSP that 1) involves value that justifies having online, real-time infrastructure 2) doesn't involve payments or money (as per somebody else's earlier posting since it has already been shown that money infrastructure does a piggy-back transaction based on real-time, fresh, dynamic, and aggregated information). 3) only requires an opinion as to the staleness of static information (yes/no) 4) has no incremental business justification for real-time, fresh, dynamic and/or aggregated information. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm From owner-ietf-pkix Sun Jan 5 15:11:02 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05NB2Y06572 for ietf-pkix-bks; Sun, 5 Jan 2003 15:11:02 -0800 (PST) Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h05NB1o06564 for ; Sun, 5 Jan 2003 15:11:01 -0800 (PST) Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by mailf.telia.com (8.12.5/8.12.5) with SMTP id h05NAhTk002233; Mon, 6 Jan 2003 00:10:43 +0100 (CET) X-Original-Recipient: ietf-pkix@imc.org Message-ID: <005701c2b50f$682d4790$0500a8c0@arport> From: "Anders Rundgren" To: "Ambarish Malpani" , Cc: "IETF PKIX" References: Subject: Re: OCSP and LDAP Date: Mon, 6 Jan 2003 00:08:49 +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: >Lets take another example ... driver's license. If you get stopped .... the >typical real-time, online response isn't about whether the license is >revoked or not (that is trivial subset) .... it is how many traffic >citations/warrents are outstanding .... number of parking tickets, and >potentially some number of other pieces of real-time, dynamic information. No problems. The licensee authenticates to the "traffic police server" which uses OCSP to verify that the TTP-issued license is not revoked. Assuming the license was OK the server then invokes other "authorities" for any additional information needed using the identity as given in the license (certificate). The result is returned as a nicely formatted screen on the officer's PDA. Except for the fact that the screen is static [:-)], I don't see any particular staleness here. Unless for the *possible* reliance on CRLs you have a problem with. But CRLs are just an option. But you do have a point. To put a lot of potentially stale information in a certificate is a bad idea. "Employee certificates" is an example of a broken scheme as they vouch for not less than three things: An individual, an organization, and an unspecified [= totally useless] association between these two entities. Here I really believe that your on-line, real-time paradigm will become the norm. Anders From owner-ietf-pkix Sun Jan 5 15:48:15 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05NmFt11793 for ietf-pkix-bks; Sun, 5 Jan 2003 15:48:15 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h05NmEo11786 for ; Sun, 5 Jan 2003 15:48:14 -0800 (PST) Subject: Re: OCSP and LDAP To: "Anders Rundgren" Cc: "Ambarish Malpani" , "IETF PKIX" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Sun, 5 Jan 2003 16:50:05 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/05/2003 06:50:12 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: but the whole point of an offline credential containing certified information is i can reference it offline. if i'm online .... i don't need a certificate. in the non-certificate model .... i assert that i have account number #xxx and sign the assertion with hardware token. that is sent off to the online infrastructure and it pulls up #xxx and verifies the signature with the public key in the online record. the state of the account and all related information is pulled from the account. there is no offlne certificate containing any certified stale, static information. in the payment transaction ... i make two assertions that I have account number #xxx and that i'll pay xyx .... I sign that assertion .... it is sent off .... the account #xxx is pulled up .... it checks the signature with the public key in the account record .... it checks the status of the account and decides about the payment and returns yes/no as to the payment (and whatever other information). No offline certificate with certified stale, static information is needed. for the license ... I make an assertion that i have license #abc and sign the assertions with a hardware token. the police sends off the assertions .... which verifies the public key and pulls up the record .... either direclty containing all the real-time, fresh, dynamic, and/or aggregating information .... or contains enuf information to aggregate all the information. still no offline certificate with certified stale, static information is needed The police is using the online, realtime, fresh, dynamic, and/or aggregated information. The police doesn't have to resort to a offline credential containing a stale, static subset of the online, realtime, fresh, dynamic and/or aggregated information. It is purely an artificial contrivence to claim that a offline certificate with stale static information provides any added value at the point when all of the online realtime, fresh, dynamic and/or aggregated information is available. i only need a certificate with stale, static information for offline operations where i don't have access to online, real-time, fresh, dynamic, and/or aggregated information. If I have a superset of the stale, static information in a certificate .... then the certificate is redundant and superfluous for that operation. If the certifcate is redundant and superfluous .... then an OCSP operation that gives an opinion about the staleness of the redundantant & superfluous stale, static information is also redundant and superfluous. If the value proposition is such that I always resort to the online, real-time, fresh, dynamic and/or aggregated information .... then for those value propositions an offline certificate with stale, static information is always redundant and superfluous. If the offline certificate with stale, static information is always redundant and superfluous ... then it would follow that an OCSP for a redundant and superfluous certificate is also redundant and superfluous. so there is slight vulnerability issue here. not only is the certificate in somebody's position subject to being stale static information ... but it is also potentially subject to counterfeiting (picture, name, address, birth date, etc). for low value operations with little risk .... the risk of counterfeited license is low. For high value operations with potentially more risk .... the "real" information is stored under strong security at the appropriate agency. The thing that is in somebody's hand is purely a stale, static offline copy of the real information stored online someplace. The law enforcement are bringing up the "real" information when they go onlne .... the stuff in your hand is basically a r/o stale, static copy purely for low value, low risk, offline operations. the claim that in an online environment .... that it is sufficient to have an authentication mechanism .... it isn't necessary in a real online environment to have any r/o, stale, static copy of the real information carried around on your person in a certificate for use in offline operations. If there are no offline operations .... then r/o, stale, static copies designed for use in offline operations are redundant and superfluous. For online operations, r/o, stale, static copies designed for offline use are redundant and superfluous when the real, online, fresh, realtime, dynamic and aggregated information is available. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm "Anders Rundgren" , 01/05/2003 04:08 cc: "IETF PKIX" PM Subject: Re: OCSP and LDAP >Lets take another example ... driver's license. If you get stopped .... the >typical real-time, online response isn't about whether the license is >revoked or not (that is trivial subset) .... it is how many traffic >citations/warrents are outstanding .... number of parking tickets, and >potentially some number of other pieces of real-time, dynamic information. No problems. The licensee authenticates to the "traffic police server" which uses OCSP to verify that the TTP-issued license is not revoked. Assuming the license was OK the server then invokes other "authorities" for any additional information needed using the identity as given in the license (certificate). The result is returned as a nicely formatted screen on the officer's PDA. Except for the fact that the screen is static [:-)], I don't see any particular staleness here. Unless for the *possible* reliance on CRLs you have a problem with. But CRLs are just an option. But you do have a point. To put a lot of potentially stale information in a certificate is a bad idea. "Employee certificates" is an example of a broken scheme as they vouch for not less than three things: An individual, an organization, and an unspecified [= totally useless] association between these two entities. Here I really believe that your on-line, real-time paradigm will become the norm. Anders From owner-ietf-pkix Sun Jan 5 16:02:34 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0602Y214162 for ietf-pkix-bks; Sun, 5 Jan 2003 16:02:34 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0602Wo14155 for ; Sun, 5 Jan 2003 16:02:32 -0800 (PST) Subject: Re: OCSP and LDAP To: "Anders Rundgren" Cc: "Ambarish Malpani" , "IETF PKIX" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Sun, 5 Jan 2003 17:04:22 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/05/2003 07:04:30 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: the driver's license in your hand isn't the real driver's license .... it is a r/o, stale, static copy made at some time in the past. the real driver's license is in some agency's database record. the issue about whether the real license is valid or not is stored there also. all the dynamic, fresh, aggregated, and/or realtime data is stored there ... or is pointed to by that record (if you want all the online, realtime, fresh, dynamic and/or aggregated information ... you have to read the real "license" record). for low value &/or low risk operations ... the static, stale copy that you hold will be sufficient. for situations that justify the cost of an online transaction ... to get the real-time, fresh, dynamic, and aggregated real information ... they go online to get the real information. somebody types in a driver's license number to the online system ... it could just spit back just a simple yes/no regarding the staleness of the static, r/o copy in the person's possesion. however, if somebody is going to the trouble of going online .... they type in the driver's license number to the online system .... and they get back the real license, with all the real-time, fresh, dynamic, and/or aggregated information. any information claims by the r/o, static, stale copy in the person's position .... at that point are redundant and superfluous. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm From owner-ietf-pkix Sun Jan 5 16:13:43 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h060Dh315690 for ietf-pkix-bks; Sun, 5 Jan 2003 16:13:43 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h060Dgo15684 for ; Sun, 5 Jan 2003 16:13:42 -0800 (PST) Subject: Re: OCSP and LDAP To: "Anders Rundgren" Cc: "Ambarish Malpani" , "IETF PKIX" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Sun, 5 Jan 2003 17:15:37 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/05/2003 07:15:40 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: ... aka ... i never said you can't have a certificate with r/o stale, static subset copy of the real information .... i just said that in an online environment whre you have the real-time, fresh, dynamic, &/or aggregate of the real information ... then the r/o stale, static, subset copy is redundant and superfluous. for a particular business/value operation, if the r/o stale, static, subset copy is redundant and superfluous ... then it seems to follow that an OCSP transaction giving an opinion about the staleness of tedundant and superfluous information is also superfluous. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm From owner-ietf-pkix Mon Jan 6 01:27:33 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h069RXd22593 for ietf-pkix-bks; Mon, 6 Jan 2003 01:27:33 -0800 (PST) Received: from mx1.fujixerox.co.jp (firewall-user@mx1.fujixerox.co.jp [202.32.191.28]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h069RVo22585 for ; Mon, 6 Jan 2003 01:27:31 -0800 (PST) Received: by mx1.fujixerox.co.jp; id SAA13195; Mon, 6 Jan 2003 18:27:30 +0900 (JST) Received: from unknown(129.249.118.132) by mx1.fujixerox.co.jp via smap (3.2) id xma012970; Mon, 6 Jan 03 18:26:51 +0900 Received: from ns1.fujixerox.co.jp (localhost [127.0.0.1]) by isvw2.fujixerox.co.jp (8.11.1/3.7W) with ESMTP id h069Qp321738 for ; Mon, 6 Jan 2003 18:26:51 +0900 (JST) Received: from mail.next.ksp.fujixerox.co.jp (mail.next.ksp.fujixerox.co.jp [129.249.209.162]) by ns1.fujixerox.co.jp (8.11.6/3.7W) with SMTP id h069Qn111489 for ; Mon, 6 Jan 2003 18:26:49 +0900 (JST) Received: (qmail 43644 invoked by uid 0); 6 Jan 2003 09:26:46 -0000 Received: from fxmxgw.fujixerox.co.jp (HELO carry-on5) (129.249.118.106) by mail.next.ksp.fujixerox.co.jp with SMTP; 6 Jan 2003 09:26:46 -0000 To: ietf-pkix@imc.org, multi-domain-PKI@jnsa.org Cc: miyakawa@ipa.go.jp, nao@jnsa.org, yas-matsumoto@secomtrust.net, Ryu.Inada@fujixerox.co.jp Subject: HTML version of Challenge PKI 2001 is ready. From: Ryu Inada References: <200212302251.HDD27484.ZVS@fujixerox.co.jp> <200301011412.CGC26883.EVBZB.JOS@fujixerox.co.jp> In-Reply-To: <200301011412.CGC26883.EVBZB.JOS@fujixerox.co.jp> Message-Id: <200301061822.JAB13951.BVOSZEJ.B@fujixerox.co.jp> X-Mailer: Winbiff [Version 2.42 beta2] X-Accept-Language: ja,en Date: Mon, 6 Jan 2003 18:26:49 +0900 Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; Boundary="---------1041844953-704823272" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. -----------1041844953-704823272 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear PKIX members. Happy new year ! As we announced pdf version of Challenge PKI 2001 report in 30 Dec 2003, this document has some Japanese character, and most of people could not open nor print out it. We stragled to solve the problem, but we could not success yet. So, we make a HTML verion of Challnge PKI 2001 report on following URL. http://www.ipa.go.jp/security/fy13/report/pki_interop/ chalange2001.html Our activity about PKI interoperability: http://www.jnsa.org/english/e_active2_10.html If you have a any comments, please post it multi-domain-PKI@jnsa. org. Sorry for out lack of experience about PDF. Thank you. Ryu Inada/JNSA -----------1041844953-704823272 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIGJAYJKoZIhvcNAQcCoIIGFTCCBhECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BIQwggIlMIIBjqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMEkxCzAJBgNVBAYTAkpQMR0wGwYD VQQKExRGdWppIFhlcm94IENvLiwgTHRkLjEbMBkGA1UEAxMSRnVqaSBYZXJveCBYbmV0IENB MB4XDTAwMDcyMDE1MDAwMFoXDTEwMTIzMTE0NTk1OVowSTELMAkGA1UEBhMCSlAxHTAbBgNV BAoTFEZ1amkgWGVyb3ggQ28uLCBMdGQuMRswGQYDVQQDExJGdWppIFhlcm94IFhuZXQgQ0Ew gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL9YJsiaA54WeIrWV5GqU1ty155OM8Jh3XgK 5o/QPcvFShuRuMvX162wVPJLFP+0k1g2E3qEtnCMRbRI8eiGpN7NkzqfsD8M6SdMVRxW77MM /riYVeEf5dMznul0VUQ82RQ5OEjf4DE+DSVw7dJCN4/rGG97PtDuWjdfsg1//q/fAgMBAAGj HTAbMAsGA1UdDwQEAwIBBjAMBgNVHRMEBTADAQEBMA0GCSqGSIb3DQEBBAUAA4GBAAmqWsKF HEDU+33KTLjz5aJzAp1u3nn2Cr5F3D1fr44uqmrIDwykcRRCQJmYMDxItKWNzBfemn+mjBzC Nk7gG38aUpxrD4tLl4miIAVYqu2svOzX0NvfHsy3ECQWXhU0vVMSVOFAfljHMFimLHFnhnsQ 2bQ3ijVKo8/V5Lmtc5CpMIICVzCCAcCgAwIBAgICLOEwDQYJKoZIhvcNAQEEBQAwSTELMAkG A1UEBhMCSlAxHTAbBgNVBAoTFEZ1amkgWGVyb3ggQ28uLCBMdGQuMRswGQYDVQQDExJGdWpp IFhlcm94IFhuZXQgQ0EwHhcNMDIwNDA5MTUwMDAwWhcNMDQwNDA5MTQ1OTU5WjBGMQswCQYD VQQGEwJKUDEdMBsGA1UEChMURnVqaSBYZXJveCBDby4sIEx0ZC4xGDAWBgNVBAMTDzE3NTc4 IFJ5dSBJbmFkYTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC5EZaT1mRJy4g1vM37ti+oKkVU phqtyvd5ZjA+woaL6T2PcMtU/QNUoJCT9x9kqHvDDHpBQN2qpe4u6PLsRffXAgMBAAGjgZQw gZEwDAYDVR0TBAUwAwEBADALBgNVHQ8EBAMCAaAwJAYDVR0RBB0wG4EZUnl1LkluYWRhQGZ1 aml4ZXJveC5jby5qcDARBglghkgBhvhCAQEEBAMCAKAwOwYDVR0fBDQwMjAwoC6gLIYqaHR0 cDovL3huZXQuZnVqaXhlcm94LmNvLmpwL0NSTC94bmV0Y2EuY3JsMA0GCSqGSIb3DQEBBAUA A4GBAJShNhdMVhVffoJkVnq1Q2MCztGWy1hwm36nSXCGDig+1jEyf1wtqoFU5bI7lX/c5Wto knmMFlj2AjpjIcJIx1gECECQnSX+ibtZkGiPcqzvApw0LxG7Jo77YW+N3DyMFzQYVt43k62/ onPINbf7hBwqAjJpXe0MQ+vU2jaekP23MYIBaDCCAWQCAQEwTzBJMQswCQYDVQQGEwJKUDEd MBsGA1UEChMURnVqaSBYZXJveCBDby4sIEx0ZC4xGzAZBgNVBAMTEkZ1amkgWGVyb3ggWG5l dCBDQQICLOEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMzAxMDYwOTIyMDBaMCMGCSqGSIb3DQEJBDEWBBSdUJFHOZFjubZVZoLh TDEd6VSOWDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAARA UCira9K8AFC39hZb/m6Z8TuCnpHyVemVf6uAAgIa+Qnzvgiwd/D1FZKHaXj9M0NSSHu8BkVa xkWsrvckybplng== -----------1041844953-704823272-- From owner-ietf-pkix Mon Jan 6 02:46:35 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h06AkZ402591 for ietf-pkix-bks; Mon, 6 Jan 2003 02:46:35 -0800 (PST) Received: from nalle.datum.nu (as6-6-8.s.bonet.se [217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h06AkXo02587 for ; Mon, 6 Jan 2003 02:46:33 -0800 (PST) Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id 6ABA610F544; Mon, 6 Jan 2003 11:46:24 +0100 (CET) From: "Simon Tardell" To: "'Peter Gutmann'" , , , Subject: RE: OCSP and LDAP Date: Mon, 6 Jan 2003 11:46:23 +0100 Message-ID: <003f01c2b570$db572040$0a01a8c0@stl> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200301050820.h058KHj00419@medusa01.cs.auckland.ac.nz> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, > Most of the CAs I know of issues CRLs a few times a day, some > as infrequently as once a day. If I'm doing processing with > any kind of value attached to the transaction, I want to know > whether the cert is valid right now, not whether it was OK > last night when the CRL was issued (substitute "credit card" > for "cert" to see why this is important). I have never seen > a situation where an offline CRL gives better performance > than a real-time check of a live database, unless you happen > to catch it just as the CRL is being issued, which (for a > 24-hour CRL time) only works about once in 86,400 times. This argument is backwards: The CAs are doing the minimum that they can while still conforming to the model, because noone is (as you correctly note) really asking for CRLs (or revocation checking in any other way) more than as a checkbox item. It doesn't mean that they can't. When need arises, they can switch to issuing one delta per revocation and push that their OCSP responders. It is just as up to date as coupling an OCSP responder directly to the CA database, and it keeps the CA offline. The only thing missing, from a standards perspective, is to specify the push protocol. Simon Simon Tardell, cell +46 70 3198319, simon@tardell.se From owner-ietf-pkix Mon Jan 6 03:00:37 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h06B0bP03391 for ietf-pkix-bks; Mon, 6 Jan 2003 03:00:37 -0800 (PST) Received: from nalle.datum.nu (as6-6-8.s.bonet.se [217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h06B0Zo03386 for ; Mon, 6 Jan 2003 03:00:35 -0800 (PST) Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id 1823A10F544; Mon, 6 Jan 2003 12:00:30 +0100 (CET) From: "Simon Tardell" To: "'Massimiliano Pala'" , Subject: RE: OCSP and LDAP Date: Mon, 6 Jan 2003 12:00:28 +0100 Message-ID: <006001c2b572$d31f53a0$0a01a8c0@stl> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3E18085A.6010209@hackmasters.net> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Ambarish Malpani wrote: > > Hi Massimiliano, > > You should seriously consider having your responder work off a > > CA's CRL, rather than trying to access its database directly. > > Well, our approach is towards the usage of an off-line CA so > my problem is that usually the CRL could be not up to date to > the latest status of the certificate (let's say a user > request its certificate to be revoked, from this time to the > time the CRL will be issued there could be a time gap during > which I want the certificate to be reported as invalid -- > let's say with the onHold reason). > > For this reason I need some more information rather than the only CRL. No, if you want to remove the latency in the system that is related to the issuance interval of your CRL, then you should issue CRLs immediately as the revocation occurs. > There is another question about this approach: if the client > request the status of one certificate with a serial that is > not within the CRL, should not the responder check for it > (i.e. its existance?) and if it does not have informations > about it return an "unknown" answer ? No. There is an unclear wording in RFC2560 that might lead the thoughts in that direction. "unknown" means that the OCSP is unable or unwilling to answer the revocation query (because it doesn't know the CA, or because it doesn't have up to date revocation information or whatever). A logical reaction to an "unknown" response is to go to some other OCSP responder that might be better connected for the moment. If you confuse the meaning of "unknown" to be an assertion (that the certificate was indeed never issued) then that availability feature breaks down (at least if you have the wrong kind of client). The OCSPv2 draft has a better wording. Simon Simon Tardell, cell +46 70 3198319, simon@tardell.se From owner-ietf-pkix Mon Jan 6 04:06:59 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h06C6x910738 for ietf-pkix-bks; Mon, 6 Jan 2003 04:06:59 -0800 (PST) Received: from mail.hackmasters.net (ppp-217-133-8-148.dialup.tiscali.it [217.133.8.148]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h06C6uo10731 for ; Mon, 6 Jan 2003 04:06:56 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hackmasters.net (Postfix) with ESMTP id 91FE5F356 for ; Mon, 6 Jan 2003 13:05:39 +0100 (CET) Received: by mail.hackmasters.net (Postfix, from userid 509) id D7873F35C; Mon, 6 Jan 2003 13:05:32 +0100 (CET) Received: from hackmasters.net (galadriel.mpnet.hackmasters.net [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id 988A5F356 for ; Mon, 6 Jan 2003 13:05:30 +0100 (CET) Message-ID: <3E197190.1030102@hackmasters.net> Date: Mon, 06 Jan 2003 13:07:44 +0100 From: Massimiliano Pala Organization: OpenCA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: OCSP and LDAP References: <006001c2b572$d31f53a0$0a01a8c0@stl> In-Reply-To: <006001c2b572$d31f53a0$0a01a8c0@stl> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080001070800010006050107" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080001070800010006050107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Simon Tardell wrote: [...]r this reason I need some more information rather than the only CRL. > > > No, if you want to remove the latency in the system that is related to > the issuance interval of your CRL, then you should issue CRLs > immediately as the revocation occurs. But this, in some environment it is not possible. Let's say the CA is in a timed controlled access, unavailable from 8pm to 8am (for different reasons, i.e. security, lack of personnel, etc.. ) and a user asks for revocation at 9pm, should we let the certificate being reported as valid till 8am ? For this reason I need some additional information, my question was about the presence of a standard describing where to store them onto LDAP and if, to you, it could be better storing them on a per certificate basis or in a single entry in the main organization entry. [ unknown ] > No. There is an unclear wording in RFC2560 that might lead the thoughts > in that direction. "unknown" means that the OCSP is unable or unwilling > to answer the revocation query (because it doesn't know the CA, or > because it doesn't have up to date revocation information or whatever). > A logical reaction to an "unknown" response is to go to some other OCSP > responder that might be better connected for the moment. If you confuse > the meaning of "unknown" to be an assertion (that the certificate was > indeed never issued) then that availability feature breaks down (at > least if you have the wrong kind of client). The OCSPv2 draft has a > better wording. Quoting the RFC2560 << The "unknown" state indicates that the responder doesn't know about the certificate being requested. >>. I was not saying that the "unknown" means that the certificate has never being issued, anyway how could the responder know which certificates have been issued ? In this case the responder can';t be sure about the validity of a certificate and it should, to me at least, therefore return an "unknown" status. Because of these considerations I think the OCSP reponder needs additional data besides the only CRL(s), although I know that this is a fast way of having it working but this works only when the CRLs are immediately (in the same second) issued after certificate revocation and this does not work in environment when some human interaction (for example verification). It seems, to me, just translating the CRLs in another format without adding a real improvement to the validating process... I think the OCSP to be more useful than this. -- C'you, Massimiliano Pala --o------------------------------------------------------------------------- Massimiliano Pala [OpenCA Project Manager] madwolf@openca.org Tel.: +39 (0)59 270 094 http://www.openca.org Fax: +39 178 221 8225 http://openca.sourceforge.net Mobile: +39 (0)347 7222 365 --------------ms080001070800010006050107 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOZjCC By8wggYXoAMCAQICASwwDQYJKoZIhvcNAQEEBQAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5j aWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9u ZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkG A1UEBhMCSVQwHhcNMDIwNzI0MTUyNjI2WhcNMDMxMjMxMjM1OTU5WjCBqTEaMBgGA1UEAxMR TWFzc2ltaWxpYW5vIFBhbGExNTAzBgNVBAsTLERpcGFydGltZW50byBkaSBJbmdlZ25lcmlh IGRlbGwnSW5mb3JtYXppb25lMRcwFQYDVQQLEw5TZWRlIGRpIE1vZGVuYTEuMCwGA1UEChMl VW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQwgZ8w DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANSesg80BGzryvQlplD0MJ2YWlSEUAZpiFmywpOm l//lWMnhONmC/q0TrO7j9Bb195dNzCMuXFgvV49Sy1iyHAjDhpysFvm/xZbAS3j8prXNN23K S3Oa7Zz2GrQpCHgupCPQL2cy+ARVwwFod2GOSCVoUACkndit964K/bfsGvyLAgMBAAGjggQB MIID/TAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCA/gw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6aSO5yTMPTf9OdcWo 14pKLqEHMDCBtwYDVR0jBIGvMIGsgBRFHaYA4ZfoyU2aaUnZYMiYf4lFA6GBkKSBjTCBijEi MCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMeVW5pbW9yZSBF bnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBkaSBNb2RlbmEg ZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVIIBADBqBglghkgBhvhCAQ0EXRZbUHJvZ2V0 dG8gUG9zdGEgRWxldHRyb25pY2EgU2ljdXJhIA0KVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUg UmVnZ2lvIEVtaWxpYSANCkMuSS5DLkEuSS5BLiANCjAiBgNVHREEGzAZgRdtYWR3b2xmQGhh Y2ttYXN0ZXJzLm5ldDA0BgNVHRIELTArgRNwa2kuY2ljYWlhQHVuaW1vLml0hhRodHRwOi8v cGtpLnVuaW1vLml0LzA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAKGI2h0dHA6Ly9wa2ku dW5pbW8uaXQvY2EvaXNzdWVycy5odG1sMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9wa2ku dW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQQEIxYhaHR0cDovL3BraS51bmlt by5pdC9jcmwvY2FjcmwuY3JsMDAGCWCGSAGG+EIBAwQjFiFodHRwOi8vcGtpLnVuaW1vLml0 L2NybC9jYWNybC5jcmwwKgYJYIZIAYb4QgEHBB0WG2h0dHA6Ly9wa2kudW5pbW8uaXQvcmVu ZXdhbDArBglghkgBhvhCAQgEHhYcaHR0cDovL3BraS51bmltby5pdC9jcHMvMS4xLzCB2QYD VR0gBIHRMIHOMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJv cGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMEEGCisGAQQBqQcCAQEwMzAxBggrBgEFBQcCARYl aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBEBgorBgEEAegTAQEBMDYw NAYIKwYBBQUHAgEWKGh0dHA6Ly9tYWlsLnVuaW1vLml0L2Zpcm1hL2Nwc21vZGVuYS5odG0w DQYJKoZIhvcNAQEEBQADggEBABn8ViNg4MPNRzEFFF4BsmRMP1YbUHbS+NmFvvys0D3xueex Ie6HU+tkv9hz8++0MbLPnRY2qKpZXfWTbIOkrHLGVVHUkiZXFzfxsDMgcB4MWmSmhRVLfPqr RZKAjIevO0JKIksq2xutAUqX5jkqZoGHpPv9JCiSI+cDRqOOW2Fh3JBGkcULKybrdwrSN6+S NoTyTXR+ryeTBUXxu9rIbjrJdH3rKS7rz3ZkP2PKuFOb+Vbp829ALph1SJOLQrUnmJouLOSL oVHW4zJK4zcAiNyMHua3HveLRkVINT9eDBeYBRPdn1k+LqdXqkXiEUPA+EIKeA23F5nQkqxI mVVpaaYwggcvMIIGF6ADAgECAgEsMA0GCSqGSIb3DQEBBAUAMIGKMSIwIAYJKoZIhvcNAQkB FhNwa2kuY2ljYWlhQHVuaW1vLml0MScwJQYDVQQDEx5Vbmltb3JlIEVudGUgZGkgQ2VydGlm aWNhemlvbmUxLjAsBgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWls aWExCzAJBgNVBAYTAklUMB4XDTAyMDcyNDE1MjYyNloXDTAzMTIzMTIzNTk1OVowgakxGjAY BgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMTUwMwYDVQQLEyxEaXBhcnRpbWVudG8gZGkgSW5n ZWduZXJpYSBkZWxsJ0luZm9ybWF6aW9uZTEXMBUGA1UECxMOU2VkZSBkaSBNb2RlbmExLjAs BgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWlsaWExCzAJBgNVBAYT AklUMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUnrIPNARs68r0JaZQ9DCdmFpUhFAG aYhZssKTppf/5VjJ4TjZgv6tE6zu4/QW9feXTcwjLlxYL1ePUstYshwIw4acrBb5v8WWwEt4 /Ka1zTdtyktzmu2c9hq0KQh4LqQj0C9nMvgEVcMBaHdhjkglaFAApJ3YrfeuCv237Br8iwID AQABo4IEATCCA/0wDAYDVR0TAQH/BAIwADARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/ BAQDAgP4MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+mkjuckz D03/TnXFqNeKSi6hBzAwgbcGA1UdIwSBrzCBrIAURR2mAOGX6MlNmmlJ2WDImH+JRQOhgZCk gY0wgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVu aW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkg TW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVSCAQAwagYJYIZIAYb4QgENBF0W W1Byb2dldHRvIFBvc3RhIEVsZXR0cm9uaWNhIFNpY3VyYSANClVuaXZlcnNpdGEnIGRpIE1v ZGVuYSBlIFJlZ2dpbyBFbWlsaWEgDQpDLkkuQy5BLkkuQS4gDQowIgYDVR0RBBswGYEXbWFk d29sZkBoYWNrbWFzdGVycy5uZXQwNAYDVR0SBC0wK4ETcGtpLmNpY2FpYUB1bmltby5pdIYU aHR0cDovL3BraS51bmltby5pdC8wPwYIKwYBBQUHAQEEMzAxMC8GCCsGAQUFBzAChiNodHRw Oi8vcGtpLnVuaW1vLml0L2NhL2lzc3VlcnMuaHRtbDAyBgNVHR8EKzApMCegJaAjhiFodHRw Oi8vcGtpLnVuaW1vLml0L2NybC9jYWNybC5jcmwwMAYJYIZIAYb4QgEEBCMWIWh0dHA6Ly9w a2kudW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQMEIxYhaHR0cDovL3BraS51 bmltby5pdC9jcmwvY2FjcmwuY3JsMCoGCWCGSAGG+EIBBwQdFhtodHRwOi8vcGtpLnVuaW1v Lml0L3JlbmV3YWwwKwYJYIZIAYb4QgEIBB4WHGh0dHA6Ly9wa2kudW5pbW8uaXQvY3BzLzEu MS8wgdkGA1UdIASB0TCBzjBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93 d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYB BQUHAgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRAYKKwYBBAHo EwEBATA2MDQGCCsGAQUFBwIBFihodHRwOi8vbWFpbC51bmltby5pdC9maXJtYS9jcHNtb2Rl bmEuaHRtMA0GCSqGSIb3DQEBBAUAA4IBAQAZ/FYjYODDzUcxBRReAbJkTD9WG1B20vjZhb78 rNA98bnnsSHuh1PrZL/Yc/PvtDGyz50WNqiqWV31k2yDpKxyxlVR1JImVxc38bAzIHAeDFpk poUVS3z6q0WSgIyHrztCSiJLKtsbrQFKl+Y5KmaBh6T7/SQokiPnA0ajjlthYdyQRpHFCysm 63cK0jevkjaE8k10fq8nkwVF8bvayG46yXR96yku6892ZD9jyrhTm/lW6fNvQC6YdUiTi0K1 J5iaLizki6FR1uMySuM3AIjcjB7mtx73i0ZFSDU/XgwXmAUT3Z9ZPi6nV6pF4hFDwPhCCngN txeZ0JKsSJlVaWmmMYIDNjCCAzICAQEwgZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNh aWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEu MCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UE BhMCSVQCASwwCQYFKw4DAhoFAKCCAfswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDMwMTA2MTIwNzQ0WjAjBgkqhkiG9w0BCQQxFgQUM4rDilnRIbsRrVyv VV3fowSySN8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaEGCSsGAQQBgjcQBDGB kzCBkDCBijEiMCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMe VW5pbW9yZSBFbnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBk aSBNb2RlbmEgZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVAIBLDCBowYLKoZIhvcNAQkQ AgsxgZOggZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNV BAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0 YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQCASwwDQYJKoZIhvcN AQEBBQAEgYCuMUWKwY4qbHSboVFdLSHhHBxMtnCcyurIHl1xXI21GtHC94XHIPwT79RX3Bmt ZfmcwrWq/WKbssB3IuxA2TIYSMrLlMpYXXUVqDSoJ3pJwKEGYVMjz+Oam9y8BpX+k30fDQH0 AULx6K3dBIxeVkvusk9sy1BO2ZqPfdcNZfZobgAAAAAAAA== --------------ms080001070800010006050107-- From owner-ietf-pkix Mon Jan 6 06:35:58 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h06EZwL24857 for ietf-pkix-bks; Mon, 6 Jan 2003 06:35:58 -0800 (PST) Received: from mail.hackmasters.net (ppp-217-133-8-148.dialup.tiscali.it [217.133.8.148]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h06EZro24841 for ; Mon, 6 Jan 2003 06:35:54 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hackmasters.net (Postfix) with ESMTP id 7C8F2F356 for ; Mon, 6 Jan 2003 15:34:45 +0100 (CET) Received: by mail.hackmasters.net (Postfix, from userid 509) id 04AA8F35C; Mon, 6 Jan 2003 15:34:39 +0100 (CET) Received: from hackmasters.net (galadriel.mpnet.hackmasters.net [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id E7200F356 for ; Mon, 6 Jan 2003 15:34:36 +0100 (CET) Message-ID: <3E199483.4040803@hackmasters.net> Date: Mon, 06 Jan 2003 15:36:51 +0100 From: Massimiliano Pala Organization: OpenCA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: OCSP and LDAP References: <00256CA6.004E010D.00@postoffice.co.uk> In-Reply-To: <00256CA6.004E010D.00@postoffice.co.uk> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030100040009040907050700" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030100040009040907050700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit chris.gilbert@royalmail.com wrote: > Then the certificate policy under which the EE cert was issued > is inappropriate for the use to which the certificate itself is > being put. If the EE requires up-to-the-minute revocation > information to be available to it's correspondents then it > should make sure it is using a CA that can fulfil these > requirements. Legality first, technology second. I understand your point and I do agree with you that the policy is at the first place when setting up a CA. Anyway I do not agree with you when you state that this is the only way, at least now that there is the OCSP. As I stated in my last email my question was about the best method of doing things was, but still I think the OCSP can behave better than the old CRL mechanisms, otherwise why implementing OCSP when the client could check the CRL by itself ? Anyway thank to you all for sharing your point of view on the subject, although I assume I am the only one supporting this approach to the OCSP (right?) :-( -- C'you, Massimiliano Pala --o------------------------------------------------------------------------- Massimiliano Pala [OpenCA Project Manager] madwolf@openca.org Tel.: +39 (0)59 270 094 http://www.openca.org Fax: +39 178 221 8225 http://openca.sourceforge.net Mobile: +39 (0)347 7222 365 --------------ms030100040009040907050700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOZjCC By8wggYXoAMCAQICASwwDQYJKoZIhvcNAQEEBQAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5j aWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9u ZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkG A1UEBhMCSVQwHhcNMDIwNzI0MTUyNjI2WhcNMDMxMjMxMjM1OTU5WjCBqTEaMBgGA1UEAxMR TWFzc2ltaWxpYW5vIFBhbGExNTAzBgNVBAsTLERpcGFydGltZW50byBkaSBJbmdlZ25lcmlh IGRlbGwnSW5mb3JtYXppb25lMRcwFQYDVQQLEw5TZWRlIGRpIE1vZGVuYTEuMCwGA1UEChMl VW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQwgZ8w DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANSesg80BGzryvQlplD0MJ2YWlSEUAZpiFmywpOm l//lWMnhONmC/q0TrO7j9Bb195dNzCMuXFgvV49Sy1iyHAjDhpysFvm/xZbAS3j8prXNN23K S3Oa7Zz2GrQpCHgupCPQL2cy+ARVwwFod2GOSCVoUACkndit964K/bfsGvyLAgMBAAGjggQB MIID/TAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCA/gw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6aSO5yTMPTf9OdcWo 14pKLqEHMDCBtwYDVR0jBIGvMIGsgBRFHaYA4ZfoyU2aaUnZYMiYf4lFA6GBkKSBjTCBijEi MCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMeVW5pbW9yZSBF bnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBkaSBNb2RlbmEg ZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVIIBADBqBglghkgBhvhCAQ0EXRZbUHJvZ2V0 dG8gUG9zdGEgRWxldHRyb25pY2EgU2ljdXJhIA0KVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUg UmVnZ2lvIEVtaWxpYSANCkMuSS5DLkEuSS5BLiANCjAiBgNVHREEGzAZgRdtYWR3b2xmQGhh Y2ttYXN0ZXJzLm5ldDA0BgNVHRIELTArgRNwa2kuY2ljYWlhQHVuaW1vLml0hhRodHRwOi8v cGtpLnVuaW1vLml0LzA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAKGI2h0dHA6Ly9wa2ku dW5pbW8uaXQvY2EvaXNzdWVycy5odG1sMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9wa2ku dW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQQEIxYhaHR0cDovL3BraS51bmlt by5pdC9jcmwvY2FjcmwuY3JsMDAGCWCGSAGG+EIBAwQjFiFodHRwOi8vcGtpLnVuaW1vLml0 L2NybC9jYWNybC5jcmwwKgYJYIZIAYb4QgEHBB0WG2h0dHA6Ly9wa2kudW5pbW8uaXQvcmVu ZXdhbDArBglghkgBhvhCAQgEHhYcaHR0cDovL3BraS51bmltby5pdC9jcHMvMS4xLzCB2QYD VR0gBIHRMIHOMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJv cGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMEEGCisGAQQBqQcCAQEwMzAxBggrBgEFBQcCARYl aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBEBgorBgEEAegTAQEBMDYw NAYIKwYBBQUHAgEWKGh0dHA6Ly9tYWlsLnVuaW1vLml0L2Zpcm1hL2Nwc21vZGVuYS5odG0w DQYJKoZIhvcNAQEEBQADggEBABn8ViNg4MPNRzEFFF4BsmRMP1YbUHbS+NmFvvys0D3xueex Ie6HU+tkv9hz8++0MbLPnRY2qKpZXfWTbIOkrHLGVVHUkiZXFzfxsDMgcB4MWmSmhRVLfPqr RZKAjIevO0JKIksq2xutAUqX5jkqZoGHpPv9JCiSI+cDRqOOW2Fh3JBGkcULKybrdwrSN6+S NoTyTXR+ryeTBUXxu9rIbjrJdH3rKS7rz3ZkP2PKuFOb+Vbp829ALph1SJOLQrUnmJouLOSL oVHW4zJK4zcAiNyMHua3HveLRkVINT9eDBeYBRPdn1k+LqdXqkXiEUPA+EIKeA23F5nQkqxI mVVpaaYwggcvMIIGF6ADAgECAgEsMA0GCSqGSIb3DQEBBAUAMIGKMSIwIAYJKoZIhvcNAQkB FhNwa2kuY2ljYWlhQHVuaW1vLml0MScwJQYDVQQDEx5Vbmltb3JlIEVudGUgZGkgQ2VydGlm aWNhemlvbmUxLjAsBgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWls aWExCzAJBgNVBAYTAklUMB4XDTAyMDcyNDE1MjYyNloXDTAzMTIzMTIzNTk1OVowgakxGjAY BgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMTUwMwYDVQQLEyxEaXBhcnRpbWVudG8gZGkgSW5n ZWduZXJpYSBkZWxsJ0luZm9ybWF6aW9uZTEXMBUGA1UECxMOU2VkZSBkaSBNb2RlbmExLjAs BgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWlsaWExCzAJBgNVBAYT AklUMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUnrIPNARs68r0JaZQ9DCdmFpUhFAG aYhZssKTppf/5VjJ4TjZgv6tE6zu4/QW9feXTcwjLlxYL1ePUstYshwIw4acrBb5v8WWwEt4 /Ka1zTdtyktzmu2c9hq0KQh4LqQj0C9nMvgEVcMBaHdhjkglaFAApJ3YrfeuCv237Br8iwID AQABo4IEATCCA/0wDAYDVR0TAQH/BAIwADARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/ BAQDAgP4MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+mkjuckz D03/TnXFqNeKSi6hBzAwgbcGA1UdIwSBrzCBrIAURR2mAOGX6MlNmmlJ2WDImH+JRQOhgZCk gY0wgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVu aW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkg TW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVSCAQAwagYJYIZIAYb4QgENBF0W W1Byb2dldHRvIFBvc3RhIEVsZXR0cm9uaWNhIFNpY3VyYSANClVuaXZlcnNpdGEnIGRpIE1v ZGVuYSBlIFJlZ2dpbyBFbWlsaWEgDQpDLkkuQy5BLkkuQS4gDQowIgYDVR0RBBswGYEXbWFk d29sZkBoYWNrbWFzdGVycy5uZXQwNAYDVR0SBC0wK4ETcGtpLmNpY2FpYUB1bmltby5pdIYU aHR0cDovL3BraS51bmltby5pdC8wPwYIKwYBBQUHAQEEMzAxMC8GCCsGAQUFBzAChiNodHRw Oi8vcGtpLnVuaW1vLml0L2NhL2lzc3VlcnMuaHRtbDAyBgNVHR8EKzApMCegJaAjhiFodHRw Oi8vcGtpLnVuaW1vLml0L2NybC9jYWNybC5jcmwwMAYJYIZIAYb4QgEEBCMWIWh0dHA6Ly9w a2kudW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQMEIxYhaHR0cDovL3BraS51 bmltby5pdC9jcmwvY2FjcmwuY3JsMCoGCWCGSAGG+EIBBwQdFhtodHRwOi8vcGtpLnVuaW1v Lml0L3JlbmV3YWwwKwYJYIZIAYb4QgEIBB4WHGh0dHA6Ly9wa2kudW5pbW8uaXQvY3BzLzEu MS8wgdkGA1UdIASB0TCBzjBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93 d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYB BQUHAgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRAYKKwYBBAHo EwEBATA2MDQGCCsGAQUFBwIBFihodHRwOi8vbWFpbC51bmltby5pdC9maXJtYS9jcHNtb2Rl bmEuaHRtMA0GCSqGSIb3DQEBBAUAA4IBAQAZ/FYjYODDzUcxBRReAbJkTD9WG1B20vjZhb78 rNA98bnnsSHuh1PrZL/Yc/PvtDGyz50WNqiqWV31k2yDpKxyxlVR1JImVxc38bAzIHAeDFpk poUVS3z6q0WSgIyHrztCSiJLKtsbrQFKl+Y5KmaBh6T7/SQokiPnA0ajjlthYdyQRpHFCysm 63cK0jevkjaE8k10fq8nkwVF8bvayG46yXR96yku6892ZD9jyrhTm/lW6fNvQC6YdUiTi0K1 J5iaLizki6FR1uMySuM3AIjcjB7mtx73i0ZFSDU/XgwXmAUT3Z9ZPi6nV6pF4hFDwPhCCngN txeZ0JKsSJlVaWmmMYIDNjCCAzICAQEwgZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNh aWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEu MCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UE BhMCSVQCASwwCQYFKw4DAhoFAKCCAfswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDMwMTA2MTQzNjUxWjAjBgkqhkiG9w0BCQQxFgQUkYsVhagk+f8LBQ2M dLu8b5QHAQMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaEGCSsGAQQBgjcQBDGB kzCBkDCBijEiMCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMe VW5pbW9yZSBFbnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBk aSBNb2RlbmEgZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVAIBLDCBowYLKoZIhvcNAQkQ AgsxgZOggZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNV BAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0 YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQCASwwDQYJKoZIhvcN AQEBBQAEgYAbcUhmtGmJVVJghN3PZcn3i3z+MZupI/l42QHdhtFfOdYhqVAsB9mcDVL6ZLxY 5oeuUy0rhK7N5eBMNmaporbhzSlbs0aETn8to/7r1BoikLdG75zVWl7wf517TzzvtaN1+cV4 p7Ts6KNeu8LHaLIAusOb+l8PZNbtKOfbsU6SWgAAAAAAAA== --------------ms030100040009040907050700-- From owner-ietf-pkix Mon Jan 6 06:16:03 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h06EG3R22744 for ietf-pkix-bks; Mon, 6 Jan 2003 06:16:03 -0800 (PST) Received: from mail4.consignia.com (mail4.consignia.com [144.87.143.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h06EG1o22738 for ; Mon, 6 Jan 2003 06:16:01 -0800 (PST) Received: from postoffice.co.uk (mta1.int.consignia.com [144.87.146.14]) by mail4.consignia.com (Postfix) with SMTP id DE7E4122131; Mon, 6 Jan 2003 14:15:58 +0000 (GMT) Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 00256CA6.004E0431 ; Mon, 6 Jan 2003 14:12:08 +0000 X-Lotus-FromDomain: POSTOFFICE From: chris.gilbert@Royalmail.com To: Massimiliano Pala Cc: ietf-pkix@imc.org Message-ID: <00256CA6.004E010D.00@postoffice.co.uk> Date: Mon, 6 Jan 2003 14:15:46 +0000 Subject: Re: OCSP and LDAP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > But this, in some environment it is not possible. Let's say the > CA is in a timed controlled access, unavailable from 8pm to 8am > (for different reasons, i.e. security, lack of personnel, etc.. ) > and a user asks for revocation at 9pm, should we let the certificate > being reported as valid till 8am ? Then the certificate policy under which the EE cert was issued is inappropriate for the use to which the certificate itself is being put. If the EE requires up-to-the-minute revocation information to be available to it's correspondents then it should make sure it is using a CA that can fulfil these requirements. Legality first, technology second. Chris This email and any attachments are confidential and intended for the addressee only. If you are not the named recipient, you must not use, disclose, reproduce, copy or distribute the contents of this communication. If you have received this in error, please contact the sender and then delete this email from your system. From owner-ietf-pkix Mon Jan 6 12:14:55 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h06KEtn13768 for ietf-pkix-bks; Mon, 6 Jan 2003 12:14:55 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h06KEpo13750 for ; Mon, 6 Jan 2003 12:14:51 -0800 (PST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h06KEmmd134428 for ; Mon, 6 Jan 2003 15:14:48 -0500 Received: from d01hub03.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h06KEjfI056846 for ; Mon, 6 Jan 2003 15:14:46 -0500 To: ietf-pkix@imc.org MIME-Version: 1.0 Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option) X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Timothy Hahn X-MIMETrack: S/MIME Sign by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/06/2003 03:14:07 PM, Serialize by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/06/2003 03:14:07 PM, Serialize complete at 01/06/2003 03:14:07 PM, Itemize by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/06/2003 03:14:07 PM, S/MIME Sign complete at 01/06/2003 03:14:07 PM, S/MIME Sign by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/06/2003 03:14:45 PM, S/MIME Sign complete at 01/06/2003 03:14:45 PM, MIME-CD by Router on D01MLC96/01/M/IBM(Build V601_12152002 SPR MIAS5GXKFV CBOD5GVRDB|December 20, 2002) at 01/06/2003 15:14:46, MIME-CD complete at 01/06/2003 15:14:46, Serialize by Router on D01HUB03/01/H/IBM(Release 6.0 [IBM]|December 22, 2002) at 01/06/2003 15:14:45 Message-ID: Date: Mon, 6 Jan 2003 15:14:45 -0500 Content-type: multipart/mixed; Boundary="0__=0ABBE635DFFDEBB78f9e8a93df938690918c0ABBE635DFFDEBB7" Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --0__=0ABBE635DFFDEBB78f9e8a93df938690918c0ABBE635DFFDEBB7 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Hello all, After listening to the different view-points on this topic, it seems to= me that there are multiple valid approaches. =A0These approaches include, = but are not limited to: =A0 - leveraging the general solution of component-matching =A0 - new schema to support application-managed componentization of information to make things searchable as well as others (additional matching rules, for example). It occurs to me that perhaps we have a situation where "one size does n= ot fit all". =A0Why not accept this and define a way for applications to determine which (of possibly multiple) format(s) has been used to place= the information into the directory? =A0We could define some small bit of sc= hema which indicates the way in which the certificate information is placed = into the directory, then different applications could query this and determi= ne: =A0 - whether they can use the data at all =A0 - if they can use the data, how they can best use it (if there are,= for example, multiple mechanisms employed). Just a thought to get us through this discussion. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Durham/IBM@IBMUS phone: 919.224.1565 =A0 =A0 tie-line: 8/687.1565 fax: 919.224.2540 = --0__=0ABBE635DFFDEBB78f9e8a93df938690918c0ABBE635DFFDEBB7 Content-type: application/octet-stream; name="=?ISO-8859-1?Q?smime=2Ep7s?=" Content-Disposition: attachment; filename="=?ISO-8859-1?Q?smime=2Ep7s?=" Content-transfer-encoding: base64 MIAGCSqGSIb3DQEHAqCAMIIULwIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISUDCCAtow ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1 aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf 1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117 ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r 1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0 MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf 1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn 00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMiMIIC i6ADAgECAgJONTANBgkqhkiG9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJu YXRpb25hbCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MB4XDTAyMTEyMTEzMDY1M1oXDTAzMTIwNTEzMDY1M1owgYQxCzAJ BgNVBAYTAlVTMQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRgwFgYDVQQDEw9UaW1v dGh5IEouIEhhaG4xGTAXBgoJkiaJk/IsZAEBEwkxMjg4NTc4OTcxHzAdBgkqhkiG9w0BCQEWEGhh aG50QHVzLmlibS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMZRHQYCNd56O2LkRqmV bpvr70BMnmNf+UWqMbgJ0v8Y5Vb3hdrThAoyNs3XKbFl9oYir3AFiZHVPUpFM2anK8+Sb9IqzfIh g/x6Tu9wVHPXkve+wBCGneHD2GgvIx7NEECdr7YuOd7SWevXcLloLu3yQ7Hb2aZ1MQ8o78M9S7K1 AgMBAAGjgbwwgbkwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQU z9GrkTcJqnyWERTvptgBPQmzC/QwKwYDVR0RBCQwIqAgBgorBgEEAYI3FAIDoBIMEGhhaG50QHVz LmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7zSkAwJwYDVR0lBCAwHgYIKwYB BQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0BAQQFAAOBgQCHcqGsmuSPRftlK36s f5HfVXRhzCbH63xR5jLTpzFIfzoNo8u8yeC2yu81Ylj3rLzKmcwNtb9rkQT+wqWJH498ECe66dOQ 6tUDHk3VYGYZ3QrerjTBWBnKoekfUMcp+9xtjsHYVfMEopW/0FU6QsMwj3vouSy6Uv5nTGxKIi73 ZzCCAyIwggKLoAMCAQICAk41MA0GCSqGSIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQK EytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJ Qk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDIxMTIxMTMwNjUzWhcNMDMxMjA1MTMwNjUz WjCBhDELMAkGA1UEBhMCVVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxGDAWBgNV BAMTD1RpbW90aHkgSi4gSGFobjEZMBcGCgmSJomT8ixkAQETCTEyODg1Nzg5NzEfMB0GCSqGSIb3 DQEJARYQaGFobnRAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxlEdBgI1 3no7YuRGqZVum+vvQEyeY1/5RaoxuAnS/xjlVveF2tOECjI2zdcpsWX2hiKvcAWJkdU9SkUzZqcr z5Jv0irN8iGD/HpO73BUc9eS977AEIad4cPYaC8jHs0QQJ2vti453tJZ69dwuWgu7fJDsdvZpnUx Dyjvwz1LsrUCAwEAAaOBvDCBuTARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G A1UdDgQWBBTP0auRNwmqfJYRFO+m2AE9CbML9DArBgNVHREEJDAioCAGCisGAQQBgjcUAgOgEgwQ aGFobnRAdXMuaWJtLmNvbTAfBgNVHSMEGDAWgBSuVA6S6qgzqSskLcfIbzDc3vNKQDAnBgNVHSUE IDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBAIdyoaya 5I9F+2Urfqx/kd9VdGHMJsfrfFHmMtOnMUh/Og2jy7zJ4LbK7zViWPesvMqZzA21v2uRBP7CpYkf j3wQJ7rp05Dq1QMeTdVgZhndCt6uNMFYGcqh6R9Qxyn73G2OwdhV8wSilb/QVTpCwzCPe+i5LLpS /mdMbEoiLvdnMYIBujCCAbYCAQEwbzBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRp b25hbCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5AgJONTAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDEwNjIwMTQwN1owIwYJKoZIhvcNAQkEMRYEFEw949jhi8Vo OowQG+xHD56xHhe/MEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcNAwICAgCAMAoG CCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAlIETn5YN6CdoxL44n0qT iWUBhF+2QL/DZKxWGMx3wtCMIELh3HoHDG0kAXXgSl81HlNXIhyFpNQAOTRe9VEqZ/J1oEzup8jZ QAltLAdwjY+qDzVV6CiF9x/T1Fzo566nSdt04GoymbupsXlZN62Du0r2G3Zhof5GJTn1iAiGlQgA AAAA --0__=0ABBE635DFFDEBB78f9e8a93df938690918c0ABBE635DFFDEBB7-- From owner-ietf-pkix Mon Jan 6 13:29:25 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h06LTPa18206 for ietf-pkix-bks; Mon, 6 Jan 2003 13:29:25 -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 h06LTNo18202 for ; Mon, 6 Jan 2003 13:29:24 -0800 (PST) Received: (qmail 28156 invoked from network); 6 Jan 2003 21:28:54 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.219.29) by woodstock.binhost.com with SMTP; 6 Jan 2003 21:28:54 -0000 Message-Id: <5.2.0.9.2.20030106162604.02959a38@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 06 Jan 2003 16:28:47 -0500 To: Timothy Hahn From: Russ Housley Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option) Cc: ietf-pkix@imc.org 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: Tim: I do not understand how a client is better off with multiple ways to put the same information in the Directory. Doesn't this approach just make the client fat? It seem to me that the client would have to support all of the possible ways that the information could be stored. It cannot know which method it will encounter until it starts looking at data in the Directory. Russ At 03:14 PM 1/6/2003 -0500, Timothy Hahn wrote: >Hello all, > >After listening to the different view-points on this topic, it seems to me >that there are multiple valid approaches. These approaches include, but >are not limited to: > - leveraging the general solution of component-matching > - new schema to support application-managed componentization of >information to make things searchable >as well as others (additional matching rules, for example). > >It occurs to me that perhaps we have a situation where "one size does not >fit all". Why not accept this and define a way for applications to >determine which (of possibly multiple) format(s) has been used to place the >information into the directory? We could define some small bit of schema >which indicates the way in which the certificate information is placed into >the directory, then different applications could query this and determine: > - whether they can use the data at all > - if they can use the data, how they can best use it (if there are, for >example, multiple mechanisms employed). > >Just a thought to get us through this discussion. > >Regards, >Tim Hahn From owner-ietf-pkix Tue Jan 7 03:13:09 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07BD9L06090 for ietf-pkix-bks; Tue, 7 Jan 2003 03:13:09 -0800 (PST) Received: from nalle.datum.nu (as6-6-8.s.bonet.se [217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07BD5o06079 for ; Tue, 7 Jan 2003 03:13:05 -0800 (PST) Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id CC8E810F544; Tue, 7 Jan 2003 12:12:54 +0100 (CET) From: "Simon Tardell" To: "'Massimiliano Pala'" , Subject: RE: OCSP and LDAP Date: Tue, 7 Jan 2003 12:12:53 +0100 Message-ID: <00f901c2b63d$b961f460$0a01a8c0@stl> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3E197190.1030102@hackmasters.net> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Simon Tardell wrote: > [...]r this reason I need some more information rather than > the only CRL. > > > > > > No, if you want to remove the latency in the system that is > related to > > the issuance interval of your CRL, then you should issue CRLs > > immediately as the revocation occurs. > > But this, in some environment it is not possible. Let's say > the CA is in a timed controlled access, unavailable from 8pm > to 8am (for different reasons, i.e. security, lack of > personnel, etc.. ) and a user asks for revocation at 9pm, > should we let the certificate being reported as valid till 8am ? Not necessarily. Just because the staff is in bed, it doesn't mean that the CA can't issue deltas with onHold in the meanwhile. It achieves the same thing, except two things: 1/ You don't introduce an extra directory which -- --would have to be sufficiently understood in order not to compromise the security of the system as a whole --would not be interoperable with anyone elses CA (private schema) 2/ You don't introduce another source of authority beside the CA. Although it is the business idea of a wellknown company, many believe the the final word on what certificate is valid and what is not lies with the CA... > For this reason I need some additional information, my > question was about the presence of a standard describing > where to store them onto LDAP and if, to you, it could be > better storing them on a per certificate basis or in a single > entry in the main organization entry. The latter describes a CRL... > [ unknown ] > > No. There is an unclear wording in RFC2560 that might lead the > > thoughts in that direction. "unknown" means that the OCSP > is unable or > > unwilling to answer the revocation query (because it > doesn't know the > > CA, or because it doesn't have up to date revocation information or > > whatever). A logical reaction to an "unknown" response is to go to > > some other OCSP responder that might be better connected for the > > moment. If you confuse the meaning of "unknown" to be an assertion > > (that the certificate was indeed never issued) then that > availability > > feature breaks down (at least if you have the wrong kind of > client). > > The OCSPv2 draft has a better wording. > > Quoting the RFC2560 << The "unknown" state indicates that the > responder doesn't know about the certificate being requested. > >>. I was not saying that the "unknown" means that the > certificate has never being issued, anyway how could the > responder know which certificates have been issued ? In this > case the responder can';t be sure about the validity of a > certificate and it should, to me at least, therefore return > an "unknown" status. This was not the intention, and the text has been refrased for the draft of OCSPv2: " This specification defines the following definitive response indicators for use in the certificate status value: -- good -- revoked -- unknown The "good" state indicates that the certificate has not been revoked. It does not indicate that the certificate was ever issued, or is in its validity interval. The "revoked" state indicates that the certificate has been revoked (either permanently or temporarily (on hold)). The "unknown" state indicates that the responder does not know, or is unwilling to tell, the requestor the status of the certificate. A client may be able to get a definitive response later, or at another responder. Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate such as positive statement about issuance, expiry, etc. " >From this is it is quite clear that the base query is about revocation, and that the answer to the question "has this neverissued certificate been revoked?" is "no". The interpretation you are suggesting has been discussed before at great length in this group, and I hesitate to regurgitate it. However, it is possible to put a question (and corresponding answer) about issuance into an extension. The question is possibly, why? What risk is it you are trying to cover for? And, is there perhaps already another, less magic, mechanism to handle it? > Because of these considerations I think the OCSP reponder > needs additional data besides the only CRL(s), although I > know that this is a fast way of having it working but this > works only when the CRLs are immediately (in the same second) > issued after certificate revocation and this does not work in > environment when some human interaction (for example verification). > > It seems, to me, just translating the CRLs in another format > without adding a real improvement to the validating > process... I think the OCSP to be more useful than this. Adding is ok, but altering is a no-no. If different implementors have different interpretations of the base query, then clients and servers from different vendors will not interoperate. Simon Simon Tardell, cell +46 70 3198319, simon@tardell.se From owner-ietf-pkix Tue Jan 7 05:33:22 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07DXME22527 for ietf-pkix-bks; Tue, 7 Jan 2003 05:33:22 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07DXLo22520 for ; Tue, 7 Jan 2003 05:33:21 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12281; Tue, 7 Jan 2003 08:30:05 -0500 (EST) Message-Id: <200301071330.IAA12281@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-scvp-11.txt Date: Tue, 07 Jan 2003 08:30:05 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Simple Certificate Validation Protocol (SCVP) Author(s) : A. Malpani, R. Housley, T. Freeman Filename : draft-ietf-pkix-scvp-11.txt Pages : 47 Date : 2003-1-6 SCVP allows a client to offload certificate handling to a server. The server can provide the client with a variety of valuable information about the certificate, such as whether the certificate is valid, a certification path to a trust anchor, and revocation status. SCVP has many purposes, including simplifying client implementations and allowing companies to centralize trust and policy management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-scvp-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-scvp-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-6145458.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-scvp-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-scvp-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-6145458.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Tue Jan 7 05:42:52 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07Dgq123637 for ietf-pkix-bks; Tue, 7 Jan 2003 05:42:52 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07Dgpo23631 for ; Tue, 7 Jan 2003 05:42:51 -0800 (PST) Subject: Re: OCSP and LDAP To: "Anders Rundgren" Cc: "Ambarish Malpani" , "IETF PKIX" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Tue, 7 Jan 2003 06:42:20 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/07/2003 08:44:46 AM 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: as been mentioned before ... it is relatively simple to see the information in certificates as form of distributed read/only cache entries ... with lots of similarities to cpu caches, database caches, filesystem caches, distributed/network databases, distributed/network filesystems, etc. the data in the certificates is stale by defintion ... if it wasn't ... it wouldn't be necessary to have an OCSP that basically is asking if it is too stale. some ten plus years ago i was at a acm sigmod conference and asked somebody what this x.500 stuff was ... and was told it is a bunch of networking types trying to re-invent 1960s database technology. random past refs: http://www.garlic.com/~lynn/aadsmore.htm#time Certifiedtime.com http://www.garlic.com/~lynn/aadsm5.htm#faith faith-based security and kinds of trust http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI) http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication http://www.garlic.com/~lynn/aepay4.htm#visaset2 Visa Delicately Gives Hook to SET Standard http://www.garlic.com/~lynn/aepay6.htm#crlwork do CRL's actually work? http://www.garlic.com/~lynn/aepay10.htm#77 Invisible Ink, E-signatures slow to broadly catch on (addenda) http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site. http://www.garlic.com/~lynn/2001e.html#43 Can I create my own SSL key? -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm From owner-ietf-pkix Tue Jan 7 05:33:17 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07DXHQ22510 for ietf-pkix-bks; Tue, 7 Jan 2003 05:33:17 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07DXGo22502 for ; Tue, 7 Jan 2003 05:33:16 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12262; Tue, 7 Jan 2003 08:29:59 -0500 (EST) Message-Id: <200301071329.IAA12262@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ecc-nist-recommended-curves-00.txt Date: Tue, 07 Jan 2003 08:29:59 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : NIST Recommended EC Domain Parameters For PKIX Author(s) : D. Brown Filename : draft-ietf-pkix-ecc-nist-recommended-curves-00.txt Pages : 5 Date : 2003-1-6 This document gives the object identifiers for the elliptic curve domain pararmeters that the National Institute of Standards and Techology recommends in its publication 'Digital Signature Standard A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-nist-recommended-curves-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ecc-nist-recommended-curves-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ecc-nist-recommended-curves-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-6145449.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ecc-nist-recommended-curves-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ecc-nist-recommended-curves-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-6145449.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Tue Jan 7 05:33:11 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07DXBg22495 for ietf-pkix-bks; Tue, 7 Jan 2003 05:33:11 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07DXAo22491 for ; Tue, 7 Jan 2003 05:33:10 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12242; Tue, 7 Jan 2003 08:29:53 -0500 (EST) Message-Id: <200301071329.IAA12242@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-rsa-pkalgs-00.txt Date: Tue, 07 Jan 2003 08:29:53 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Author(s) : R. Housley, B. Kaliski Filename : draft-ietf-pkix-rsa-pkalgs-00.txt Pages : 22 Date : 2003-1-6 This document supplements RFC 3279. It describes the conventions for using the RSASSA-PSS signature algorithm, the RSAES-OAEP key transport algorithm, and additional one-way hash functions with the PKCS #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-rsa-pkalgs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-rsa-pkalgs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-6145441.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-rsa-pkalgs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-rsa-pkalgs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-6145441.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Tue Jan 7 05:33:28 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07DXSr22544 for ietf-pkix-bks; Tue, 7 Jan 2003 05:33:28 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07DXRo22540 for ; Tue, 7 Jan 2003 05:33:27 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12313; Tue, 7 Jan 2003 08:30:11 -0500 (EST) Message-Id: <200301071330.IAA12313@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-warranty-extn-02.txt Date: Tue, 07 Jan 2003 08:30:11 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Warranty Certificate Extension Author(s) : D. Linsenbardt, S. Pontius, A. Sturgeon Filename : draft-ietf-pkix-warranty-extn-02.txt Pages : 7 Date : 2003-1-6 This document describes a certificate extension to explicitly state the warranty offered by a Certificate Authority (CA) for a the certificate containing the extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-warranty-extn-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-warranty-extn-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-6145507.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-warranty-extn-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-warranty-extn-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-6145507.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Tue Jan 7 07:13:19 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07FDJD02970 for ietf-pkix-bks; Tue, 7 Jan 2003 07:13:19 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07FDGo02965 for ; Tue, 7 Jan 2003 07:13:16 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h07FDCOd008966 for ; Tue, 7 Jan 2003 10:13:12 -0500 Received: from d01hub03.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h07FCxLN131872 for ; Tue, 7 Jan 2003 10:13:10 -0500 In-Reply-To: <5.2.0.9.2.20030106162604.02959a38@mail.binhost.com> To: ietf-pkix@imc.org MIME-Version: 1.0 Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option) X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Timothy Hahn X-MIMETrack: S/MIME Sign by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/07/2003 08:34:32 AM, Serialize by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/07/2003 08:34:32 AM, Serialize complete at 01/07/2003 08:34:33 AM, Itemize by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/07/2003 08:34:33 AM, S/MIME Sign complete at 01/07/2003 08:34:33 AM, S/MIME Sign by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/07/2003 08:40:14 AM, S/MIME Sign complete at 01/07/2003 08:40:14 AM, MIME-CD by Router on D01MLC96/01/M/IBM(Build V601_12152002 SPR MIAS5GXKFV CBOD5GVRDB|December 20, 2002) at 01/07/2003 10:13:00, MIME-CD complete at 01/07/2003 10:13:00, Serialize by Router on D01HUB03/01/H/IBM(Release 6.0 [IBM]|December 22, 2002) at 01/07/2003 10:13:10 Message-ID: Date: Tue, 7 Jan 2003 08:40:13 -0500 Content-type: multipart/mixed; Boundary="0__=0ABBE634DFDA282D8f9e8a93df938690918c0ABBE634DFDA282D" Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --0__=0ABBE634DFDA282D8f9e8a93df938690918c0ABBE634DFDA282D Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Russ, Great question. =A0Simply - it gives the "client" the opportunity to establish whether or not it can or cannot support retrieval of the information from that data source (directory sub-tree). =A0Client and s= erver implementations choose which protocols and data models they're going to= "support" all the time. =A0As long as both support the same model(s), t= hen they interoperate. =A0My proposal is that we define one way to identify= which data model(s) is(are) employed, so that servers and clients can determi= ne whether they are capable of supporting the formats. =A0If they are not capable, they can gracefully fail. The client can be made as "fat" or as "lean" as the implementer wants, because the implementer can decide which formats to support. =A0If the implementer decides to support one while another part of the industry t= ends to support another - well, then that particular implementation will get= "fatter" because it will wind up supporting both. My premise is that there is not a single data model that "fits" for ALL= applications/deployments. =A0And because of that, multiple data models = can and will (in real-world scenarios) exist. =A0So why not accept this, de= fine a (singular) way of identifying which model is used, and move on. =A0At l= east in this way, if a particular implementation/application has a need to s= tore things in a different way, it can, and we can still hope for interoperability through IETF documents. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Durham/IBM@IBMUS phone: 919.224.1565 =A0 =A0 tie-line: 8/687.1565 fax: 919.224.2540 |+-----------------------+---------------------------------------------= ---| || Russ Housley | = | || | Hahn/Durham/IBM@IBMUS = | || | =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0ietf-pk= ix@imc.org | || 01/06/2003 04:28 PM | =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0Re= : LDAP PKI Schema | || | (was Re: No-op LDAP ;binary option) = | || | = | || | = | |+-----------------------+---------------------------------------------= ---| Tim: I do not understand how a client is better off with multiple ways to pu= t the same information in the Directory. =A0Doesn't this approach just ma= ke the client fat? =A0It seem to me that the client would have to support all = of the possible ways that the information could be stored. =A0It cannot know w= hich method it will encounter until it starts looking at data in the Directo= ry. Russ At 03:14 PM 1/6/2003 -0500, Timothy Hahn wrote: >Hello all, > >After listening to the different view-points on this topic, it seems t= o me >that there are multiple valid approaches. =A0These approaches include,= but >are not limited to: > =A0 - leveraging the general solution of component-matching > =A0 - new schema to support application-managed componentization of >information to make things searchable >as well as others (additional matching rules, for example). > >It occurs to me that perhaps we have a situation where "one size does = not >fit all". =A0Why not accept this and define a way for applications to >determine which (of possibly multiple) format(s) has been used to plac= e the >information into the directory? =A0We could define some small bit of s= chema >which indicates the way in which the certificate information is placed= into >the directory, then different applications could query this and determ= ine: > =A0 - whether they can use the data at all > =A0 - if they can use the data, how they can best use it (if there ar= e, for >example, multiple mechanisms employed). > >Just a thought to get us through this discussion. > >Regards, >Tim Hahn = --0__=0ABBE634DFDA282D8f9e8a93df938690918c0ABBE634DFDA282D Content-type: application/octet-stream; name="=?ISO-8859-1?Q?smime=2Ep7s?=" Content-Disposition: attachment; filename="=?ISO-8859-1?Q?smime=2Ep7s?=" Content-transfer-encoding: base64 MIAGCSqGSIb3DQEHAqCAMIIULwIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISUDCCAtow ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1 aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf 1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117 ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r 1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0 MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf 1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn 00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMiMIIC i6ADAgECAgJONTANBgkqhkiG9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJu YXRpb25hbCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MB4XDTAyMTEyMTEzMDY1M1oXDTAzMTIwNTEzMDY1M1owgYQxCzAJ BgNVBAYTAlVTMQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRgwFgYDVQQDEw9UaW1v dGh5IEouIEhhaG4xGTAXBgoJkiaJk/IsZAEBEwkxMjg4NTc4OTcxHzAdBgkqhkiG9w0BCQEWEGhh aG50QHVzLmlibS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMZRHQYCNd56O2LkRqmV bpvr70BMnmNf+UWqMbgJ0v8Y5Vb3hdrThAoyNs3XKbFl9oYir3AFiZHVPUpFM2anK8+Sb9IqzfIh g/x6Tu9wVHPXkve+wBCGneHD2GgvIx7NEECdr7YuOd7SWevXcLloLu3yQ7Hb2aZ1MQ8o78M9S7K1 AgMBAAGjgbwwgbkwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQU z9GrkTcJqnyWERTvptgBPQmzC/QwKwYDVR0RBCQwIqAgBgorBgEEAYI3FAIDoBIMEGhhaG50QHVz LmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7zSkAwJwYDVR0lBCAwHgYIKwYB BQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0BAQQFAAOBgQCHcqGsmuSPRftlK36s f5HfVXRhzCbH63xR5jLTpzFIfzoNo8u8yeC2yu81Ylj3rLzKmcwNtb9rkQT+wqWJH498ECe66dOQ 6tUDHk3VYGYZ3QrerjTBWBnKoekfUMcp+9xtjsHYVfMEopW/0FU6QsMwj3vouSy6Uv5nTGxKIi73 ZzCCAyIwggKLoAMCAQICAk41MA0GCSqGSIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQK EytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJ Qk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDIxMTIxMTMwNjUzWhcNMDMxMjA1MTMwNjUz WjCBhDELMAkGA1UEBhMCVVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxGDAWBgNV BAMTD1RpbW90aHkgSi4gSGFobjEZMBcGCgmSJomT8ixkAQETCTEyODg1Nzg5NzEfMB0GCSqGSIb3 DQEJARYQaGFobnRAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxlEdBgI1 3no7YuRGqZVum+vvQEyeY1/5RaoxuAnS/xjlVveF2tOECjI2zdcpsWX2hiKvcAWJkdU9SkUzZqcr z5Jv0irN8iGD/HpO73BUc9eS977AEIad4cPYaC8jHs0QQJ2vti453tJZ69dwuWgu7fJDsdvZpnUx Dyjvwz1LsrUCAwEAAaOBvDCBuTARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G A1UdDgQWBBTP0auRNwmqfJYRFO+m2AE9CbML9DArBgNVHREEJDAioCAGCisGAQQBgjcUAgOgEgwQ aGFobnRAdXMuaWJtLmNvbTAfBgNVHSMEGDAWgBSuVA6S6qgzqSskLcfIbzDc3vNKQDAnBgNVHSUE IDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBAIdyoaya 5I9F+2Urfqx/kd9VdGHMJsfrfFHmMtOnMUh/Og2jy7zJ4LbK7zViWPesvMqZzA21v2uRBP7CpYkf j3wQJ7rp05Dq1QMeTdVgZhndCt6uNMFYGcqh6R9Qxyn73G2OwdhV8wSilb/QVTpCwzCPe+i5LLpS /mdMbEoiLvdnMYIBujCCAbYCAQEwbzBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRp b25hbCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5AgJONTAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDEwNzEzMzQzM1owIwYJKoZIhvcNAQkEMRYEFJp9BPP8kHRW uPbyKiAViU9+VAEfMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcNAwICAgCAMAoG CCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGACvwBO2mZ9klb4VTwcMK4 AorPvtztACgs80jrAKSwy8ULcOH9XxhhRmKOYvO8RxrPORVdWOkU/of3DxjXslsgD1JtuGWuSacb KFF4YNecGqD9dEQgmeqxI6yi4cXIgD439SB/Oti+KBLrgpyHgH5usZOUpvORb5KjOu5UX1ff0McA AAAA --0__=0ABBE634DFDA282D8f9e8a93df938690918c0ABBE634DFDA282D-- From owner-ietf-pkix Tue Jan 7 09:50:57 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07Hovj13571 for ietf-pkix-bks; Tue, 7 Jan 2003 09:50:57 -0800 (PST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07Hoto13564 for ; Tue, 7 Jan 2003 09:50:55 -0800 (PST) Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26556; Tue, 7 Jan 2003 09:50:52 -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 h07HopQ28086; Tue, 7 Jan 2003 12:50:51 -0500 (EST) Message-ID: <3E1B1330.C826AEB7@sun.com> Date: Tue, 07 Jan 2003 12:49:36 -0500 From: Steve Hanna X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Santosh Chokhani CC: PKIX List Subject: Re: Offline Root CA with valid CRL hierachie References: <000e01c2b366$bbed4380$5b845b0c@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 don't think we disagree substantially. We discussed a few different ways to provide timely revocation with an offline CA, pointing out some of the pros and cons of each technique. We may not agree on which technique is best, but ultimately that's up to the CA operator. -Steve Santosh Chokhani wrote: > > 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 Tue Jan 7 17:15:44 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h081Fio09619 for ietf-pkix-bks; Tue, 7 Jan 2003 17:15:44 -0800 (PST) Received: from smtp2.mivlmd.cablespeed.com (smtp2.mivlmd.cablespeed.com [24.35.0.19] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id h081Fho09615 for ; Tue, 7 Jan 2003 17:15:43 -0800 (PST) Received: (qmail 14938 invoked by uid 0); 8 Jan 2003 01:15:10 -0000 Received: from unknown (HELO cablespeed.com) (216.45.82.31) by 0 with SMTP; 8 Jan 2003 01:15:10 -0000 Message-ID: <3E1B7BB6.507@cablespeed.com> Date: Tue, 07 Jan 2003 20:15:34 -0500 From: jim User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (nscd2) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Onus on Registration Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Does anyone have any sample PK installation that they know of where the onus for registration was placed on the relying party using organizational certificates. There is a chance that an organization will undertake such a path and I have been asked to find out if anyone else has done it. Jim Heimberg, ABC, Ph.D. From owner-ietf-pkix Tue Jan 7 21:53:18 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h085rIi16554 for ietf-pkix-bks; Tue, 7 Jan 2003 21:53:18 -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 h085rFo16550 for ; Tue, 7 Jan 2003 21:53:16 -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 h085qfvv007227; Wed, 8 Jan 2003 18:52:41 +1300 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h085qeA28408; Wed, 8 Jan 2003 18:52:40 +1300 Date: Wed, 8 Jan 2003 18:52:40 +1300 Message-Id: <200301080552.h085qeA28408@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: anders.rundgren@telia.com, lynn.wheeler@firstdata.com Subject: Re: OCSP and LDAP Cc: ambarish@malpani.biz, ietf-pkix@imc.org Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: lynn.wheeler@firstdata.com writes: >some ten plus years ago i was at a acm sigmod conference and asked somebody >what this x.500 stuff was ... and was told it is a bunch of networking types >trying to re-invent 1960s database technology. I've used that explanation too :-). The conversion went something like this: Other person: "Why is X.500 so special? Why is no-one else doing this?" Me: "Get your favourite book on database technology and look up 'Hierarchical databases'". [Time passes] Other person: "I looked in several books. Many didn't mention it at all, and one had a half-page historical note saying it's something that was obsoleted by better technology more than two decades ago". Me: "Exactly". Peter. From owner-ietf-pkix Wed Jan 8 02:08:30 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h08A8UZ17645 for ietf-pkix-bks; Wed, 8 Jan 2003 02:08:30 -0800 (PST) Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h08A8To17639 for ; Wed, 8 Jan 2003 02:08:29 -0800 (PST) Received: from f67j40j ([213.106.136.127]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20030108100826.NZCK4699.mta03-svc.ntlworld.com@f67j40j> for ; Wed, 8 Jan 2003 10:08:26 +0000 From: "Marc Poulaud" To: Subject: RE: Onus on Registration Date: Wed, 8 Jan 2003 10:08:12 -0000 MIME-Version: 1.0 Message-ID: Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0029_01C2B6FD.D81F3460" 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 V6.00.2800.1106 Importance: Normal In-Reply-To: <3E1B7BB6.507@cablespeed.com> 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_0029_01C2B6FD.D81F3460 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jim, Can you give some more details as to what you mean exactly. The scheme known as Identrus requires an RP to register (a customer agreement and certificate requests) for what amounts to an organi[sz]ational certificate. This is partly to do with participating in a closed scheme but also to use the org certificate for signing validation requests (of a subscribing customer's certificate) to its financial institution. Marc. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of jim Sent: 08 January 2003 01:16 To: ietf-pkix@imc.org Subject: Onus on Registration Does anyone have any sample PK installation that they know of where the onus for registration was placed on the relying party using organizational certificates. There is a chance that an organization will undertake such a path and I have been asked to find out if anyone else has done it. Jim Heimberg, ABC, Ph.D. ------=_NextPart_000_0029_01C2B6FD.D81F3460 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKITCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1 E3LnQDGa07LEq+dWvovj+xUwggR2MIID36ADAgECAhB/l4yg+FrgmGLkay+Z3cRwMA0GCSqGSIb3 DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMTAwNzAwMDAw MFoXDTAzMTAwNzIzNTk1OVowggEaMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs bCBTZXJ2aWNlMRUwEwYDVQQDFAxNYXJjIFBvdWxhdWQxKTAnBgkqhkiG9w0BCQEWGm1hcmMucG91 bGF1ZEBpLXNvbHZlLmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDfd3CCaom3tU0P mdCz0ggSdD8UNJMSVDPou1CJjsLvYpwUySsSQgUdYdFjvQmheBDL2z0T3dX1mvce5WJrDg5fcWQG aUmQbubJ0qxdK5uT4IkNJx9s1PPDfOEj4PdJExyyG0Cbsvwo8Wyq+xnRlCcMzwm4D/XNnXqkrEZw MifX+wIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcC AjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVm ZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAh/j3ynKibKwqRZA4Y3KsDwboqp78AIi04ATWtK0MSq+qL2FIu7HORZrN9eJVwqkm 3lr4tNU/ld7bCqnd9zHO4FRyg17pDVwZ4/7Z3UR+wW6WLj2FXn+QPRPWuyeIpOz+LxPhn4HaBIS6 qaO6+glnQl0IX6axcAhLebO/J/hNIQAxggNWMIIDUgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv bmEgTm90IFZhbGlkYXRlZAIQf5eMoPha4Jhi5Gsvmd3EcDAJBgUrDgMCGgUAoIIByjAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMDgxMDA4MDhaMCMGCSqGSIb3 DQEJBDEWBBSyQfhoGTxzsg3+W6xJZmPb9gvvhjB2BgkqhkiG9w0BCQ8xaTBnMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjAHBgUrDgMCGjAKBggqhkiG9w0CBTAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHM MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhB/l4yg+FrgmGLkay+Z3cRwMA0GCSqG SIb3DQEBAQUABIGAoVNTTFRCWyq/UOsrspfjA4Fc0uU657crtzogg3eJ9E2DfTWApXYVSWV27H7F SVma59tTEyJpgxJEsNKFhVlFP/Iu8EUkjiSz1RiwHhuuOD58GncJpBV3wEyfc88mglVYIwoEmMAW 4zdUKLUeoYxP6/nZQ53hy49ZP0DQ3rgBsYMAAAAAAAA= ------=_NextPart_000_0029_01C2B6FD.D81F3460-- From owner-ietf-pkix Wed Jan 8 04:37:43 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h08CbhT29819 for ietf-pkix-bks; Wed, 8 Jan 2003 04:37:43 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h08Cbfo29815 for ; Wed, 8 Jan 2003 04:37:41 -0800 (PST) Subject: Re: OCSP and LDAP To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: ambarish@malpani.biz, anders.rundgren@telia.com, ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Wed, 8 Jan 2003 05:37:17 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/08/2003 07:39:35 AM 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: on the other hand ... there some book someplace that makes the claim that relational set the state-of-the-art back 20 years. I was somewhat involved having done some support infrastructure for system/r and then involved in the technology transfer of system/r from sjr to endicott for sql/ds (before the technology transfer back from endicott to stl for db2 .... note that SJR/bld28 & STL/bld90 are like 10 miles apart .... with both SRJ/STL on the west coast and endicott nearly on the east coast). slightly related: http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 some archeological tales: http://www.garlic.com/~lynn/2000.html#18 Computer of the century http://www.garlic.com/~lynn/2000b.html#29 20th March 2000 http://www.garlic.com/~lynn/2000b.html#55 Multics dual-page-size scheme http://www.garlic.com/~lynn/2000e.html#49 How did Oracle get started? http://www.garlic.com/~lynn/2001d.html#44 IBM was/is: Imitation... http://www.garlic.com/~lynn/2001k.html#5 OT - Internet Explorer V6.0 http://www.garlic.com/~lynn/2002.html#10 index searching http://www.garlic.com/~lynn/2002e.html#44 SQL wildcard origins? http://www.garlic.com/~lynn/2002g.html#60 Amiga Rexx http://www.garlic.com/~lynn/2002h.html#17 disk write caching (was: ibm icecube -- return of http://www.garlic.com/~lynn/2002i.html#69 Hercules and System/390 - do we need it? http://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends http://www.garlic.com/~lynn/2002k.html#9 Avoiding JCL Space Abends http://www.garlic.com/~lynn/2002l.html#71 Faster seeks (was Re: Do any architectures use instruction http://www.garlic.com/~lynn/2002n.html#36 VR vs. Portable Computing http://www.garlic.com/~lynn/2002o.html#54 XML, AI, Cyc, psych, and literature http://www.garlic.com/~lynn/2002q.html#32 Collating on the S/360-2540 card reader? -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm ptut001@cs.auckland.ac.nz on 1/7/2003 10:52 pm wrote: I've used that explanation too :-). The conversion went something like this: Other person: "Why is X.500 so special? Why is no-one else doing this?" Me: "Get your favourite book on database technology and look up 'Hierarchical databases'". [Time passes] Other person: "I looked in several books. Many didn't mention it at all, and one had a half-page historical note saying it's something that was obsoleted by better technology more than two decades ago". Me: "Exactly". Peter. From owner-ietf-pkix Wed Jan 8 04:57:00 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h08Cv0k00687 for ietf-pkix-bks; Wed, 8 Jan 2003 04:57:00 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h08Cuwo00683 for ; Wed, 8 Jan 2003 04:56:59 -0800 (PST) Subject: Re: OCSP and LDAP To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: ambarish@malpani.biz, anders.rundgren@telia.com, ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Wed, 8 Jan 2003 05:51:10 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/08/2003 07:58:52 AM 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: total trivia: from the previous aadsm5 references to: http://www.garlic.com/~lynn/95.html#13 two of the people in the conference room went on to the small client/server startup involved in this thing called SSL & HTTPS ... one had been involved in the tech. transfer from SJR to Endicott for SQL/DS and one had been involved in the tech transfer from Endicott to STL for DB2. Of all the people in the meeting .... I believe only one is still working for the same employer they were then ... and that case isn't exactly considered employee ... most recently there has been some stuff about him getting ready to compete with some sailing team from "down under". -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm From owner-ietf-pkix Wed Jan 8 08:49:39 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h08FwDb10161 for ietf-pkix-bks; Wed, 8 Jan 2003 07:58:13 -0800 (PST) Received: from mail.inka.de (mail@quechua.inka.de [193.197.184.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h08FwBo10156 for ; Wed, 8 Jan 2003 07:58:12 -0800 (PST) Received: from nb2.stroeder.com (puric.inka.de [193.197.184.17]) by mail.inka.de with esmtp id 18WIal-0005cP-00; Wed, 08 Jan 2003 16:58:07 +0100 Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id B7CF039426; Wed, 8 Jan 2003 16:58:05 +0100 (CET) Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 92DCF3480A; Wed, 8 Jan 2003 16:58:04 +0100 (CET) Message-ID: <3E1C4A8C.8070307@stroeder.com> Date: Wed, 08 Jan 2003 16:58:04 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Peter Gutmann Cc: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-03.txt References: <200301040132.h041W2719281@medusa01.cs.auckland.ac.nz> In-Reply-To: <200301040132.h041W2719281@medusa01.cs.auckland.ac.nz> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter Gutmann wrote: > > 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. Which is perfectly right since the draft specifies a simple query interface and (hopefully) nothing else. Ciao, Michael. From owner-ietf-pkix Wed Jan 8 12:02:01 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h08K21G16855 for ietf-pkix-bks; Wed, 8 Jan 2003 12:02:01 -0800 (PST) Received: from smtp-2.llnl.gov (smtp-2.llnl.gov [128.115.250.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h08K20o16851 for ; Wed, 8 Jan 2003 12:02:00 -0800 (PST) Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-2.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id MAA03623; Wed, 8 Jan 2003 12:00:58 -0800 (PST) Received: from [128.115.222.68] (HELO catalyst2b.llnl.gov) by poptop.llnl.gov (CommuniGate Pro SMTP 3.5.9) with ESMTP id 8842067; Wed, 08 Jan 2003 12:01:01 -0800 Message-Id: <5.0.0.25.2.20030108115433.03d32ca8@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 08 Jan 2003 12:01:44 -0800 To: pgut001@cs.auckland.ac.nz (Peter Gutmann), anders.rundgren@telia.com, lynn.wheeler@firstdata.com From: Tony Bartoletti Subject: Re: OCSP and LDAP Cc: ambarish@malpani.biz, ietf-pkix@imc.org In-Reply-To: <200301080552.h085qeA28408@medusa01.cs.auckland.ac.nz> 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: At 06:52 PM 1/8/2003 +1300, Peter Gutmann wrote: >Other person: "Why is X.500 so special? Why is no-one else doing this?" > >Me: "Get your favourite book on database technology and look up > 'Hierarchical databases'". > >[Time passes] > >Other person: "I looked in several books. Many didn't mention it at all, > and one had a half-page historical note saying it's something > that was obsoleted by better technology more than two decades > ago". > >Me: "Exactly". Heh. Actually, hierarchical databases can be superlative to most all other technologies, when one has a static taxonomy to support. Trying to represent (no less manage) a dynamically changing global namespace with scores of independent geopolitical naming authorities with a hierarchical database is rather ... ridiculous. :) Cheers! ____tony____ From owner-ietf-pkix Wed Jan 8 13:01:47 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h08L1lc18580 for ietf-pkix-bks; Wed, 8 Jan 2003 13:01:47 -0800 (PST) Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h08L1ho18574 for ; Wed, 8 Jan 2003 13:01:44 -0800 (PST) Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by maild.telia.com (8.12.5/8.12.5) with SMTP id h08L14UU018997; Wed, 8 Jan 2003 22:01:05 +0100 (CET) X-Original-Recipient: ietf-pkix@imc.org Message-ID: <011e01c2b758$c94e9290$0500a8c0@arport> From: "Anders Rundgren" To: "Peter Gutmann" , , "Tony Bartoletti" Cc: , References: <5.0.0.25.2.20030108115433.03d32ca8@poptop.llnl.gov> Subject: Re: OCSP and LDAP Date: Wed, 8 Jan 2003 21:58:56 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011B_01C2B761.24499CF0" 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_011B_01C2B761.24499CF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >Heh. Actually, hierarchical databases can be superlative to most all = other=20 >technologies, when one has a static taxonomy to support. Trying to=20 >represent (no less manage) a dynamically changing global namespace with = >scores of independent geopolitical naming authorities with a = hierarchical=20 >database is rather ... ridiculous. :) Tony, You are right! You may be pleased to know that a remedy is in = preparation in the form of an I-D where the following extract addresses the = situation mentioned. /Anders Plug-and-Play Certificates for Web Services 1. Introduction and rationale To combine PKI with "Web Services" on a global scale presents a challenge, as it requires Relying Parties (RPs) to process signed messages possibly emanating from many different PKIs, while preferably using a unified RP PKI software- and user-interface. In the web-browser environment, global interoperability is only achieved due to the fact that web-server certificates supporting HTTPS [6], are based on a static ("hard-coded") profile [7], which is a prerequisite by browsers to correctly interpret such certificates. To further simplify usage, most commercial CAs' root-certificates are already pre-installed in leading browsers. However, "Web Services" can unlike web-browsers, not depend on static PKI-schemes and pre-installed root-certificates, as this would severely limit the kind of entity-types and certificate- profiles that would be possible for RPs to accept. This specification introduces a CA-certificate-based, non-critical X.509 v3 extension, from now on referred to as a "PnP-descriptor", that works like an additional "specification" for associated End Entity (EE)-certificates. The following introductory sections describe how this extension can support a more dynamic PKI-based ecosystem, by removing some major hurdles to wide-scale PKI usage. 1.1 Globally unique subject DNs The aforementioned Web-server certificates, contain globally unique subject Distinguished Names (DNs) [8] due to the fact that they certify Domain Name System (DNS) [9] host-names. However, for non-DNS-based entities, few existing certificate- profiles as well as RFC3280 [10] and RFC3039 [11] require subject DNs to be globally unique. This may lead to possible name-clashes when multiple non-coordinated PKIs are to be handled by RPs. One way to cope with this is to associate each CA-certificate with a unique "virtual" name-space. This complicates CA-certificate renewals with respect to RPs, as well as making it more difficult to efficiently explore common certificate-profiles and associated naming-domains shared by multiple CAs (exemplified by many national ID-schemes), as both these scenarios require manual and error-prone RP configuration to work. Requiring CAs to deploy globally unique subject DNs by for example adding Domain Components (DCs) [8] is likely to be less popular, as well as breaking some existing RP software. The PnP-descriptor therefore supports an explicit naming-domain in the form of a Universal Resource Identifier (URI) [12]. Due to the two-level naming structure, the PnP-descriptor provides global uniqueness to any existing or future non-empty subject DN scheme. Below is a figure, illustrating the two-level naming system. ____ / \ | CA |<--- PnP Naming domain: \____/ http://www.sampleregistry.org/members / \ / \ | _\__ | / \ | | EE | CN=3DJohn Doe, serialNumber=3D43155, C=3DUS | \____/ | _|__ / \ | EE | CN=3DMarion Anderson, serialNumber=3D43566, C=3DUS \____/ That is, Marion's fully canonicalized name could be expressed like "http://www.sampleregistry.org/members" : "CN=3DMarion Anderson, serialNumber=3D43566, C=3DUS" Note: Canonicalization syntax is outside of this specification as it is mostly a disadvantage to merge naming domain and subject DN in a real application. ------=_NextPart_000_011B_01C2B761.24499CF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>Heh.  Actually, hierarchical = databases can=20 be superlative to most all other
>technologies, when one has a = static=20 taxonomy to support.  Trying to
>represent (no less manage) = a=20 dynamically changing global namespace with
>scores of independent = geopolitical naming authorities with a hierarchical
>database is = rather=20 ... ridiculous. :)
 
Tony,
You are right!  You may be pleased = to know=20 that a remedy is in preparation
in the form of an I-D where the = following extract=20 addresses the situation mentioned.
/Anders
          &nbs= p;  =20 Plug-and-Play Certificates for Web Services
 
1. Introduction and = rationale
 
   To combine PKI = with "Web=20 Services" on a global scale presents a
   challenge, as it = requires=20 Relying Parties (RPs) to process signed
   messages = possibly=20 emanating from many different PKIs, while
   preferably = using a=20 unified RP PKI software- and user-interface.
   In the = web-browser=20 environment, global interoperability is only
   achieved = due to the=20 fact that web-server certificates supporting
   HTTPS [6], = are=20 based on a static ("hard-coded") profile [7],
   which is a = prerequisite by browsers to correctly interpret such
  =20 certificates.  To further simplify usage, most commercial=20 CAs'
   root-certificates are already pre-installed in = leading=20 browsers.
 
   However, "Web = Services" can=20 unlike web-browsers, not depend on
   static PKI-schemes = and=20 pre-installed root-certificates, as this
   would severely = limit=20 the kind of entity-types and certificate-
   profiles that = would be=20 possible for RPs to accept.
 
   This specification = introduces=20 a CA-certificate-based, non-critical
   X.509 v3 extension, = from=20 now on referred to as a "PnP-descriptor",
   that works = like an=20 additional "specification" for associated End
   Entity=20 (EE)-certificates.  The following introductory = sections
  =20 describe how this extension can support a more dynamic = PKI-based
  =20 ecosystem, by removing some major hurdles to wide-scale PKI = usage.
 
1.1 Globally unique subject=20 DNs
 
   The aforementioned = Web-server=20 certificates, contain globally unique
   subject = Distinguished=20 Names (DNs) [8] due to the fact that they
   certify Domain = Name=20 System (DNS) [9] host-names.
 
   However, for = non-DNS-based=20 entities, few existing certificate-
   profiles as well as = RFC3280=20 [10] and RFC3039 [11] require subject
   DNs to be globally = unique.  This may lead to possible name-clashes
   = when=20 multiple non-coordinated PKIs are to be handled by RPs. =20 One
   way to cope with this is to associate each = CA-certificate=20 with a
   unique "virtual" name-space.  This = complicates=20 CA-certificate
   renewals with respect to RPs, as well as = making=20 it more difficult to
   efficiently explore common=20 certificate-profiles and associated
   naming-domains = shared by=20 multiple CAs (exemplified by many national
   ID-schemes), = as both=20 these scenarios require manual and error-prone
   RP = configuration=20 to work.  Requiring CAs to deploy globally unique
   = subject=20 DNs by for example adding Domain Components (DCs) [8] is
   = likely=20 to be less popular, as well as breaking some existing RP
   = software.

   The = PnP-descriptor=20 therefore supports an explicit naming-domain in
   the form = of a=20 Universal Resource Identifier (URI) [12]. Due to the
   = two-level=20 naming structure, the PnP-descriptor provides global
   = uniqueness=20 to any existing or future non-empty subject DN scheme.
   = Below is=20 a figure, illustrating the two-level naming=20 system.
          &n= bsp; =20 ____
           = ;=20 /   =20 \
           = | =20 CA  |<--- PnP Naming=20 domain:
          &n= bsp;=20 \____/      http://www.sampleregistry.org/members
          &nbs= p;=20 /   =20 \
          =20 /     =20 \
         =20 |      =20 _\__
         =20 |      /   =20 \
         =20 |     |  EE  | CN=3DJohn Doe, = serialNumber=3D43155,=20 C=3DUS
         =20 |     =20 \____/
         =20 |
        =20 _|__
        /   =20 \
       |  EE  | CN=3DMarion = Anderson,=20 serialNumber=3D43566, = C=3DUS
       =20 \____/
 
   That is, Marion's = fully=20 canonicalized name could be expressed like
 
      =20 "http://www.sampleregistry.org/members" :
       "CN=3DMarion = Anderson,=20 serialNumber=3D43566, C=3DUS"
 
   Note: = Canonicalization syntax=20 is outside of this specification as it
   is mostly a = disadvantage=20 to merge naming domain and subject DN in a
   real=20 application.
 
 
------=_NextPart_000_011B_01C2B761.24499CF0-- From owner-ietf-pkix Wed Jan 8 14:09:56 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h08M9uA20063 for ietf-pkix-bks; Wed, 8 Jan 2003 14:09:56 -0800 (PST) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h08M9so20059 for ; Wed, 8 Jan 2003 14:09:55 -0800 (PST) Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18WONz-0000Ba-00; Wed, 08 Jan 2003 17:09:19 -0500 Message-ID: <3E1CA15A.8080304@asn-1.com> Date: Wed, 08 Jan 2003 17:08:26 -0500 From: "Phillip H. Griffin" Organization: http://asn-1.com User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Bartoletti CC: Peter Gutmann , anders.rundgren@telia.com, lynn.wheeler@firstdata.com, ambarish@malpani.biz, ietf-pkix@imc.org Subject: Re: OCSP and LDAP References: <5.0.0.25.2.20030108115433.03d32ca8@poptop.llnl.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Well, you guys are all much smarter than I am. I used to think I knew a lot about Directory, then I attended a few meetings. I figured that since I was pretty clever in my understanding of the abstract syntax and notation that I probably had a major leg up. I figured that directory was just another term for database. I figured that by having implemented shttp and early ssl in C and the first code ever (I think) to issue a v1 certificate at IBM, that maybe I had a clue. Turns out that just about an hour in a Directory meeting is enough to make your hat fit better. Extremely smart people involved. And they're probably not working on what most folks think they are. Phil Tony Bartoletti wrote: > > At 06:52 PM 1/8/2003 +1300, Peter Gutmann wrote: > >> Other person: "Why is X.500 so special? Why is no-one else doing this?" >> >> Me: "Get your favourite book on database technology and look up >> 'Hierarchical databases'". >> >> [Time passes] >> >> Other person: "I looked in several books. Many didn't mention it at >> all, >> and one had a half-page historical note saying it's >> something >> that was obsoleted by better technology more than two >> decades >> ago". >> >> Me: "Exactly". > > > > Heh. Actually, hierarchical databases can be superlative to most all > other technologies, when one has a static taxonomy to support. Trying > to represent (no less manage) a dynamically changing global namespace > with scores of independent geopolitical naming authorities with a > hierarchical database is rather ... ridiculous. :) > > Cheers! ____tony____ > > From owner-ietf-pkix Thu Jan 9 00:45:37 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h098jb322670 for ietf-pkix-bks; Thu, 9 Jan 2003 00:45:37 -0800 (PST) Received: from host8.successfulhosting.com (host8.successfulhosting.com [209.239.36.32]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h098jao22659 for ; Thu, 9 Jan 2003 00:45:36 -0800 (PST) Received: from ascertiacompaq ([203.81.197.48]) by host8.successfulhosting.com (8.10.2/8.10.2) with SMTP id h098jaN26096 for ; Thu, 9 Jan 2003 03:45:37 -0500 Message-ID: <003701c2b7ba$521a71a0$2400a8c0@ascertiacompaq> From: "Liaquat Khan" To: "Ietf-Pkix@Imc. Org" Subject: question on OCSP Date: Thu, 9 Jan 2003 08:36:10 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01C2B7BA.29480120" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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_0034_01C2B7BA.29480120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, According to Item 3 of Section 3.2 of RFC2560, OCSP clients should = confirm that "the identity of the signer matches the intended recipient = of the request" before accepting a signed OCSP response.=20 Can I ask how this can be achieved by the client? It is not quite as = simple as it seems, since the OCSP client may not know the identity of = the OCSP responder in advance, but only have an address of where the = OCSP responder is located (e.g. from the AIA extension of the = certificate whose revocation status is being checked).=20 Thanks and my apologies if this has already been covered before.=20 Regards, Liaquat Khan=20 ------=_NextPart_000_0034_01C2B7BA.29480120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

According to Item 3 of Section 3.2 of RFC2560, OCSP clients should = confirm=20 that "the identity of the signer matches the intended recipient of the = request"=20 before accepting a signed OCSP response.

Can I ask how this can be achieved by the client? It is not quite as = simple=20 as it seems, since the OCSP client may not know the identity of the OCSP = responder in advance, but only have an address of where the OCSP = responder is=20 located (e.g. from the AIA extension of the certificate whose revocation = status=20 is being checked).

Thanks and my apologies if this has already been covered before.

Regards,

Liaquat Khan

------=_NextPart_000_0034_01C2B7BA.29480120-- From owner-ietf-pkix Thu Jan 9 02:06:52 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h09A6qS02360 for ietf-pkix-bks; Thu, 9 Jan 2003 02:06:52 -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 h09A6po02356 for ; Thu, 9 Jan 2003 02:06:51 -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 h09A6pht027919 for ; Thu, 9 Jan 2003 11:06:51 +0100 (CET) X-Original-Recipient: Message-ID: <006901c2b7c6$8d33b920$0500a8c0@arport> From: "Anders Rundgren" To: References: <200301071330.IAA12313@ietf.org> Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-02.txt Date: Thu, 9 Jan 2003 11:04:51 +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: I would be happy to get some response from the "infrastructure deployment experts" of the PKIX WG on how you look at the software question. Ref: http://www.imc.org/ietf-pkix/mail-archive/msg05348.html If this question is out of scope, please let me know. >From the authors' I would be happy to get feedback on: http://www.imc.org/ietf-pkix/mail-archive/msg05349.html As VeriSign talks about "Limited liability warranty" it seems that these terms are intimately associated in the context of compensation for _indirect_ damages caused by faulty products... cheers, Anders ----- Original Message ----- From: To: Cc: Sent: Tuesday, January 07, 2003 14:30 Subject: I-D ACTION:draft-ietf-pkix-warranty-extn-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Warranty Certificate Extension Author(s) : D. Linsenbardt, S. Pontius, A. Sturgeon Filename : draft-ietf-pkix-warranty-extn-02.txt Pages : 7 Date : 2003-1-6 This document describes a certificate extension to explicitly state the warranty offered by a Certificate Authority (CA) for a the certificate containing the extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-warranty-extn-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-warranty-extn-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ietf-pkix Thu Jan 9 08:25:30 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h09GPUw26280 for ietf-pkix-bks; Thu, 9 Jan 2003 08:25:30 -0800 (PST) Received: from mail1.belgacom.be (mail1.belgacom.be [195.13.15.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h09GPSo26276 for ; Thu, 9 Jan 2003 08:25:29 -0800 (PST) Received: from exhub01.bc (exchange.bc [45.34.4.231]) by mail1.belgacom.be with SMTP id QAA22348 for ; Thu, 9 Jan 2003 16:25:25 GMT From: malek.bechlaghem@belgacom.be Received: from 127.0.0.1 by exhub01.bc (InterScan E-Mail VirusWall NT); Thu, 09 Jan 2003 17:23:48 +0100 Received: by exhub01.bc with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 17:23:48 +0100 Message-ID: <95C94B2F0094D21180710008C75DD6A40B9AB56D@apl541.bc> To: ietf-pkix@imc.org Subject: e-tendering enabler digital certificate Date: Thu, 9 Jan 2003 17:23:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear all, When answering to call for tenders, sellers should not be judged solely on the price the buyer will be billed for. Usually, a seller provide lots of documents and arguments to provide their ability to win a tender. I am aware about few initiatives to develop and implement an e-tendering service allowing particularly to automate the process of tender creation by the buyer and bid offer creation by suppliers. The approach of these initiative is to standardize the tender creation language and logic relying on XML and DTD schemas. I am quite confident in e-tendering since it will particularly allow to promote PKI and and digital certificates but i see that the idea of automating the process of tender creation might be confusing for the buyer and sellers. My idea to automate efficiently a fair tender winner determination (not relying only on the price proposed by the seller) is to rely on digital certificate with particular attributes. We can consider that terms of seller qualifications (a least few of them) can be standardized and the certification authority issue an "e-tendering enabler" certificate only for those sellers that meets the needed criterions. I would like to have feedback about my proposal i mean - whether there exist actually a similar initiative some where? - whether you find it is interest idea and subject? - if there organizations of people currently working on similar idears? thank you for your feedback, best regards, malek. ___________________________________________________________ Malek Bechlaghem e-Security Product Development Manager Strategy, Business Development and Product Management (SBP) Internet Business Unit (IBU) Belgacom SA/NV Bd du Roi Albert II, 27, B-1030 Brussels Tel.: +32 2 202 79 02 Fax: +32 2 202 41 06 E-mail: malek.bechlaghem@belgacom.be We bring security to the e-world : www.e-trust.be **** DISCLAIMER **** "This e-mail and any attachments thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by persons other than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation." From owner-ietf-pkix Thu Jan 9 15:34:11 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h09NYB009523 for ietf-pkix-bks; Thu, 9 Jan 2003 15:34:11 -0800 (PST) Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h09NY9o09519 for ; Thu, 9 Jan 2003 15:34:10 -0800 (PST) Received: from MarsXP ([148.233.248.105]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 9 Jan 2003 17:34:58 -0600 From: "Miguel Rodriguez" To: Subject: OCSP signed requests Date: Thu, 9 Jan 2003 17:34:18 -0600 Message-ID: <001001c2b837$a4866b60$a600a8c0@seguridata.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C2B805.59EBFB60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-OriginalArrivalTime: 09 Jan 2003 23:34:58.0250 (UTC) FILETIME=[B8C622A0:01C2B837] 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_0011_01C2B805.59EBFB60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit What is the prescribed (or most common) behavior of an OCSP responder when receiving a signed request? Should the signature be ignored if it is not required? Thanks, Miguel A. Rodriguez Software Engineer SeguriDATA ------=_NextPart_000_0011_01C2B805.59EBFB60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What is the prescribed (or most common) behavior of = an OCSP responder when receiving a signed request? Should the signature be = ignored if it is not required?

 

Thanks,

 

Miguel A. = Rodriguez

=

Software = Engineer

=

SeguriDATA

=

 

------=_NextPart_000_0011_01C2B805.59EBFB60-- From owner-ietf-pkix Thu Jan 9 19:26:07 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0A3Q7K15006 for ietf-pkix-bks; Thu, 9 Jan 2003 19:26:07 -0800 (PST) Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0A3Q3o14978 for ; Thu, 9 Jan 2003 19:26:04 -0800 (PST) Received: from MMyersLapTop (ppp213-77.coastside.net [207.213.213.77]) by mail.coastside.net with SMTP id h0A3Q581005849; Thu, 9 Jan 2003 19:26:06 -0800 (PST) From: "Michael Myers" To: "Miguel Rodriguez" , Subject: RE: OCSP signed requests Date: Thu, 9 Jan 2003 20:21:23 -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) Importance: Normal In-Reply-To: <001001c2b837$a4866b60$a600a8c0@seguridata.com> 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: Miguel, Signed OCSP requests enable audit trails and authenticated service access. Implementors should produce this capability; deployers decide on its use. Mike -----Original Message----- From: Miguel Rodriguez Sent: Thursday, January 09, 2003 3:34 PM Subject: OCSP signed requests What is the prescribed (or most common) behavior of an OCSP responder when receiving a signed request? Should the signature be ignored if it is not required? Thanks, Miguel A. Rodriguez Software Engineer SeguriDATA From owner-ietf-pkix Thu Jan 9 21:40:51 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0A5epM18870 for ietf-pkix-bks; Thu, 9 Jan 2003 21:40:51 -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 h0A5eoo18866 for ; Thu, 9 Jan 2003 21:40:50 -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 h0A5eqZp008617; Thu, 9 Jan 2003 21:40:52 -0800 From: "Ambarish Malpani" To: "Miguel Rodriguez" , Subject: RE: OCSP signed requests Date: Thu, 9 Jan 2003 21:41:19 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0135_01C2B827.D8672970" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <001001c2b837$a4866b60$a600a8c0@seguridata.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: This is a multi-part message in MIME format. ------=_NextPart_000_0135_01C2B827.D8672970 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Miguel, If a responder doesn't require signed requests, it is free to ignore the signature completely and not validate it at all. Hope this helps, Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani 650.759.9045 Malpani Consulting Services ambarish@malpani.biz -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Miguel Rodriguez Sent: Thursday, January 09, 2003 3:34 PM To: ietf-pkix@imc.org Subject: OCSP signed requests What is the prescribed (or most common) behavior of an OCSP responder when receiving a signed request? Should the signature be ignored if it is not required? Thanks, Miguel A. Rodriguez Software Engineer SeguriDATA ------=_NextPart_000_0135_01C2B827.D8672970 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi=20 Miguel,
    If a responder doesn't require signed = requests, it is=20 free to ignore the signature
completely and not validate it at all.
 
Hope=20 this helps,
Regards,
Ambarish
 

----------------------------------------------------------------= -----
Ambarish=20 Malpani           =             &= nbsp;           &n= bsp;     =20 650.759.9045
Malpani Consulting=20 Services           = ;            =           =20 ambarish@malpani.biz

-----Original Message-----
From: = owner-ietf-pkix@mail.imc.org=20 [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Miguel=20 Rodriguez
Sent: Thursday, January 09, 2003 3:34 = PM
To:=20 ietf-pkix@imc.org
Subject: OCSP signed = requests

What is the prescribed = (or most=20 common) behavior of an OCSP responder when receiving a signed request? = Should=20 the signature be ignored if it is not required? =

 

Thanks,

 

Miguel=20 A. Rodriguez

Software=20 Engineer

SeguriDATA

 

------=_NextPart_000_0135_01C2B827.D8672970-- From owner-ietf-pkix Fri Jan 10 00:42:14 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0A8gE508551 for ietf-pkix-bks; Fri, 10 Jan 2003 00:42:14 -0800 (PST) Received: from mail4.consignia.com (mail4.consignia.com [144.87.143.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0A8gCo08540 for ; Fri, 10 Jan 2003 00:42:13 -0800 (PST) Received: from postoffice.co.uk (mta2.int.consignia.com [144.87.146.16]) by mail4.consignia.com (Postfix) with SMTP id B4C7412237C; Fri, 10 Jan 2003 08:42:02 +0000 (GMT) Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 00256CAA.002FD0A6 ; Fri, 10 Jan 2003 08:42:16 +0000 X-Lotus-FromDomain: POSTOFFICE From: chris.gilbert@Royalmail.com To: ietf-pkix@imc.org Cc: malek.bechlaghem@belgacom.be Message-ID: <00256CAA.002FCCD7.00@postoffice.co.uk> Date: Fri, 10 Jan 2003 08:41:45 +0000 Subject: Re: e-tendering enabler digital certificate Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > My idea ... is to rely on digital certificate with particular > attributes. I am against building application information into Certificates. They are merely a trust mechanism. Every time you add to the content you make it harder to achieve interoperability. Push the application specific logic back into the application. Chris From owner-ietf-pkix Fri Jan 10 03:07:32 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0AB7Wc24059 for ietf-pkix-bks; Fri, 10 Jan 2003 03:07:32 -0800 (PST) Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0AB7To24045 for ; Fri, 10 Jan 2003 03:07:30 -0800 (PST) Received: from localhost (217.215.93.181) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Fri, 10 Jan 2003 12:05:33 +0100 Date: Fri, 10 Jan 2003 12:03:36 +0100 (CET) Message-ID: <20030110.120336.27781785.levitte@lp.se> To: chris.gilbert@Royalmail.com CC: ietf-pkix@imc.org, malek.bechlaghem@belgacom.be Subject: Re: e-tendering enabler digital certificate From: Richard Levitte - VMS Whacker In-Reply-To: <00256CAA.002FCCD7.00@postoffice.co.uk> References: <00256CAA.002FCCD7.00@postoffice.co.uk> X-URL: http://www.lp.se/ X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1 X-Mew: See http://www.mew.org/ X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) MIME-Version: 1.0 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: In message <00256CAA.002FCCD7.00@postoffice.co.uk> on Fri, 10 Jan 2003 08:41:45 +0000, chris.gilbert@Royalmail.com said: chris.gilbert> > My idea ... is to rely on digital certificate with particular chris.gilbert> > attributes. chris.gilbert> chris.gilbert> I am against building application information into Certificates. chris.gilbert> They are merely a trust mechanism. Every time you add to the chris.gilbert> content you make it harder to achieve interoperability. Push the chris.gilbert> application specific logic back into the application. Hmm, attribute certificates come to mind. Is there any reason (apart from lack of implementation, I'm want to hear theories, not that it currently can't be achieved in practice) not to use them? -- Richard Levitte | http://richard.levitte.org/ | Spannv. 38, I Levitte Programming | http://www.lp.se/ | S-168 35 Bromma T: +46-708-26 53 44 | | SWEDEN "Price, performance, quality... choose the two you like" From owner-ietf-pkix Fri Jan 10 04:31:34 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0ACVYx29492 for ietf-pkix-bks; Fri, 10 Jan 2003 04:31:34 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0ACVVo29487 for ; Fri, 10 Jan 2003 04:31:31 -0800 (PST) Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA15536; Fri, 10 Jan 2003 13:32:32 +0100 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id NAA22528; Fri, 10 Jan 2003 13:31:11 +0100 Message-ID: <3E1EBCFE.4020204@bull.net> Date: Fri, 10 Jan 2003 13:30:54 +0100 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Tim Polk CC: ietf-pkix@imc.org, kent@bbn.com, Russ Housley , stefan@addtrust.com, trevorf@microsoft.com Subject: Re: WG Last Call: Logotypes References: <5.1.0.14.2.20021223153044.00ae6cd8@email.nist.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > This message initiates working group Last Call for the logotypes > document. In light of holiday schedules, Last Call will run for three > weeks rather than two weeks. That is, Last Call will not close before > January 13. The URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-09.txt > > The editors have informed us that "all of the items briefed at the > meeting in Atlanta as well as the request by the chairs have been > handled. In addition, a few comments from working group members that > sent us email have been addressed." I acknowledge the fact that many improvements have been done to the specification. However I have two remaining concerns: 1. In order to try to solve the minimum interoperability requirements between an application and a certificate issuer, the characteristics of the size of the picture have been indicated in the following way: At least one of the image files representing a logotype SHOULD contain an image within the size range of 60 pixels wide by 45 pixels high and 200 pixels wide by 150 pixels high. This does not say what whether a client is able or not to display logos, which was the basic question. I suggest to mandate clients to support at least images within the size range of 60 pixels wide by 45 pixels. This sentence does not exist in the document and should be added. 2. I have indicated that it would be nice to have an optional pointer to a web site where more information could be obtained about the logo. This is currently not possible with the current definition. From a non-technical point of view, it would be a very nice marketing tool. This can easily be accomplished by adding one OPTIONAL element in the ASN.1 syntax. Denis From owner-ietf-pkix Fri Jan 10 04:46:37 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0ACkbn29884 for ietf-pkix-bks; Fri, 10 Jan 2003 04:46:37 -0800 (PST) Received: from mail3.consignia.com (mail3.consignia.com [144.87.143.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0ACkao29880 for ; Fri, 10 Jan 2003 04:46:36 -0800 (PST) Received: from postoffice.co.uk (mta2.int.consignia.com [144.87.146.16]) by mail3.consignia.com (Postfix) with SMTP id DCBD118F8D9; Fri, 10 Jan 2003 12:46:35 +0000 (GMT) Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 00256CAA.00463106 ; Fri, 10 Jan 2003 12:46:40 +0000 X-Lotus-FromDomain: POSTOFFICE From: chris.gilbert@Royalmail.com To: Richard Levitte - VMS Whacker Cc: ietf-pkix@imc.org Message-ID: <00256CAA.0041DFCE.00@postoffice.co.uk> Date: Fri, 10 Jan 2003 11:59:01 +0000 Subject: Re: e-tendering enabler digital certificate Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > attribute certificates come to mind. I have no doubt that it could be done but it strikes me as a rather specialised implementation. I am sure, that any of the large cert vendors would gladly relieve the parties involved in the process of their cash in return for the privilege of constructing the certs and the associated registration process :-) Alternatively, if the issuer of the tender owns and runs a CA then they could issue appropriate Attribute Certificates to those people tendering. Then again CA could even be owned by an organisation that sells the facilitation of this sort of thing and includes the cost of the certs and registration in the package. The more generic the supporting infrastructure becomes the lower the cost of implementation. Chris From owner-ietf-pkix Fri Jan 10 05:44:05 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0ADi5704774 for ietf-pkix-bks; Fri, 10 Jan 2003 05:44:05 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0ADi2o04770 for ; Fri, 10 Jan 2003 05:44:03 -0800 (PST) Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA26806; Fri, 10 Jan 2003 14:45:36 +0100 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id OAA25016; Fri, 10 Jan 2003 14:44:15 +0100 Message-ID: <3E1ECE1F.9090007@bull.net> Date: Fri, 10 Jan 2003 14:43:59 +0100 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: carol CC: "ietf-pkix@imc.org" Subject: Re: [TSP] while introduce TSU in RFC3161bis-00? References: <200212240934.gBO9YCo11877@above.proper.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Carol, Sorry for the delay to answer, > Folks, > > I am wondering while RFC3161bis-00 introduces TSU. > Can I interpret as the following ? > 1. One TSA may support multiple policy, just as one CA may have multiple policy. > 2. Each policy or some policies of one TSA needs a TSU to support. The basic argument is that one TSA (i.e. organization) may be in charge of several TSUs (units). Each unit has its own key pair while the organization does not need to have any key pair. Units can be revoked, while there is no concept of revocation of the organization as a whole. It is true as well that one TSA (i.e. organization) can support several policies. Regards, Denis > Thanks in advance, > > carol > wangbingyan@ccit.com.cn > 2002-12-24 From owner-ietf-pkix Fri Jan 10 06:11:21 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0AEBLd05603 for ietf-pkix-bks; Fri, 10 Jan 2003 06:11:21 -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 h0AEBIo05598 for ; Fri, 10 Jan 2003 06:11:18 -0800 (PST) Received: (qmail 22762 invoked from network); 10 Jan 2003 14:10:46 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.186.236) by woodstock.binhost.com with SMTP; 10 Jan 2003 14:10:46 -0000 Message-Id: <5.2.0.9.2.20030110085451.00b8a8a8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 10 Jan 2003 09:04:04 -0500 To: Denis Pinkas From: Russ Housley Subject: Re: WG Last Call: Logotypes Cc: ietf-pkix@imc.org, kent@bbn.com, stefan@addtrust.com, trevorf@microsoft.com, Tim Polk In-Reply-To: <3E1EBCFE.4020204@bull.net> References: <5.1.0.14.2.20021223153044.00ae6cd8@email.nist.gov> 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: Denis: >>This message initiates working group Last Call for the logotypes >>document. In light of holiday schedules, Last Call will run for three >>weeks rather than two weeks. That is, Last Call will not close before >>January 13. The URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-09.txt >>The editors have informed us that "all of the items briefed at the >>meeting in Atlanta as well as the request by the chairs have been >>handled. In addition, a few comments from working group members that sent >>us email have been addressed." > >I acknowledge the fact that many improvements have been done to the >specification. > >However I have two remaining concerns: > >1. In order to try to solve the minimum interoperability requirements >between an application and a certificate issuer, the characteristics of >the size of the picture have been indicated in the following way: > > At least one of the image files representing a logotype SHOULD > contain an image within the size range of 60 pixels wide by 45 pixels > high and 200 pixels wide by 150 pixels high. > >This does not say what whether a client is able or not to display logos, >which was the basic question. > >I suggest to mandate clients to support at least images within the size >range of 60 pixels wide by 45 pixels. This sentence does not exist in the >document and should be added. I have no problem with this addition. >2. I have indicated that it would be nice to have an optional pointer to a >web site where more information could be obtained about the logo. This is >currently not possible with the current definition. From a non-technical >point of view, it would be a very nice marketing tool. > >This can easily be accomplished by adding one OPTIONAL element in the >ASN.1 syntax. This addition opens a huge can of worms. I would prefer to leave the lid tightly sealed. The certificate issuer would be including a reference in the certificate to information that is maintained by another party, and that other party could make unacceptable changes after certificate issuance. The usual mechanism to handle this situation is to include a hash value of the referenced object, preventing any changes. However, in this context, this does not seem like an appropriate thing to do. The organization that owns the logo will surely want to make changes to their web page. And, it is not easy to handle links form that web page. Handling links would require the definition of complicated canonicalization rules. Russ From owner-ietf-pkix Fri Jan 10 07:24:57 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0AFOvt09326 for ietf-pkix-bks; Fri, 10 Jan 2003 07:24:57 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0AFOso09315 for ; Fri, 10 Jan 2003 07:24:54 -0800 (PST) Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA35540; Fri, 10 Jan 2003 16:25:09 +0100 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id QAA19392; Fri, 10 Jan 2003 16:23:48 +0100 Message-ID: <3E1EE574.8080402@bull.net> Date: Fri, 10 Jan 2003 16:23:32 +0100 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: ietf-pkix@imc.org, kent@bbn.com, stefan@addtrust.com, trevorf@microsoft.com, Tim Polk Subject: Re: WG Last Call: Logotypes References: <5.1.0.14.2.20021223153044.00ae6cd8@email.nist.gov> <5.2.0.9.2.20030110085451.00b8a8a8@mail.binhost.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Thanks for your prompt answer. > Denis: > >>> This message initiates working group Last Call for the logotypes >>> document. In light of holiday schedules, Last Call will run for >>> three weeks rather than two weeks. That is, Last Call will not close >>> before January 13. The URL for this Internet-Draft is: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-09.txt >>> The editors have informed us that "all of the items briefed at the >>> meeting in Atlanta as well as the request by the chairs have been >>> handled. In addition, a few comments from working group members that >>> sent us email have been addressed." >> >> >> I acknowledge the fact that many improvements have been done to the >> specification. >> >> However I have two remaining concerns: >> >> 1. In order to try to solve the minimum interoperability requirements >> between an application and a certificate issuer, the characteristics >> of the size of the picture have been indicated in the following way: >> >> At least one of the image files representing a logotype SHOULD >> contain an image within the size range of 60 pixels wide by 45 pixels >> high and 200 pixels wide by 150 pixels high. >> >> This does not say what whether a client is able or not to display >> logos, which was the basic question. >> >> I suggest to mandate clients to support at least images within the >> size range of 60 pixels wide by 45 pixels. This sentence does not >> exist in the document and should be added. > > > I have no problem with this addition. Fine. >> 2. I have indicated that it would be nice to have an optional pointer >> to a web site where more information could be obtained about the logo. >> This is currently not possible with the current definition. From a >> non-technical point of view, it would be a very nice marketing tool. >> >> This can easily be accomplished by adding one OPTIONAL element in the >> ASN.1 syntax. > > > This addition opens a huge can of worms. I would prefer to leave the > lid tightly sealed. I would rather go fishing with that huge can of worms. :-) > The certificate issuer would be including a reference in the certificate > to information that is maintained by another party, and that other party > could make unacceptable changes after certificate issuance. The usual > mechanism to handle this situation is to include a hash value of the > referenced object, preventing any changes. However, in this context, > this does not seem like an appropriate thing to do. The organization > that owns the logo will surely want to make changes to their web page. > And, it is not easy to handle links form that web page. Handling links > would require the definition of complicated canonicalization rules. The basic question is what the link contains. The intent is not to point to a link where you have the exact meaning of the logo, but to the entry point of a web site. Here is an example for such a URL: http://www.cartes-bancaires.com/GB/Pages/Accueil2.htm So we need to carefully state what the link contains. Denis > Russ > > From owner-ietf-pkix Fri Jan 10 09:40:23 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0AHeNF15414 for ietf-pkix-bks; Fri, 10 Jan 2003 09:40:23 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0AHeLo15406 for ; Fri, 10 Jan 2003 09:40:21 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05599; Fri, 10 Jan 2003 12:37:05 -0500 (EST) Message-Id: <200301101737.MAA05599@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ocsp-dpvdpd-00.txt Date: Fri, 10 Jan 2003 12:37:04 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : DPV and DPD over OCSP Author(s) : M. Myers Filename : draft-ietf-pkix-ocsp-dpvdpd-00.txt Pages : 8 Date : 2003-1-9 This specification standardizes means by which the extensibility mechanisms of OCSP are to be used for Delegated Path Validation (DPV) and Delegated Path Discovery (DPD). Familiarity with OCSP core syntax [RFC2560] is assumed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-dpvdpd-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ocsp-dpvdpd-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ocsp-dpvdpd-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-10122700.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ocsp-dpvdpd-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ocsp-dpvdpd-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-10122700.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Fri Jan 10 08:42:13 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0AGgD513336 for ietf-pkix-bks; Fri, 10 Jan 2003 08:42:13 -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 h0AGg9o13316 for ; Fri, 10 Jan 2003 08:42:10 -0800 (PST) Received: (qmail 31448 invoked from network); 10 Jan 2003 16:41:41 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.215.77) by woodstock.binhost.com with SMTP; 10 Jan 2003 16:41:41 -0000 Message-Id: <5.2.0.9.2.20030110111006.029a7480@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 10 Jan 2003 11:14:49 -0500 To: Denis Pinkas From: Russ Housley Subject: Re: WG Last Call: Logotypes Cc: ietf-pkix@imc.org, kent@bbn.com, stefan@addtrust.com, trevorf@microsoft.com, Tim Polk In-Reply-To: <3E1EE574.8080402@bull.net> References: <5.1.0.14.2.20021223153044.00ae6cd8@email.nist.gov> <5.2.0.9.2.20030110085451.00b8a8a8@mail.binhost.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: Denis: >>The certificate issuer would be including a reference in the certificate >>to information that is maintained by another party, and that other party >>could make unacceptable changes after certificate issuance. The usual >>mechanism to handle this situation is to include a hash value of the >>referenced object, preventing any changes. However, in this context, >>this does not seem like an appropriate thing to do. The organization >>that owns the logo will surely want to make changes to their web page. >>And, it is not easy to handle links form that web page. Handling links >>would require the definition of complicated canonicalization rules. > >The basic question is what the link contains. The intent is not to point >to a link where you have the exact meaning of the logo, but to the entry >point of a web site. Here is an example for such a URL: > >http://www.cartes-bancaires.com/GB/Pages/Accueil2.htm > >So we need to carefully state what the link contains. I understand the manner that you wish to use the URL. It is not appropriate to prevent changes to such a web page by including a hash in the certificate. So, it is possible for changes to be unacceptable to the certificate issuer. The only recourse would be the revocation of the certificate, and this punishes the wrong party. The subject would have to get a new certificate (without the embedded URL), yet the subject had no part in the activities that lead to revocation. I remain opposed. Russ From owner-ietf-pkix Fri Jan 10 11:31:16 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0AJVGn18859 for ietf-pkix-bks; Fri, 10 Jan 2003 11:31:16 -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 h0AJVFo18855 for ; Fri, 10 Jan 2003 11:31:15 -0800 (PST) Received: (qmail 11971 invoked from network); 10 Jan 2003 19:30:54 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.178.141) by woodstock.binhost.com with SMTP; 10 Jan 2003 19:30:54 -0000 Message-Id: <5.2.0.9.2.20030110142822.02973fc0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 10 Jan 2003 14:31:12 -0500 To: Timothy Hahn From: Russ Housley Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option) Cc: ietf-pkix@imc.org In-Reply-To: References: <5.2.0.9.2.20030106162604.02959a38@mail.binhost.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: Tim: In the PKIX WG, we have learned a hard lesson about letting two standard that accomplish the same goal progress. The "let the market decide" has lead to camps that implement the alternatives, but do not interoperate with each other, even if they know why they do not interoperate. I do not want to repeat this mistake. Russ At 08:40 AM 1/7/2003 -0500, Timothy Hahn wrote: >Russ, > >Great question. Simply - it gives the "client" the opportunity to >establish whether or not it can or cannot support retrieval of the >information from that data source (directory sub-tree). Client and server >implementations choose which protocols and data models they're going to >"support" all the time. As long as both support the same model(s), then >they interoperate. My proposal is that we define one way to identify which >data model(s) is(are) employed, so that servers and clients can determine >whether they are capable of supporting the formats. If they are not >capable, they can gracefully fail. > >The client can be made as "fat" or as "lean" as the implementer wants, >because the implementer can decide which formats to support. If the >implementer decides to support one while another part of the industry tends >to support another - well, then that particular implementation will get >"fatter" because it will wind up supporting both. > >My premise is that there is not a single data model that "fits" for ALL >applications/deployments. And because of that, multiple data models can >and will (in real-world scenarios) exist. So why not accept this, define a >(singular) way of identifying which model is used, and move on. At least >in this way, if a particular implementation/application has a need to store >things in a different way, it can, and we can still hope for >interoperability through IETF documents. > >Regards, >Tim Hahn > >Internet: hahnt@us.ibm.com >Internal: Timothy Hahn/Durham/IBM@IBMUS >phone: 919.224.1565 tie-line: 8/687.1565 >fax: 919.224.2540 > >|+-----------------------+------------------------------------------------| >|| Russ Housley | | >|| || m> | Hahn/Durham/IBM@IBMUS | >|| | cc: ietf-pkix@imc.org | >|| 01/06/2003 04:28 PM | Subject: Re: LDAP PKI Schema | >|| | (was Re: No-op LDAP ;binary option) | >|| | | >|| | | >|+-----------------------+------------------------------------------------| > > > > > >Tim: > >I do not understand how a client is better off with multiple ways to put >the same information in the Directory. Doesn't this approach just make the >client fat? It seem to me that the client would have to support all of the >possible ways that the information could be stored. It cannot know which >method it will encounter until it starts looking at data in the Directory. > >Russ > > >At 03:14 PM 1/6/2003 -0500, Timothy Hahn wrote: > >Hello all, > > > >After listening to the different view-points on this topic, it seems to me > >that there are multiple valid approaches. These approaches include, but > >are not limited to: > > - leveraging the general solution of component-matching > > - new schema to support application-managed componentization of > >information to make things searchable > >as well as others (additional matching rules, for example). > > > >It occurs to me that perhaps we have a situation where "one size does not > >fit all". Why not accept this and define a way for applications to > >determine which (of possibly multiple) format(s) has been used to place >the > >information into the directory? We could define some small bit of schema > >which indicates the way in which the certificate information is placed >into > >the directory, then different applications could query this and determine: > > - whether they can use the data at all > > - if they can use the data, how they can best use it (if there are, for > >example, multiple mechanisms employed). > > > >Just a thought to get us through this discussion. > > > >Regards, > >Tim Hahn > > From owner-ietf-pkix Sun Jan 12 23:54:02 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0D7s2L02227 for ietf-pkix-bks; Sun, 12 Jan 2003 23:54:02 -0800 (PST) Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0D7s0o02223 for ; Sun, 12 Jan 2003 23:54:01 -0800 (PST) Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id h0D7rsLb022300 for ; Mon, 13 Jan 2003 08:53:55 +0100 (CET) X-Original-Recipient: Message-ID: <006a01c2bad8$a0802490$0500a8c0@arport> From: "Anders Rundgren" To: References: <009401c1b5a3$ea927cd0$0500a8c0@arport> <3C6CEE7D.CDEA4B79@bull.net> <012201c1b633$93cd09c0$0500a8c0@arport> <3C70C411.474F1354@bull.net> Subject: Re: I-D ACTION:draft-ietf-pkix-pi-06.txt Date: Mon, 13 Jan 2003 08:51:48 +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: In the Nordic region TTP CAs are slowly but surely supporting a total of 15 million citizens using "implicit" PI-schemes as described on the next line: Subject: CN=Maria Svensson, serialNumber=43566, C=SE Now, how should they preferably convert to using the PKIX PI profile? (it is of some value to know that these profiles are compatible with RFC3039 which requires DNs to be unique) Variant 1. Redundantly storing the citizen code in each EE-cert: Subject: CN=Maria Svensson, serialNumber=43566, C=SE PI Assigner Authority: http://government.se/citizens PI Value: 43566 Variant 2. Adding a nonsense disambiguer code to the subject DN: Subject: CN=Maria Svensson, serialNumber=6, C=SE PI Assigner Authority: http://government.se/citizens PI Value: 43566 It there a variant 3? Cheers, Anders From owner-ietf-pkix Mon Jan 13 02:10:44 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0DAAiG19767 for ietf-pkix-bks; Mon, 13 Jan 2003 02:10:44 -0800 (PST) Received: from mail3.consignia.com (mail3.consignia.com [144.87.143.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0DAAho19763 for ; Mon, 13 Jan 2003 02:10:43 -0800 (PST) Received: from postoffice.co.uk (mta2.int.consignia.com [144.87.146.16]) by mail3.consignia.com (Postfix) with SMTP id 337C218F97D; Mon, 13 Jan 2003 10:10:42 +0000 (GMT) Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 00256CAD.0037EEFE ; Mon, 13 Jan 2003 10:10:56 +0000 X-Lotus-FromDomain: POSTOFFICE From: chris.gilbert@Royalmail.com To: ietf-pkix@imc.org Cc: Russ Housley Message-ID: <00256CAD.0037EE02.00@postoffice.co.uk> Date: Mon, 13 Jan 2003 10:10:33 +0000 Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The "let the market decide" has > lead to camps that implement the alternatives, but do not interoperate with > each other, even if they know why they do not interoperate. I do not want > to repeat this mistake. Amen. Any chance of coming up with a procedure that de-engineers these standards ? We are failing in the 'Review' stage of the project life-cycle :-) Chris From owner-ietf-pkix Mon Jan 13 05:00:13 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0DD0DI01977 for ietf-pkix-bks; Mon, 13 Jan 2003 05:00:13 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0DD08o01972 for ; Mon, 13 Jan 2003 05:00:08 -0800 (PST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0DD03md005384 for ; Mon, 13 Jan 2003 08:00:03 -0500 Received: from d01mlc96.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0DD00Gm082208 for ; Mon, 13 Jan 2003 08:00:00 -0500 In-Reply-To: <5.2.0.9.2.20030110142822.02973fc0@mail.binhost.com> To: ietf-pkix@imc.org MIME-Version: 1.0 Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option) X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Timothy Hahn X-MIMETrack: S/MIME Sign by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/13/2003 07:57:28 AM, Serialize by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/13/2003 07:57:28 AM, Serialize complete at 01/13/2003 07:57:28 AM, Itemize by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/13/2003 07:57:28 AM, S/MIME Sign complete at 01/13/2003 07:57:28 AM, S/MIME Sign by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/13/2003 08:00:01 AM, S/MIME Sign complete at 01/13/2003 08:00:01 AM, Serialize by Router on D01MLC96/01/M/IBM(Build V601_12152002 SPR MIAS5GXKFV CBOD5GVRDB TDAS5GZPCG|January 7, 2003) at 01/13/2003 08:00:01, Serialize complete at 01/13/2003 08:00:01 Message-ID: Date: Mon, 13 Jan 2003 07:59:59 -0500 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z35712_boundary_sign Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is an S/MIME signed message. ---------z35712_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 00472E1685256CAD_=" This is a multipart message in MIME format. --=_alternative 00472E1685256CAD_= Content-Type: text/plain; charset="US-ASCII" Russ, I agree with you in not wanting two standards for accomplishing the same goal. But I still assert that the (currently) two proposed models do not have exactly the same goals, hence a possibility that the different goals require different solutions. Option 1: single entry, containing possibly multiple userCertificate attribute values Goals: (primary) support existing deployments which assume this model, (secondary) support attribute-within-certificate searching, (secondary) support single userCertificate retrieval. Option 2: multiple entry, containing single userCertificate attribute value per entry, entries related by sub-tree layout Goals: (primary) support attribute-within-certificate searching with existing and widely available directory technologies, (primary) support single userCertificate retrieval, (non-goal) support existing deployments which assume a single entry model. I accept the desire to not have this situation, but I also believe it is going to occur - so why wouldn't we try and infuse at least some order into this situation? Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Durham/IBM@IBMUS phone: 919.224.1565 tie-line: 8/687.1565 fax: 919.224.2540 Russ Housley Sent by: owner-ietf-pkix@mail.imc.org 01/10/2003 02:31 PM To: Timothy Hahn/Durham/IBM@IBMUS cc: ietf-pkix@imc.org Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option) Tim: In the PKIX WG, we have learned a hard lesson about letting two standard that accomplish the same goal progress. The "let the market decide" has lead to camps that implement the alternatives, but do not interoperate with each other, even if they know why they do not interoperate. I do not want to repeat this mistake. Russ At 08:40 AM 1/7/2003 -0500, Timothy Hahn wrote: >Russ, > >Great question. Simply - it gives the "client" the opportunity to >establish whether or not it can or cannot support retrieval of the >information from that data source (directory sub-tree). Client and server >implementations choose which protocols and data models they're going to >"support" all the time. As long as both support the same model(s), then >they interoperate. My proposal is that we define one way to identify which >data model(s) is(are) employed, so that servers and clients can determine >whether they are capable of supporting the formats. If they are not >capable, they can gracefully fail. > >The client can be made as "fat" or as "lean" as the implementer wants, >because the implementer can decide which formats to support. If the >implementer decides to support one while another part of the industry tends >to support another - well, then that particular implementation will get >"fatter" because it will wind up supporting both. > >My premise is that there is not a single data model that "fits" for ALL >applications/deployments. And because of that, multiple data models can >and will (in real-world scenarios) exist. So why not accept this, define a >(singular) way of identifying which model is used, and move on. At least >in this way, if a particular implementation/application has a need to store >things in a different way, it can, and we can still hope for >interoperability through IETF documents. > >Regards, >Tim Hahn > >Internet: hahnt@us.ibm.com >Internal: Timothy Hahn/Durham/IBM@IBMUS >phone: 919.224.1565 tie-line: 8/687.1565 >fax: 919.224.2540 > >|+-----------------------+------------------------------------------------| >|| Russ Housley | | >|| || m> | Hahn/Durham/IBM@IBMUS | >|| | cc: ietf-pkix@imc.org | >|| 01/06/2003 04:28 PM | Subject: Re: LDAP PKI Schema | >|| | (was Re: No-op LDAP ;binary option) | >|| | | >|| | | >|+-----------------------+------------------------------------------------| > > > > > >Tim: > >I do not understand how a client is better off with multiple ways to put >the same information in the Directory. Doesn't this approach just make the >client fat? It seem to me that the client would have to support all of the >possible ways that the information could be stored. It cannot know which >method it will encounter until it starts looking at data in the Directory. > >Russ > > >At 03:14 PM 1/6/2003 -0500, Timothy Hahn wrote: > >Hello all, > > > >After listening to the different view-points on this topic, it seems to me > >that there are multiple valid approaches. These approaches include, but > >are not limited to: > > - leveraging the general solution of component-matching > > - new schema to support application-managed componentization of > >information to make things searchable > >as well as others (additional matching rules, for example). > > > >It occurs to me that perhaps we have a situation where "one size does not > >fit all". Why not accept this and define a way for applications to > >determine which (of possibly multiple) format(s) has been used to place >the > >information into the directory? We could define some small bit of schema > >which indicates the way in which the certificate information is placed >into > >the directory, then different applications could query this and determine: > > - whether they can use the data at all > > - if they can use the data, how they can best use it (if there are, for > >example, multiple mechanisms employed). > > > >Just a thought to get us through this discussion. > > > >Regards, > >Tim Hahn > > --=_alternative 00472E1685256CAD_= Content-Type: text/html; charset="US-ASCII"
Russ,

I agree with you in not wanting two standards for accomplishing the same goal.

But I still assert that the (currently) two proposed models do not have exactly the same goals, hence a possibility that the different goals require different solutions.

Option 1: single entry, containing possibly multiple userCertificate attribute values
Goals: (primary) support existing deployments which assume this model, (secondary) support attribute-within-certificate searching, (secondary) support single userCertificate retrieval.

Option 2: multiple entry, containing single userCertificate attribute value per entry, entries related by sub-tree layout
Goals: (primary) support attribute-within-certificate searching with existing and widely available directory technologies, (primary) support single userCertificate retrieval, (non-goal) support existing deployments which assume a single entry model.

I accept the desire to not have this situation, but I also believe it is going to occur - so why wouldn't we try and infuse at least some order into this situation?

Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Durham/IBM@IBMUS
phone: 919.224.1565     tie-line: 8/687.1565
fax: 919.224.2540


Russ Housley <housley@vigilsec.com>
Sent by: owner-ietf-pkix@mail.imc.org

01/10/2003 02:31 PM

       
        To:        Timothy Hahn/Durham/IBM@IBMUS
        cc:        ietf-pkix@imc.org
        Subject:        Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)

       



Tim:

In the PKIX WG, we have learned a hard lesson about letting two standard
that accomplish the same goal progress.  The "let the market decide" has
lead to camps that implement the alternatives, but do not interoperate with
each other, even if they know why they do not interoperate.  I do not want
to repeat this mistake.

Russ


At 08:40 AM 1/7/2003 -0500, Timothy Hahn wrote:



>Russ,
>
>Great question.  Simply - it gives the "client" the opportunity to
>establish whether or not it can or cannot support retrieval of the
>information from that data source (directory sub-tree).  Client and server
>implementations choose which protocols and data models they're going to
>"support" all the time.  As long as both support the same model(s), then
>they interoperate.  My proposal is that we define one way to identify which
>data model(s) is(are) employed, so that servers and clients can determine
>whether they are capable of supporting the formats.  If they are not
>capable, they can gracefully fail.
>
>The client can be made as "fat" or as "lean" as the implementer wants,
>because the implementer can decide which formats to support.  If the
>implementer decides to support one while another part of the industry tends
>to support another - well, then that particular implementation will get
>"fatter" because it will wind up supporting both.
>
>My premise is that there is not a single data model that "fits" for ALL
>applications/deployments.  And because of that, multiple data models can
>and will (in real-world scenarios) exist.  So why not accept this, define a
>(singular) way of identifying which model is used, and move on.  At least
>in this way, if a particular implementation/application has a need to store
>things in a different way, it can, and we can still hope for
>interoperability through IETF documents.
>
>Regards,
>Tim Hahn
>
>Internet: hahnt@us.ibm.com
>Internal: Timothy Hahn/Durham/IBM@IBMUS
>phone: 919.224.1565     tie-line: 8/687.1565
>fax: 919.224.2540
>
>|+-----------------------+------------------------------------------------|
>||   Russ Housley        |                                                |
>||   <housley@vigilsec.co|           To:        Timothy                   |
>||   m>                  |   Hahn/Durham/IBM@IBMUS                        |
>||                       |           cc:        ietf-pkix@imc.org         |
>||   01/06/2003 04:28 PM |           Subject:        Re: LDAP PKI Schema  |
>||                       |   (was Re: No-op LDAP ;binary option)          |
>||                       |                                                |
>||                       |                                                |
>|+-----------------------+------------------------------------------------|
>
>
>
>
>
>Tim:
>
>I do not understand how a client is better off with multiple ways to put
>the same information in the Directory.  Doesn't this approach just make the
>client fat?  It seem to me that the client would have to support all of the
>possible ways that the information could be stored.  It cannot know which
>method it will encounter until it starts looking at data in the Directory.
>
>Russ
>
>
>At 03:14 PM 1/6/2003 -0500, Timothy Hahn wrote:
> >Hello all,
> >
> >After listening to the different view-points on this topic, it seems to me
> >that there are multiple valid approaches.  These approaches include, but
> >are not limited to:
> >   - leveraging the general solution of component-matching
> >   - new schema to support application-managed componentization of
> >information to make things searchable
> >as well as others (additional matching rules, for example).
> >
> >It occurs to me that perhaps we have a situation where "one size does not
> >fit all".  Why not accept this and define a way for applications to
> >determine which (of possibly multiple) format(s) has been used to place
>the
> >information into the directory?  We could define some small bit of schema
> >which indicates the way in which the certificate information is placed
>into
> >the directory, then different applications could query this and determine:
> >   - whether they can use the data at all
> >   - if they can use the data, how they can best use it (if there are, for
> >example, multiple mechanisms employed).
> >
> >Just a thought to get us through this discussion.
> >
> >Regards,
> >Tim Hahn
>
>
--=_alternative 00472E1685256CAD_=-- ---------z35712_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIIULwIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISUDCCAtow ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1 aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf 1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117 ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r 1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0 MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf 1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn 00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMiMIIC i6ADAgECAgJONTANBgkqhkiG9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJu YXRpb25hbCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MB4XDTAyMTEyMTEzMDY1M1oXDTAzMTIwNTEzMDY1M1owgYQxCzAJ BgNVBAYTAlVTMQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRgwFgYDVQQDEw9UaW1v dGh5IEouIEhhaG4xGTAXBgoJkiaJk/IsZAEBEwkxMjg4NTc4OTcxHzAdBgkqhkiG9w0BCQEWEGhh aG50QHVzLmlibS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMZRHQYCNd56O2LkRqmV bpvr70BMnmNf+UWqMbgJ0v8Y5Vb3hdrThAoyNs3XKbFl9oYir3AFiZHVPUpFM2anK8+Sb9IqzfIh g/x6Tu9wVHPXkve+wBCGneHD2GgvIx7NEECdr7YuOd7SWevXcLloLu3yQ7Hb2aZ1MQ8o78M9S7K1 AgMBAAGjgbwwgbkwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQU z9GrkTcJqnyWERTvptgBPQmzC/QwKwYDVR0RBCQwIqAgBgorBgEEAYI3FAIDoBIMEGhhaG50QHVz LmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7zSkAwJwYDVR0lBCAwHgYIKwYB BQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0BAQQFAAOBgQCHcqGsmuSPRftlK36s f5HfVXRhzCbH63xR5jLTpzFIfzoNo8u8yeC2yu81Ylj3rLzKmcwNtb9rkQT+wqWJH498ECe66dOQ 6tUDHk3VYGYZ3QrerjTBWBnKoekfUMcp+9xtjsHYVfMEopW/0FU6QsMwj3vouSy6Uv5nTGxKIi73 ZzCCAyIwggKLoAMCAQICAk41MA0GCSqGSIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQK EytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJ Qk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDIxMTIxMTMwNjUzWhcNMDMxMjA1MTMwNjUz WjCBhDELMAkGA1UEBhMCVVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxGDAWBgNV BAMTD1RpbW90aHkgSi4gSGFobjEZMBcGCgmSJomT8ixkAQETCTEyODg1Nzg5NzEfMB0GCSqGSIb3 DQEJARYQaGFobnRAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxlEdBgI1 3no7YuRGqZVum+vvQEyeY1/5RaoxuAnS/xjlVveF2tOECjI2zdcpsWX2hiKvcAWJkdU9SkUzZqcr z5Jv0irN8iGD/HpO73BUc9eS977AEIad4cPYaC8jHs0QQJ2vti453tJZ69dwuWgu7fJDsdvZpnUx Dyjvwz1LsrUCAwEAAaOBvDCBuTARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G A1UdDgQWBBTP0auRNwmqfJYRFO+m2AE9CbML9DArBgNVHREEJDAioCAGCisGAQQBgjcUAgOgEgwQ aGFobnRAdXMuaWJtLmNvbTAfBgNVHSMEGDAWgBSuVA6S6qgzqSskLcfIbzDc3vNKQDAnBgNVHSUE IDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBAIdyoaya 5I9F+2Urfqx/kd9VdGHMJsfrfFHmMtOnMUh/Og2jy7zJ4LbK7zViWPesvMqZzA21v2uRBP7CpYkf j3wQJ7rp05Dq1QMeTdVgZhndCt6uNMFYGcqh6R9Qxyn73G2OwdhV8wSilb/QVTpCwzCPe+i5LLpS /mdMbEoiLvdnMYIBujCCAbYCAQEwbzBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRp b25hbCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5AgJONTAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDExMzEyNTcyOFowIwYJKoZIhvcNAQkEMRYEFOG38R/9EyqC 8HEJ4kuOlzKEKP95MEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcNAwICAgCAMAoG CCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAGn7zLvGANF8zEbIlyC1H 7Ao8DxZgFh67p0uolSucYBU8L7BZtdcUrkwIkG6BISRSV8YctWodv0gXqXIQpLf0YDqgeX3M3uVQ 8upw4OIlqpV8fBhGV5QwMfwQmLAtXCGHwoViDRre+rZbB/fnjOO8f6IppbHdpDs08rT6JYh/Bh0A AAAA ---------z35712_boundary_sign-- From owner-ietf-pkix Mon Jan 13 06:54:59 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0DEsxr09569 for ietf-pkix-bks; Mon, 13 Jan 2003 06:54:59 -0800 (PST) Received: from kraid.nerim.net (smtp-101.nerim.net [62.4.16.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0DEswo09565 for ; Mon, 13 Jan 2003 06:54:58 -0800 (PST) Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by kraid.nerim.net (Postfix) with ESMTP id DDD3840E35 for ; Mon, 13 Jan 2003 15:37:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id 9C60449F4 for ; Mon, 13 Jan 2003 15:50:17 +0100 (CET) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id 3FB0249F2 for ; Mon, 13 Jan 2003 15:50:17 +0100 (CET) Received: by callisto.cry.pto (sSMTP sendmail emulation); Mon, 13 Jan 2003 15:50:17 +0100 From: "Julien Stern" Date: Mon, 13 Jan 2003 15:50:17 +0100 To: ietf-pkix@imc.org Subject: SubjectAltName comparison question. Message-ID: <20030113145017.GA31298@cryptolog.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Virus-Scanned: by AMaViS new-20020517 X-Razor-id: e932746e49fd0a29e60537b1b8b6a261b931b661 X-Spam-Status: No, hits=-4.6 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, sorry if this is a multi-faq, I checked the archives but could not find it. In short the question is: are DN comparisons somewhat inconsistent with comparisons on equivalent fields in SubjectAltName and IssuerAltName in RFC3280 ? More precisely, RFC3280 says in 4.1.2.4: (b) attribute values in types other than PrintableString are case sensitive (this permits matching of attribute values as binary objects); So, because email addresses and domain components are represented as Ia5Strings, I understand that they should be entirely matched in a case sensitive manner. Now, the same RFC in 4.2.1.7 defines matching rules for rfc822Name (fully case insensitive according to the RFC, and already questionned on the list by Steve Hanna, if I remember correctly), and for dNSName (fully case insensitive). So, if one choose to put an email attribute or a domain components attribute in a DN inside a GeneralName, the matching will not be the same as if the email or the domain components are put in an rfc822Name or a dNSName inside a GeneralName ? Now, Pkcs9Email is a legacy attribute, so this might not be a big deal, but domainComponent is not, and it is explicitely stated in 4.2.1.7 that "a DNS name MAY be represented in the subject field using the domainComponent attribute as described in section 4.1.2.4." So, it seems to me that we have two legal representations for DNS names, which are not equivalent, as they should be matched differently. -- Julien Stern Cryptolog International From owner-ietf-pkix Mon Jan 13 11:06:33 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0DJ6Xw19250 for ietf-pkix-bks; Mon, 13 Jan 2003 11:06:33 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0DJ6Vo19246 for ; Mon, 13 Jan 2003 11:06:31 -0800 (PST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 13 Jan 2003 11:06:27 -0800 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 13 Jan 2003 11:06:27 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 13 Jan 2003 11:06:27 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 13 Jan 2003 11:06:27 -0800 Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3718.0); Mon, 13 Jan 2003 11:06:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message Subject: RE: WG Last Call: Logotypes MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Jan 2003 11:06:26 -0800 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD063C439E@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: Logotypes thread-index: AcK4vGYJ0TbmI5bnS+yPVgLest4BagCdpGCw From: "Trevor Freeman" To: "Denis Pinkas" Cc: , , , "Tim Polk" X-OriginalArrivalTime: 13 Jan 2003 19:06:27.0466 (UTC) FILETIME=[DFA696A0:01C2BB36] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0DJ6Vo19247 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, Let me clarify why the document today only places the requirement on the CA for image sizes so you will understand that the asymmetry between CA and client requirements was quite deliberate. A UI designer has to balance the functions which need to be performed with the real-estate available. For the general case, we have defined a format which should reasonably support any logotype which the UI designer can reasonably rely on being available. If they want they can of course allow the display of larger images at their discretion and local policy. However, since some logotypes can be displayed in a smaller size, we did not want to exclude their use either which in situations where there in minimal real-estate available could mean the deference between some or no logotypes. Those restrictions could be universal such as on a small hand held device so it could conceivably mean a device never displays a 60x45 image. I therefore don't agree that we should mandate any display requirements on the client. At most we can recommend what they do, but ultimately it's down to the implementer to make the best job given the restrictions they are under. Trevor -----Original Message----- From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] Sent: Friday, January 10, 2003 7:24 AM To: Russ Housley Cc: ietf-pkix@imc.org; kent@bbn.com; stefan@addtrust.com; Trevor Freeman; Tim Polk Subject: Re: WG Last Call: Logotypes Russ, Thanks for your prompt answer. > Denis: > >>> This message initiates working group Last Call for the logotypes >>> document. In light of holiday schedules, Last Call will run for >>> three weeks rather than two weeks. That is, Last Call will not close >>> before January 13. The URL for this Internet-Draft is: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-09.txt >>> The editors have informed us that "all of the items briefed at the >>> meeting in Atlanta as well as the request by the chairs have been >>> handled. In addition, a few comments from working group members that >>> sent us email have been addressed." >> >> >> I acknowledge the fact that many improvements have been done to the >> specification. >> >> However I have two remaining concerns: >> >> 1. In order to try to solve the minimum interoperability requirements >> between an application and a certificate issuer, the characteristics >> of the size of the picture have been indicated in the following way: >> >> At least one of the image files representing a logotype SHOULD >> contain an image within the size range of 60 pixels wide by 45 pixels >> high and 200 pixels wide by 150 pixels high. >> >> This does not say what whether a client is able or not to display >> logos, which was the basic question. >> >> I suggest to mandate clients to support at least images within the >> size range of 60 pixels wide by 45 pixels. This sentence does not >> exist in the document and should be added. > > > I have no problem with this addition. Fine. >> 2. I have indicated that it would be nice to have an optional pointer >> to a web site where more information could be obtained about the logo. >> This is currently not possible with the current definition. From a >> non-technical point of view, it would be a very nice marketing tool. >> >> This can easily be accomplished by adding one OPTIONAL element in the >> ASN.1 syntax. > > > This addition opens a huge can of worms. I would prefer to leave the > lid tightly sealed. I would rather go fishing with that huge can of worms. :-) > The certificate issuer would be including a reference in the certificate > to information that is maintained by another party, and that other party > could make unacceptable changes after certificate issuance. The usual > mechanism to handle this situation is to include a hash value of the > referenced object, preventing any changes. However, in this context, > this does not seem like an appropriate thing to do. The organization > that owns the logo will surely want to make changes to their web page. > And, it is not easy to handle links form that web page. Handling links > would require the definition of complicated canonicalization rules. The basic question is what the link contains. The intent is not to point to a link where you have the exact meaning of the logo, but to the entry point of a web site. Here is an example for such a URL: http://www.cartes-bancaires.com/GB/Pages/Accueil2.htm So we need to carefully state what the link contains. Denis > Russ > > From owner-ietf-pkix Mon Jan 13 22:55:32 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0E6tW506211 for ietf-pkix-bks; Mon, 13 Jan 2003 22:55:32 -0800 (PST) Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0E6tUo06207 for ; Mon, 13 Jan 2003 22:55:30 -0800 (PST) Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by mailc.telia.com (8.12.5/8.12.5) with SMTP id h0E6tWFI016016 for ; Tue, 14 Jan 2003 07:55:32 +0100 (CET) X-Original-Recipient: Message-ID: <008501c2bb99$a21f0ed0$0500a8c0@arport> From: "Anders Rundgren" To: Subject: RFC3039/X.500 naming question Date: Tue, 14 Jan 2003 07:53:24 +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: Hi, A colleague of mine claims that the DN "CN=Marion Anderson, serialNumber=nnnnnnnnnnnn, C=SE" denotes a Swedish citizen according to ISO/ITU standards. This makes the DN string globally unique as as it would be a "violation" to use the same naming scheme for expressing lets say "members" of some kind of organization "associated" to Sweden. I claim that this is a "convention" (maybe even "good practice") but that this statement at least has no support in PKIX RFCs. RFC3039 which should be close to this issue is BTW absolutely mum about what "C" actually means. Thoughts? cheers. Anders Rundgren From owner-ietf-pkix Tue Jan 14 01:49:31 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0E9nV704806 for ietf-pkix-bks; Tue, 14 Jan 2003 01:49:31 -0800 (PST) Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0E9nTo04801 for ; Tue, 14 Jan 2003 01:49:29 -0800 (PST) Received: from Santesson ([213.64.1.87]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 14 Jan 2003 10:49:27 +0100 From: "Stefan Santesson" To: "Anders Rundgren" , Subject: RE: RFC3039/X.500 naming question Date: Tue, 14 Jan 2003 10:49:26 +0100 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.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <008501c2bb99$a21f0ed0$0500a8c0@arport> X-OriginalArrivalTime: 14 Jan 2003 09:49:28.0171 (UTC) FILETIME=[3A9C9BB0:01C2BBB2] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Anders, Comments in line; > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Anders Rundgren > Sent: Tuesday, January 14, 2003 7:53 AM > To: ietf-pkix@imc.org > Subject: RFC3039/X.500 naming question > > > > Hi, > > A colleague of mine claims that the DN > > "CN=Marion Anderson, serialNumber=nnnnnnnnnnnn, C=SE" > > denotes a Swedish citizen according to ISO/ITU standards. What ISO/ITU Standard would that be? My guess is that your colleague is wrong. There is at least nothing in RFC 3280 or RFC 3039 that support that statement. > This makes the DN string globally unique as as it would be a > "violation" to use the same naming scheme for expressing > lets say "members" of some kind of organization "associated" to Sweden. Again that is not necessarily true. A RP can not assume globally uniqueness just based on the information you supply here. RFC 3039 provide a mechanism where you could define semantics fro these attributes so that the RP could have this information and knowledge about the name uniqueness. > > I claim that this is a "convention" (maybe even "good practice") > but that this statement at least has no support in PKIX RFCs. > RFC3039 which should be close to this issue is BTW absolutely > mum about what "C" actually means. Actually not. RFC 3039 section 3.1.2 says: The countryName attribute value specifies a general context in which other attributes are to be understood. The country attribute does not necessarily indicate the subject's country of citizenship or country of residence, nor does it have to indicate the country of issuance. Note: Many X.500 implementations require the presence of countryName in the DIT. In cases where the subject name, as specified in the subject field, specifies a public X.500 directory entry, the countryName attribute SHOULD always be present. /Stefan > > Thoughts? > > cheers. > Anders Rundgren > > > > > From owner-ietf-pkix Tue Jan 14 02:19:07 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0EAJ7706328 for ietf-pkix-bks; Tue, 14 Jan 2003 02:19:07 -0800 (PST) Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0EAJ6o06322 for ; Tue, 14 Jan 2003 02:19:06 -0800 (PST) Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by mailc.telia.com (8.12.5/8.12.5) with SMTP id h0EAJ5pc010186; Tue, 14 Jan 2003 11:19:05 +0100 (CET) X-Original-Recipient: ietf-pkix@imc.org Message-ID: <012901c2bbb6$11d292d0$0500a8c0@arport> From: "Anders Rundgren" To: "Stefan Santesson" , References: Subject: Re: RFC3039/X.500 naming question Date: Tue, 14 Jan 2003 11:16: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: Thanx Stefan, some minor "return-data". >> A colleague of mine claims that the DN >> >> "CN=Marion Anderson, serialNumber=nnnnnnnnnnnn, C=SE" >> >> denotes a Swedish citizen according to ISO/ITU standards. >What ISO/ITU Standard would that be? The ones that are the foundation for X.500, that's all I know. >My guess is that your colleague is wrong. There is at least nothing in RFC >3280 or RFC 3039 that support that statement. So I have understood it as well. But he claims that you must FIRST read the ISO/ITU-stuff which is NORMATIVE and then see what's fits with the PKIX RFCs. I find this both awkard and unrealistic. >> I claim that this is a "convention" (maybe even "good practice") >> but that this statement at least has no support in PKIX RFCs. >> RFC3039 which should be close to this issue is BTW absolutely >> mum about what "C" actually means. >Actually not. >RFC 3039 section 3.1.2 says: > The countryName attribute value specifies a general context in which > other attributes are to be understood. The country attribute does > not necessarily indicate the subject's country of citizenship or > country of residence, nor does it have to indicate the country of > issuance. Well, "mum" was an exaggeration of mine, but it is pretty clear that "C" do not carry huge semantic weight in RFC3039. Which IMO is perfectly OK. Anders From owner-ietf-pkix Tue Jan 14 07:32:19 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0EFWJb24386 for ietf-pkix-bks; Tue, 14 Jan 2003 07:32:19 -0800 (PST) Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0EFWGo24381 for ; Tue, 14 Jan 2003 07:32:17 -0800 (PST) Received: from localhost (217.215.93.181) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Tue, 14 Jan 2003 16:30:10 +0100 Date: Tue, 14 Jan 2003 16:28:00 +0100 (CET) Message-ID: <20030114.162800.63997334.levitte@lp.se> To: anders.rundgren@telia.com CC: stefan@addtrust.com, ietf-pkix@imc.org Subject: Re: RFC3039/X.500 naming question From: Richard Levitte - VMS Whacker In-Reply-To: <012901c2bbb6$11d292d0$0500a8c0@arport> References: <012901c2bbb6$11d292d0$0500a8c0@arport> X-URL: http://www.lp.se/ X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1 X-Mew: See http://www.mew.org/ X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) MIME-Version: 1.0 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: In message <012901c2bbb6$11d292d0$0500a8c0@arport> on Tue, 14 Jan 2003 11:16:54 +0100, "Anders Rundgren" said: anders.rundgren> >> A colleague of mine claims that the DN anders.rundgren> >> anders.rundgren> >> "CN=Marion Anderson, serialNumber=nnnnnnnnnnnn, C=SE" anders.rundgren> >> anders.rundgren> >> denotes a Swedish citizen according to ISO/ITU standards. anders.rundgren> anders.rundgren> >What ISO/ITU Standard would that be? anders.rundgren> anders.rundgren> The ones that are the foundation for X.500, that's all I know. I think your colleague should say exactly what he or she means, or we can discuss endlessly and in loops... You can't really throw something like "the ISO/ITU Standards" and assume that everyone knows what you're talking about. I'm assuming that what's meant is X.520, which mentions a number of attribute types. All those used in the DN above exist according to that document. Note that the ISO/ITU standards (at least those I have a copy of) say nothing about swedish citizen, so the fact that swedish citizen get a DN like the above is outside the scope of ISO/ITU and has been documented somewhere else. So the question "What ISO/ITU Standard would that be?" is pretty well founded. anders.rundgren> >My guess is that your colleague is wrong. There is anders.rundgren> >at least nothing in RFC 3280 or RFC 3039 that anders.rundgren> >support that statement. anders.rundgren> anders.rundgren> So I have understood it as well. But he claims that anders.rundgren> you must FIRST read the ISO/ITU-stuff which is anders.rundgren> NORMATIVE and then see what's fits with the PKIX anders.rundgren> RFCs. I find this both awkard and unrealistic. That actually depends entirely on your base of operation. PKIX document the use of certificates and PKI for the Internet, so if you base your operation on the Internet, the PKIX documents would be normative. You would however have to find all the missing pieces in the ISO/ITU documents :-/. At least that's how I understand things. Am I alone in this belief? (from a personal point of view: when I started playing with PKI, I did start with the ISO/ITU documents I could get hold of, and then went on to the RFCs. However, since my business is based on the Internet, I base my work on the letter of the RFCs first) -- Richard Levitte | http://richard.levitte.org/ | Spannv. 38, I Levitte Programming | http://www.lp.se/ | S-168 35 Bromma T: +46-708-26 53 44 | | SWEDEN "Price, performance, quality... choose the two you like" From owner-ietf-pkix Tue Jan 14 08:01:45 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0EG1jd26034 for ietf-pkix-bks; Tue, 14 Jan 2003 08:01:45 -0800 (PST) Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0EG1io26030 for ; Tue, 14 Jan 2003 08:01:44 -0800 (PST) Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id ; Tue, 14 Jan 2003 11:01:39 -0500 Message-ID: <9A4F653B0A375841AC75A8D17712B9C9031C400A@sottmxs04.entrust.com> From: Sharon Boeyen To: "'Russ Housley'" , Timothy Hahn Cc: ietf-pkix@imc.org Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option) Date: Tue, 14 Jan 2003 11:01:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BBE6.389E3600" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BBE6.389E3600 Content-Type: text/plain Russ I want to add my support to your comment about interoperability. In particular I think we need to be careful about anything that would require changes/additions to clients. Existing deployed PKIX clients will be around for quite some time and need to be accomodated in anticipated environments. The only way to do that with this proposal would be to require that all servers follow the traditional userCertificate schema and some could, in addition to that, add these child entries for enhanced clients. Even that approach would require some way for the enhanced client to know which servers support the enhancements. otherwise they'd be sending a lot of requests that wouldn't succeed and they'd need to re-request the old way. Its also not fine for the PKI application to say that clients and servers will figure out which ones they are compatible with and work with those alone. That model is limited to closed environments and creates isolated islands of interoperability. PKIX requires a mechanism that enables clients to be able to access the data they need to build and validate cert paths and separating servers into some that follow a compatible schema and others that don't would significantly hinder that ability. A few years ago I remember participating in discussions about the crossCertificatePairs attribute and how complex that one is. It would be wonderful to replace that single overloaded attribute with at least two separate attributes (one for certs issued "to" this CA and a separate one for certs issued "by" this CA). While many of those in that discussion, myself included, agreed that this would be a great thing to do we decided NOT to try to make that change for exactly this same reason. Existing clients need to be accomodated and making such a change can only be done gracefully by requiring that all CAs publish the old way and some may also publish the new way. It then becomes very difficult to determine a point in time at which you can turn off the old schema and rely solely on the new one. Sharon -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Friday, January 10, 2003 2:31 PM To: Timothy Hahn Cc: ietf-pkix@imc.org Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option) Tim: In the PKIX WG, we have learned a hard lesson about letting two standard that accomplish the same goal progress. The "let the market decide" has lead to camps that implement the alternatives, but do not interoperate with each other, even if they know why they do not interoperate. I do not want to repeat this mistake. Russ At 08:40 AM 1/7/2003 -0500, Timothy Hahn wrote: >Russ, > >Great question. Simply - it gives the "client" the opportunity to >establish whether or not it can or cannot support retrieval of the >information from that data source (directory sub-tree). Client and server >implementations choose which protocols and data models they're going to >"support" all the time. As long as both support the same model(s), then >they interoperate. My proposal is that we define one way to identify which >data model(s) is(are) employed, so that servers and clients can determine >whether they are capable of supporting the formats. If they are not >capable, they can gracefully fail. > >The client can be made as "fat" or as "lean" as the implementer wants, >because the implementer can decide which formats to support. If the >implementer decides to support one while another part of the industry tends >to support another - well, then that particular implementation will get >"fatter" because it will wind up supporting both. > >My premise is that there is not a single data model that "fits" for ALL >applications/deployments. And because of that, multiple data models can >and will (in real-world scenarios) exist. So why not accept this, define a >(singular) way of identifying which model is used, and move on. At least >in this way, if a particular implementation/application has a need to store >things in a different way, it can, and we can still hope for >interoperability through IETF documents. > >Regards, >Tim Hahn > >Internet: hahnt@us.ibm.com >Internal: Timothy Hahn/Durham/IBM@IBMUS >phone: 919.224.1565 tie-line: 8/687.1565 >fax: 919.224.2540 > >|+-----------------------+------------------------------------------------| >|| Russ Housley | | >|| || m> | Hahn/Durham/IBM@IBMUS | >|| | cc: ietf-pkix@imc.org | >|| 01/06/2003 04:28 PM | Subject: Re: LDAP PKI Schema | >|| | (was Re: No-op LDAP ;binary option) | >|| | | >|| | | >|+-----------------------+------------------------------------------------| > > > > > >Tim: > >I do not understand how a client is better off with multiple ways to put >the same information in the Directory. Doesn't this approach just make the >client fat? It seem to me that the client would have to support all of the >possible ways that the information could be stored. It cannot know which >method it will encounter until it starts looking at data in the Directory. > >Russ > > >At 03:14 PM 1/6/2003 -0500, Timothy Hahn wrote: > >Hello all, > > > >After listening to the different view-points on this topic, it seems to me > >that there are multiple valid approaches. These approaches include, but > >are not limited to: > > - leveraging the general solution of component-matching > > - new schema to support application-managed componentization of > >information to make things searchable > >as well as others (additional matching rules, for example). > > > >It occurs to me that perhaps we have a situation where "one size does not > >fit all". Why not accept this and define a way for applications to > >determine which (of possibly multiple) format(s) has been used to place >the > >information into the directory? We could define some small bit of schema > >which indicates the way in which the certificate information is placed >into > >the directory, then different applications could query this and determine: > > - whether they can use the data at all > > - if they can use the data, how they can best use it (if there are, for > >example, multiple mechanisms employed). > > > >Just a thought to get us through this discussion. > > > >Regards, > >Tim Hahn > > ------_=_NextPart_001_01C2BBE6.389E3600 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option)

Russ I want to add my support to your comment about = interoperability. In particular
I think we need to be careful about anything that = would require changes/additions to
clients. Existing deployed PKIX clients will be = around for quite some time and need
to be accomodated in anticipated environments. The = only way to do that with this proposal
would be to require that all servers follow the = traditional userCertificate schema and
some could, in addition to that, add these child = entries for enhanced clients. Even that
approach would require some way for the enhanced = client to know which servers support the
enhancements. otherwise they'd be sending a lot of = requests that wouldn't succeed and they'd
need to re-request the old way. Its also not fine = for the PKI application to say that clients
and servers will figure out which ones they are = compatible with and work with those alone. 
That model is limited to closed environments and = creates isolated islands of interoperability.
PKIX requires a mechanism that enables clients to be = able to access the data they need to build
and validate cert paths and separating servers into = some that follow a compatible schema and others
that don't would significantly hinder that ability. =

A few years ago I remember participating in = discussions about the crossCertificatePairs attribute and
how complex that one is. It would be wonderful to = replace that single overloaded attribute with at least
two separate attributes (one for certs issued = "to" this CA and a separate one for certs issued = "by" this
CA). While many of those in that discussion, myself = included, agreed that this would be a great thing to
do we decided NOT to try to make that change for = exactly this same reason. Existing clients need to be
accomodated and making such a change can only be = done gracefully by requiring that all CAs publish the old
way and some may also publish the new way. It then = becomes very difficult to determine a point in time
at which you can turn off the old schema and rely = solely on the new one.

Sharon


-----Original Message-----
From: Russ Housley [mailto:housley@vigilsec.com]
Sent: Friday, January 10, 2003 2:31 PM
To: Timothy Hahn
Cc: ietf-pkix@imc.org
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP = ;binary option)



Tim:

In the PKIX WG, we have learned a hard lesson about = letting two standard
that accomplish the same goal progress.  The = "let the market decide" has
lead to camps that implement the alternatives, but = do not interoperate with
each other, even if they know why they do not = interoperate.  I do not want
to repeat this mistake.

Russ


At 08:40 AM 1/7/2003 -0500, Timothy Hahn = wrote:



>Russ,
>
>Great question.  Simply - it gives the = "client" the opportunity to
>establish whether or not it can or cannot = support retrieval of the
>information from that data source (directory = sub-tree).  Client and server
>implementations choose which protocols and data = models they're going to
>"support" all the time.  As long = as both support the same model(s), then
>they interoperate.  My proposal is that we = define one way to identify which
>data model(s) is(are) employed, so that servers = and clients can determine
>whether they are capable of supporting the = formats.  If they are not
>capable, they can gracefully fail.
>
>The client can be made as "fat" or as = "lean" as the implementer wants,
>because the implementer can decide which formats = to support.  If the
>implementer decides to support one while another = part of the industry tends
>to support another - well, then that particular = implementation will get
>"fatter" because it will wind up = supporting both.
>
>My premise is that there is not a single data = model that "fits" for ALL
>applications/deployments.  And because of = that, multiple data models can
>and will (in real-world scenarios) exist.  = So why not accept this, define a
>(singular) way of identifying which model is = used, and move on.  At least
>in this way, if a particular = implementation/application has a need to store
>things in a different way, it can, and we can = still hope for
>interoperability through IETF documents.
>
>Regards,
>Tim Hahn
>
>Internet: hahnt@us.ibm.com
>Internal: Timothy Hahn/Durham/IBM@IBMUS
>phone: 919.224.1565     = tie-line: 8/687.1565
>fax: 919.224.2540
>
>|+-----------------------+---------------------------------= ---------------|
>||   Russ = Housley        = |            = ;            = ;            = ;            = |
>||   = <housley@vigilsec.co|        =    To:        = Timothy           = ;        |
>||   = m>           &= nbsp;      |   = Hahn/Durham/IBM@IBMUS        &nb= sp;           &nb= sp;   |
>||        = ;            = ;   = |           = cc:        = ietf-pkix@imc.org         = |
>||   01/06/2003 04:28 PM = |           = Subject:        Re: LDAP PKI = Schema  |
>||         &nb= sp;           &nb= sp; |   (was Re: No-op LDAP ;binary = option)          |
>||         &nb= sp;           &nb= sp; = |            = ;            = ;            = ;            = |
>||         &nb= sp;           &nb= sp; = |            = ;            = ;            = ;            = |
>|+-----------------------+---------------------------------= ---------------|
>
>
>
>
>
>Tim:
>
>I do not understand how a client is better off = with multiple ways to put
>the same information in the Directory.  = Doesn't this approach just make the
>client fat?  It seem to me that the client = would have to support all of the
>possible ways that the information could be = stored.  It cannot know which
>method it will encounter until it starts looking = at data in the Directory.
>
>Russ
>
>
>At 03:14 PM 1/6/2003 -0500, Timothy Hahn = wrote:
> >Hello all,
> >
> >After listening to the different = view-points on this topic, it seems to me
> >tha