From owner-ietf-pkix Sat Jan 2 08:22:27 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23889 for ietf-pkix-bks; Sat, 2 Jan 1999 08:22:27 -0800 (PST) Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23883 for ; Sat, 2 Jan 1999 08:22:24 -0800 (PST) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id FAA31355 for ; Sun, 3 Jan 1999 05:22:49 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91529416913470>; Sun, 3 Jan 1999 05:22:49 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org Subject: CRL reason codes Reply-To: pgut001@cs.auckland.ac.nz X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Sun, 3 Jan 1999 05:22:49 (NZDT) Message-ID: <91529416913470@cs26.cs.auckland.ac.nz> Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: While I was playing with CRL's today I found a somewhat annoying problem in the way the CRL reasons are defined: In two different locations they're defined as either an enumerated type (CRLReason) or a bit string (ReasonFlags). What this means is that a name like 'affiliationChanged' can be associated with the value 8 for a ReasonFlag but 3 for a CRLReason. This makes it a real pain for programmers because even with fascist range checking in the code it's quite possible to pass in a ReasonFlags keyCompromise where a function is expecting a CRLReason keyCompromise (you just end up with a 'superseded' instead). I can't think of any easy solution for this, but perhaps changing the ReasonFlags names so they end in 'Flag' (eg affiliationChanged vs affiliationChangedFlag) would help a bit. Another question about CRL's, what happens when a CA with a self-signed cert revokes its own cert? Is the cert regarded as valid for the purposes of authenticating the CRL, but invalid a few microseconds later once its revocation is read from the CRL? Peter. From owner-ietf-pkix Sat Jan 2 09:15:49 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA24085 for ietf-pkix-bks; Sat, 2 Jan 1999 09:15:49 -0800 (PST) Received: from mail.softcomca.com (softcomca.com [168.144.1.9]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA24081 for ; Sat, 2 Jan 1999 09:15:48 -0800 (PST) From: aarsenault@mail.spyrus.com Message-Id: <199901021715.JAA24081@mail.proper.com> Received: from phantom [168.144.1.30] by mail.softcomca.com (SMTPD32-4.07) id A37B11F0140; Sat, 02 Jan 1999 12:12:27 EDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: pgut001@cs.auckland.ac.nz (Peter Gutmann), ietf-pkix@imc.org Subject: Re: CRL reason codes Date: Sat, 02 Jan 1999 12:12:19 Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Peter: You asked: Another question about CRL's, what happens when a CA with a self-signed cert revokes its own cert? Is the cert regarded as valid for the purposes of authenticating the CRL, but invalid a few microseconds later once its revocation is read from the CRL? Gee, when I asked that same question about 3 weeks ago on this same list, all I got was deafening silence. As I noted in my posting on this topic, I've seen a CA revoke its own self-signed cert in the lab on two occasions. Some of the end-entity applications accepted the CRL as valid, and then revoked the cert; some rejected the CRL as invalid (it was signed with a revoked certificate); and some of the applications just died. I'm still interested in any consensus on what's "supposed" to happen in this case. Al Arsenault -- my own opinions; not representing those of my employer or any other organization; etc. etc. Oh, and Happy New Year, too! --------------------------------------------------------------------- This message has been posted from Mail2Web (http://www.mail2web.com/) --------------------------------------------------------------------- From owner-ietf-pkix Sun Jan 3 14:25:16 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA25161 for ietf-pkix-bks; Sun, 3 Jan 1999 14:25:16 -0800 (PST) Received: from springfield.SIMPSONS (rotek1.lnk.telstra.net [139.130.48.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25157 for ; Sun, 3 Jan 1999 14:25:14 -0800 (PST) Received: by SPRINGFIELD with Internet Mail Service (5.5.1960.3) id ; Mon, 4 Jan 1999 09:24:03 +1100 Message-ID: From: Andrew Probert To: "'Eric Bomarsi'" , ietf-pkix@imc.org Subject: RE: Cert Rqsts and Key Pairs Date: Mon, 4 Jan 1999 09:24:02 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I have used multiple certs for the same keypaire, where the device was a Web server, having multiple SSL ports e.g. www1a.site.com, www1b.site.com, www1c.site.com. These were virtual IP mapped onto differing services on the server. But the hardware crypto engine behind the scenes used the same keys, no matter which virtual / logical server was used. This simplified key management on the SSL server and especially in the hardware crypto. I'd be interested to hear the context in which you would use a PKIX MIB? Regards. Andew Probert Rotek Consulting http://www.rotek.com.au a Division of Secure Network Services Tel +61 3 9690 8877 Fax +61 3 9690 8171 > -----Original Message----- > From: Eric Bomarsi [SMTP:ebomarsi@xedia.com] > Sent: Thursday, December 31, 1998 5:57 AM > To: ietf-pkix@imc.org > Subject: Cert Rqsts and Key Pairs > > > Is there any practical reason why a network device would > need to generate multiple certificate requests each including > the same public/private key pair? Maybe for some reason > two cert rqsts would include the same key pair, but have > different distinguished names or extensions? > > I am writing a PKI MIB and need to determine the best way > for a pkiCertRqstEntry to reference a public/private key-pair: > > 1) include keypair info (algorithm and length) in pkiCertRqstEntry > such that the keypair is created along with the pkiCertRqstEntry. > This would limit the key-pair use to the single pkiCertRqstEntry. > > 2) create a separate pkiKeyPairTable where pkiKeyPairEntries > are referenced by pkiCertRqstEntries: > > 2a) If always 1 pkiCertRqstEntry to 1 pkiKeyPairEntry, then > I can use the same index for both tables. > > 2b) Otherwise (n pkiCertRqstEntries to 1 pkiKeyPairEntry) > a different index for the pkiCertRqstTable is necessary. > > Thanks in advance, > Eric Bomarsi > From owner-ietf-pkix Sun Jan 3 17:44:21 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA26570 for ietf-pkix-bks; Sun, 3 Jan 1999 17:44:21 -0800 (PST) Received: from zeus.planetworld.com (smtp.planetworld.com [38.234.12.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA26566; Sun, 3 Jan 1999 17:44:20 -0800 (PST) Received: by smtp.planetworld.com with Internet Mail Service (5.5.2232.9) id ; Sun, 3 Jan 1999 19:46:38 -0600 Message-ID: <410E16F6AD02D011A9A6080009F89C760B4205@smtp.planetworld.com> From: Bill Brice To: ietf-pkix@imc.org, "'ietf-smime@imc.org'" Subject: Impact of US Export Regulation changes on WG documents Date: Sun, 3 Jan 1999 19:46:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: PKIX and S/MIME lists: On Thursday, December 31 the US Department of Commerce, Bureau of Export Administration published it's awaited revised regulations on the export of Encryption Items. My purpose in bringing this to the attention of these lists it that many of the Work Group documents are in last call or near completion. The appropriate authors should consider whether the changes made by the BXA might impact these documents. The most significant change is that the allowable key lengths have been increased for export grade software. Previously, symmetric confidentiality ciphers were limited to 40-bits and asymmetric ciphers (such as RSA) used for key exchange were limited to 512 bits. The new regulations permit the following key lengths for export: Symmetric confidentiality algorithms RC2, RC4, RC5, DES and CAST: 56-bits Symmetric key exchange ciphers: 112 bits Asymmetric key exchange ciphers: 1024 bits This has the effect of permitting the export versions of such products as Microsoft Internet Explorer (CryptoAPI) and Netscape Communicator (PKCS#11) to, by default, use 56-bit DES and 1024-bit RSA. For certificate authorities, this has the impact of permitting browser based enrollment controls (Xenroll or KeyGen) to default to 1024-bit RSA worldwide (except the 7 bad countries). Between now and March 31, 1999 any manufacturer of encryption software may upgrade their export versions to the new bit levels by merely sending notice to the BXA. I'd like for Microsoft and Netscape to comment as to how quickly they expect to have crypto upgrades available for release. The relevant BXA link for the complete text is: http://www.bxa.doc.gov/Encryption/1231ERC.htm or http://www.bxa.doc.gov/PDF/1231ERC.pdf The relevant text covering mass-market software is quoted in the postscript. -Bill Brice, CEO AlphaTrust Corp. Postscript: (iv) Mass-market encryption software that has already been classified after a technical review and that has been released from EI controls under the provisions of this paragraph (b)(1) will be permitted for export and reexport under license exception TSU with increases of 56-bits for the confidentiality algorithm, the same or double the key length authorized for the confidentiality algorithm for symmetric algorithms for key exchange mechanisms and with key spaces of 512, 768 or up to and including 1024 bits for asymmetric algorithms for key exchange without an additional technical review, provided that there is no other change in the cryptographic functionality. Exporters must notify BXA in writing of the increase in the key length for the confidentiality algorithm, the asymmetric or symmetric key exchange algorithms, and include the original authorization number issued by BXA and the information identified in paragraphs (a)(2)(iii) through (v) of Supplement No. 6 to part 742 of the EAR (if this information was submitted previously, then only identify the modifications). BXA must receive such notification by March 31, 1999. (A) The notification should be sent to: Office of Strategic Trade and Foreign Policy Controls, Bureau of Export Administration, Department of Commerce, 14th Street and Pennsylvania Ave., N.W., Room 2705, Washington, D.C. 20230, Attn: Encryption Upgrade (B) A copy of the certification should be sent to: Attn: ENC Encryption Request Coordinator, P.O. Box 246, Annapolis Junction, MD 20701-0246 End Postscript. From owner-ietf-pkix Sun Jan 3 18:02:10 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA26764 for ietf-pkix-bks; Sun, 3 Jan 1999 18:02:10 -0800 (PST) Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA26760; Sun, 3 Jan 1999 18:02:08 -0800 (PST) Message-Id: <4.1.19990103174708.027a88a0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 03 Jan 1999 17:57:09 -0800 To: ietf-pkix@imc.org, ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: Impact of US Export Regulation changes on WG documents In-Reply-To: <410E16F6AD02D011A9A6080009F89C760B4205@smtp.planetworld.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 07:46 PM 1/3/99 -0600, Bill Brice wrote: >My purpose in bringing this to the attention of these >lists it that many of the Work Group documents are in >last call or near completion. The appropriate authors >should consider whether the changes made by the BXA >might impact these documents. Could you be a bit more explicit? What do you mean by "impact"? I hope you are not suggesting that we break backwards compatibility with S/MIME v2 by substituting one weak algorithm for another. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-pkix Sun Jan 3 18:51:42 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA27166 for ietf-pkix-bks; Sun, 3 Jan 1999 18:51:42 -0800 (PST) Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA27162; Sun, 3 Jan 1999 18:51:37 -0800 (PST) From: ESMOND_TONG@HP-HongKong-om1.om.hp.com Received: from hkmail.hkg.hp.com (root@hkmail.hkg.hp.com [15.19.68.29]) by palrel3.hp.com (8.8.6 (PHNE_14041)/8.8.5tis) with ESMTP id SAA23205; Sun, 3 Jan 1999 18:52:14 -0800 (PST) Received: from localhost (root@localhost) by hkmail.hkg.hp.com with SMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0 Openmail) id KAA13015; Mon, 4 Jan 1999 10:51:57 +0800 (HKG) X-OpenMail-Hops: 1 Date: Mon, 4 Jan 1999 10:51:49 +0800 Message-Id: Subject: Wassenaar Agreement MIME-Version: 1.0 TO: bill.brice@idtrust.com, ietf-pkix@imc.org, ietf-smime@imc.org Content-Type: text/plain; charset=US-ASCII; name="Wassenaar" Content-Disposition: inline; filename="Wassenaar" Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hello all, Have anybody/organization has ever evaluate the impact of the Wassenaar Arrangement in Dec 1998 about the dual use regulation on the global PKI market and whether this will cause a new barrier to the export of strong cryptographic technology from other non-us countries. In the past, non-US countries company like Ireland Balimore can export strong crypto. Will it be changed after the signing of the Wassenaar Arrangement. Best REegards, Esmond TONG From owner-ietf-pkix Sun Jan 3 19:29:09 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA01219 for ietf-pkix-bks; Sun, 3 Jan 1999 19:29:09 -0800 (PST) Received: from zeus.planetworld.com (smtp.planetworld.com [38.234.12.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA01212; Sun, 3 Jan 1999 19:29:07 -0800 (PST) Received: by smtp.planetworld.com with Internet Mail Service (5.5.2232.9) id ; Sun, 3 Jan 1999 21:31:27 -0600 Message-ID: <410E16F6AD02D011A9A6080009F89C760B420A@smtp.planetworld.com> From: Bill Brice To: ietf-pkix@imc.org, "'ietf-smime@imc.org'" Subject: RE: Impact of US Export Regulation changes on WG documents Date: Sun, 3 Jan 1999 21:31:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Not at all. There may be no impact. My posting is simply in response to many debates I've seen fly by on algorithm support. I'm merely suggesting that the technologists see if this has any impact. If there is none, then great. -----Original Message----- From: Paul Hoffman / IMC [mailto:phoffman@imc.org] Sent: Sunday, January 03, 1999 7:57 PM To: ietf-pkix@imc.org; ietf-smime@imc.org Subject: Re: Impact of US Export Regulation changes on WG documents At 07:46 PM 1/3/99 -0600, Bill Brice wrote: >My purpose in bringing this to the attention of these >lists it that many of the Work Group documents are in >last call or near completion. The appropriate authors >should consider whether the changes made by the BXA >might impact these documents. Could you be a bit more explicit? What do you mean by "impact"? I hope you are not suggesting that we break backwards compatibility with S/MIME v2 by substituting one weak algorithm for another. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-pkix Sun Jan 3 20:39:40 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA07943 for ietf-pkix-bks; Sun, 3 Jan 1999 20:39:40 -0800 (PST) Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA07939; Sun, 3 Jan 1999 20:39:39 -0800 (PST) Message-Id: <4.1.19990103203051.028c4270@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 03 Jan 1999 20:34:22 -0800 To: ietf-pkix@imc.org, ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: Wassenaar Agreement In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >Have anybody/organization has ever evaluate the >impact of the Wassenaar Arrangement in Dec 1998 >about the dual use regulation on the global PKI >market and whether this will cause a new barrier >to the export of strong cryptographic technology >from other non-us countries. I believe that neither the ietf-smime mailing list nor the ietf-pkix mailing lists is an appropriate place to discuss this. There are plenty of other discussion lists on which the Wassenaar Arrangement and its effects are being debated. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-pkix Mon Jan 4 02:59:55 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA10476 for ietf-pkix-bks; Mon, 4 Jan 1999 02:59:55 -0800 (PST) Received: from marcellus.cost.se (marcellus.cost.se [195.100.88.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA10472 for ; Mon, 4 Jan 1999 02:59:54 -0800 (PST) Received: from jimmie ([10.0.0.22]) by marcellus.cost.se (8.8.5/8.7.5) with SMTP id LAA11359; Mon, 4 Jan 1999 11:58:25 +0100 (MET) Message-Id: <3.0.3.32.19990104115945.00c09a10@mail.cost.se> X-Sender: nada@mail.cost.se X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 04 Jan 1999 11:59:45 +0100 To: aarsenault@mail.spyrus.com, pgut001@cs.auckland.ac.nz (Peter Gutmann), ietf-pkix@imc.org From: Nada Kapidzic Cicovic Subject: Re: CRL reason codes In-Reply-To: <199901021715.JAA24081@mail.proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 12:12 1/2/99, aarsenault@mail.spyrus.com wrote: >Peter: > >You asked: > >Another question about CRL's, what happens when a CA with a self-signed cert >revokes its own cert? Is the cert regarded as valid for the purposes of >authenticating the CRL, but invalid a few microseconds later once its >revocation is read from the CRL? > >Gee, when I asked that same question about 3 weeks ago on this same list, all I got was deafening silence. > >As I noted in my posting on this topic, I've seen a CA revoke its own self-signed cert in the lab on two occasions. Some of the end-entity applications accepted the CRL as valid, and then revoked the cert; some rejected the CRL as invalid (it was signed with a revoked certificate); and some of the applications just died. > >I'm still interested in any consensus on what's "supposed" to happen in this case. I suppose you should never "trust" a self-signed certificate in the first place. You should trust a CA's public key that you received in a trusted way and installed in your PSE. If the CRL was signed with the private key corresponding to your CA's trusted public key, then you regard all of the revocations from the CRL as valid (thus even the self-signed certificate is invalid, if you ever come to verifying it). You may raise the question about the way of getting the trusted CA's key. Even if it is sent in the form of a self-signed certificate, it should not be tested against the latest CRL, since you should trust the source of the key and the means of the transportation (out-of-band). So, in my opinion in this particular chicken-and-egg problem, the trusted public key is the oldest one. Regards, Nada > > Al Arsenault > >-- my own opinions; not representing those of my employer or any other organization; etc. etc. Oh, and Happy New Year, too! > > > > > > > > > >--------------------------------------------------------------------- >This message has been posted from Mail2Web (http://www.mail2web.com/) >--------------------------------------------------------------------- > > From owner-ietf-pkix Mon Jan 4 05:15:45 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA13267 for ietf-pkix-bks; Mon, 4 Jan 1999 05:15:45 -0800 (PST) Received: from thehub.knight-hub.com (root@thehub.knight-hub.com [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA13263 for ; Mon, 4 Jan 1999 05:15:44 -0800 (PST) Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id IAA31460; Mon, 4 Jan 1999 08:15:53 -0500 Message-Id: <4.1.19990104075715.00a87180@209.172.119.123> X-Sender: aarsenault#207.212.34.30@209.172.119.123 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 04 Jan 1999 08:11:38 -0500 To: Nada Kapidzic Cicovic , pgut001@cs.auckland.ac.nz (Peter Gutmann), ietf-pkix@imc.org From: Al Arsenault Subject: Re: CRL reason codes In-Reply-To: <3.0.3.32.19990104115945.00c09a10@mail.cost.se> References: <199901021715.JAA24081@mail.proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Nada, I'm a little unclear as to your logic here. At 11:59 AM 1/4/99 +0100, Nada Kapidzic Cicovic wrote: > > >I suppose you should never "trust" a self-signed certificate in the first >place. You should trust a CA's public key that you received in a trusted >way and installed in your PSE. > That's basically the scenario I'm talking about. I have obtained through out of band methods the public key of a CA that I trust. (Maybe it came on a tamper-resistant hardware token; maybe I got it by physically going to the CA workstation and copying it onto a floppy disk, which I hand carried back; maybe I used some other means to get it.) That public key is also contained in that CA's self-signed certificate. Then, the certificate containing the public key is listed on a CRL. If it makes a difference, the reason code can be "key compromise"; i.e., we believe that the private key corresponding to the "trusted" public key has been compromised. So - a certificate containing the key I trust has now been declared to be revoked. The declaration comes in a CRL, signed with the very private key that is now declared to be compromised. Do I believe it? >If the CRL was signed with the private key corresponding to your CA's >trusted public key, then you regard all of the revocations from the CRL as >valid (thus even the self-signed certificate is invalid, if you ever come >to verifying it). > Personally, that's my preference. I believe that if a certificate containing a public key is revoked, and the revocation notice (e.g., the CRL) is signed with the private key matching that public key, then the revocation notice should be treated as valid, and the certificate only marked revoked AFTER the revocation notice is processed. I'm interested in other people's opinions, though. >You may raise the question about the way of getting the trusted CA's key. >Even if it is sent in the form of a self-signed certificate, it should not >be tested against the latest CRL, since you should trust the source of the >key and the means of the transportation (out-of-band). > I think I disagree with this, although I'm not sure that I understand your point. If I get a new "trusted" key, I should check its revocation status before each use. Yes, self-signed keys should rarely if ever be revoked, but it might happen. (It reminds me of the old doctor joke: "Doctor, it hurts when I do this." "Well, don't do that." If it hurts when you revoke your own self-signed certificate, in general you shouldn't do it. But there might be a reason - the CA's private key might really have been compromised.) >So, in my opinion in this particular chicken-and-egg problem, the trusted >public key is the oldest one. > And if that oldest trusted public key has been compromised...? >Regards, > >Nada A variation on this occurs when that same key is used in multiple different self-signed certificates, and only one of them is marked as revoked. I personally believe that using the key this way is a bad idea, and hope that it never occurs, but I suppose that it's theoretically possible. Al Arsenault -- these are my opinions only. They do not necessarily reflect the opinions of my employer, or of any other organization with which I have a relationship. From owner-ietf-pkix Mon Jan 4 05:37:39 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA13404 for ietf-pkix-bks; Mon, 4 Jan 1999 05:37:39 -0800 (PST) Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA13399 for ; Mon, 4 Jan 1999 05:37:37 -0800 (PST) Received: from xedia.com by relay7.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfwsc28362; Mon, 4 Jan 1999 08:37:06 -0500 (EST) Received: from aruba by xedia.com (4.1/SMI-4.1) id AA03781; Mon, 4 Jan 99 08:34:11 EST Message-Id: <3690C400.1CA63025@xedia.com> Date: Mon, 04 Jan 1999 08:37:04 -0500 From: Eric Bomarsi Organization: xedia.com X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en Mime-Version: 1.0 To: Andrew Probert Cc: ietf-pkix@imc.org Subject: Re: Cert Rqsts and Key Pairs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Thanks Andrew, A few people have pointed out the need for multiple cert requests to use the same keypair, so it's clear that the keypair and cert request tables need to be separate. RE: I'd be interested to hear the context in which you would use a PKIX MIB? The PKI MIB I'm working on is for a VPN Gateway, but could be used for any networking device which supported PKI. It currently supports keypair and cert request generation, loading self and static certificates into the device, and a certificate table to manage all certs (self, static, dynamic) in the local database. I plan to add support for CRLs and LDAP client config soon. /Eric Bomarsi Andrew Probert wrote: > I have used multiple certs for the same keypaire, where the device was a > Web server, having multiple SSL ports e.g. www1a.site.com, > www1b.site.com, www1c.site.com. These were virtual IP mapped onto > differing services on the server. > > But the hardware crypto engine behind the scenes used the same keys, no > matter which virtual / logical server was used. This simplified key > management on the SSL server and especially in the hardware crypto. > > I'd be interested to hear the context in which you would use a PKIX MIB? > > Regards. > > Andew Probert > Rotek Consulting http://www.rotek.com.au > a Division of Secure Network Services > Tel +61 3 9690 8877 > Fax +61 3 9690 8171 > > > -----Original Message----- > > From: Eric Bomarsi [SMTP:ebomarsi@xedia.com] > > Sent: Thursday, December 31, 1998 5:57 AM > > To: ietf-pkix@imc.org > > Subject: Cert Rqsts and Key Pairs > > > > > > Is there any practical reason why a network device would > > need to generate multiple certificate requests each including > > the same public/private key pair? Maybe for some reason > > two cert rqsts would include the same key pair, but have > > different distinguished names or extensions? > > > > I am writing a PKI MIB and need to determine the best way > > for a pkiCertRqstEntry to reference a public/private key-pair: > > > > 1) include keypair info (algorithm and length) in pkiCertRqstEntry > > such that the keypair is created along with the pkiCertRqstEntry. > > This would limit the key-pair use to the single pkiCertRqstEntry. > > > > 2) create a separate pkiKeyPairTable where pkiKeyPairEntries > > are referenced by pkiCertRqstEntries: > > > > 2a) If always 1 pkiCertRqstEntry to 1 pkiKeyPairEntry, then > > I can use the same index for both tables. > > > > 2b) Otherwise (n pkiCertRqstEntries to 1 pkiKeyPairEntry) > > a different index for the pkiCertRqstTable is necessary. > > > > Thanks in advance, > > Eric Bomarsi > > From owner-ietf-pkix Mon Jan 4 07:14:59 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA13987 for ietf-pkix-bks; Mon, 4 Jan 1999 07:14:59 -0800 (PST) Received: from pluto.deh.de ([194.162.233.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA13983 for ; Mon, 4 Jan 1999 07:14:54 -0800 (PST) Received: from chappi.deh.de (chappi.deh.de [194.162.234.60]) by pluto.deh.de (8.9.1a/8.9.1) with ESMTP id QAA31361; Mon, 4 Jan 1999 16:14:56 +0100 Received: from deh.de (juergen.deh.de [194.162.234.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id QAA12776; Mon, 4 Jan 1999 16:15:09 +0100 Message-ID: <3690DB7F.6A80F5E7@deh.de> Date: Mon, 04 Jan 1999 16:17:19 +0100 From: Juergen Walter Reply-To: Juergen.Walter@deh.de X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: aarsenault@mail.spyrus.com, Peter Gutmann , ietf-pkix Subject: Re: CRL reason codes References: <199901021715.JAA24081@mail.proper.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Al, Peter, I have scanned the current drafts. The result is the same that Al has already found in the lab. I refer to the variable T in the certificate path validation chapter of the current draft. T is not specified. T is an arbitrary date in the past: [PKIX] "(d) the time, T, for which the validity of the path should be determined. (This may be the current date/time, or some point in the past.)" [PKIX] Hence, the certiifcate path validation algorithm is not well-defined. Actually, it depends on T. This may explain Al´s observations. Two additional requirements would solve the problem: (1) CRL signing certificate _must_ be valid at least until _nextUpdate_, and (2) in the unlikely event that the CRL signing key is compromised the CRL _must_ be reissued and _must_ signed with a key that certificate is valid at least until _nextUpdate_ of the reissued CRL. I do not know whether these requirements are (implicitly) contained in the current drafts or not. If they are, the remaining lines may be skipped. I assume that the CRL may be signed with a key that is present at the signed CRL in the following. Another issue is the authentication of CRLs. This depends on the key usage on the one side and on CRL content on the other side. Al and Peter has considered the case that the CA root key is used for both signing certificates and signing CRLs. But a different key usage is still allowed. Secondly, the CRL may contain _revocationDate_, _invalidityDate_, _reasonCode_, ... information. So, the _revocationReason_ of the root certificate comes into question. I would like to give the following (extremal) example. The CA signs its own CRL applying the CA´s private key. In the unlikely event that the CA´s private key is compromised disaster handling consists of publishing a CRL including an revocation entry for its own root key. When an application verifies the validity of a certificate signed with the compromised CA´s key the result must be "invalid". This result must be independent whether this certificate is present at the issued CRL or not. In addition, the _revocationDate_ and other information usually provided by CRL is not authenticated. The application knows only the latest date of revocation in this case, i. e. the date, when the CRL was retrieved. Furthermore, the application must be aware of fake CRLs. An attacker may issue a CRL without root certificate entry. Other reasons of revocation result in several scenarios. They differ in the amount of available information authenticated by the issued CRL. I think that the revocation of the CRL signing key is a matter of disaster management and bussiness continuity planning, respectively. These topics should be covered by the PKIX drafts such that the error situation described by Al no longer appears. Juergen aarsenault@mail.spyrus.com wrote: > > Peter: > > You asked: > > Another question about CRL's, what happens when a CA with a self-signed cert > revokes its own cert? Is the cert regarded as valid for the purposes of > authenticating the CRL, but invalid a few microseconds later once its > revocation is read from the CRL? > > Gee, when I asked that same question about 3 weeks ago on this same list, all I got was deafening silence. > > As I noted in my posting on this topic, I've seen a CA revoke its own self-signed cert in the lab on two occasions. Some of the end-entity applications accepted the CRL as valid, and then revoked the cert; some rejected the CRL as invalid (it was signed with a revoked certificate); and some of the applications just died. > > I'm still interested in any consensus on what's "supposed" to happen in this case. > > Al Arsenault > Juergen From owner-ietf-pkix Mon Jan 4 08:06:33 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA14375 for ietf-pkix-bks; Mon, 4 Jan 1999 08:06:33 -0800 (PST) Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [192.94.214.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA14371 for ; Mon, 4 Jan 1999 08:06:32 -0800 (PST) Received: by relay.hq.tis.com; id LAA05139; Mon, 4 Jan 1999 11:14:33 -0500 (EST) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.1) id xma005124; Mon, 4 Jan 99 11:14:19 -0500 Received: from balenson.hq.tis.com (balenson.hq.tis.com [10.33.80.11]) by clipper.hq.tis.com (8.9.1/8.9.1) with SMTP id LAA25665; Mon, 4 Jan 1999 11:02:42 -0500 (EST) Message-Id: X-Sender: balenson@pop.hq.tis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 04 Jan 1999 11:03:47 -0500 To: ietf-pkix@imc.org From: "David M. Balenson" Subject: REMINDER: Jan 6th Early Bird Deadline for NDSS '99 Cc: balenson@tis.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_915483827==_" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --=====================_915483827==_ Content-Type: text/plain; charset="us-ascii" --=====================_915483827==_ Content-Type: text/plain; charset="us-ascii" S A V E $ 7 0 O F F R E G I S T R A T I O N F E E ! ! R E G I S T E R B Y J A N U A R Y 6 , 1 9 9 9 THE INTERNET SOCIETY'S 1999 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM February 3-5, 1999 Catamaran Resort Hotel San Diego, California Program Chairs: Steve Kent, BBN Technologies Gene Tsudik, USC/Information Sciences Institute ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss99 KEYNOTE SPEAKER: Whitfield Diffie, Sun Microsystems. Co-author of "Privacy on the Line: The Politics of Wiretapping and Encryption." THIS YEAR'S TOPICS INCLUDE: - Secure Password-Based Protocol for Downloading a Private Key - A Real-World Analysis of Kerberos Password Security - Secure Remote Access to an Internal Web Server - Security and the User - Experimenting with Shared Generation of RSA Keys - Addressing the Problem of Undetected Signature Key Compromise - Practical Approach to Anonymity in Large Scale Electronic Voting Schemes - Securing the Internet's Exterior Routing Infrastructure - Distributed Policy Management for Java 1.2 - Distributed Execution with Remote Audit - An Algebra for Assessing Trust in Certification Chains - A Network Security Research Agenda - PGRIP: PNNI Global Routing Infrastructure Protection - A Cryptographic Countermeasure Against Connection Depletion Attacks - IPSec: Friend or Foe? EXPANDED PRE-CONFERENCE TECHNICAL TUTORIALS: - Principles of Network Security (Dr. Stephen T. Kent, BBN Technologies) - Optical Network Security (Jeff Ingle and Dr. Eric Harder, NSA) - Electronic Payment Systems (Dr. B. Clifford Neuman, USC/ISI) - Windows NT Security (Dominique Brezinski, Secure Computing Corp.) - Web Security and Beyond (Dr. B. Clifford Neuman, USC/ISI) - JAVA Security (Dr. Gary McGraw, Reliable Software Technologies) Full details and biographies at http://www.isoc.org/ndss99/technical.shtml --=====================_915483827==_ Content-Type: text/plain; charset="us-ascii" ---------------------------------------------------------------------- David M. Balenson, Publicity Chair, NDSS '99 TIS Labs at Network Associates, Inc. 3060 Washington Road, Suite 100, Glenwood, MD 21738 USA balenson@tis.com; 443-259-2358; fax 301-854-4731 --=====================_915483827==_-- From owner-ietf-pkix Mon Jan 4 08:35:40 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA14605 for ietf-pkix-bks; Mon, 4 Jan 1999 08:35:40 -0800 (PST) Received: from pluto.deh.de (pluto.deh.de [194.162.233.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA14601 for ; Mon, 4 Jan 1999 08:35:35 -0800 (PST) Received: from chappi.deh.de (chappi.deh.de [194.162.234.60]) by pluto.deh.de (8.9.1a/8.9.1) with ESMTP id RAA04902; Mon, 4 Jan 1999 17:36:02 +0100 Received: from deh.de (juergen.deh.de [194.162.234.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id RAA13073; Mon, 4 Jan 1999 17:36:17 +0100 Message-ID: <3690EE83.F0C44348@deh.de> Date: Mon, 04 Jan 1999 17:38:27 +0100 From: Juergen Walter Reply-To: Juergen.Walter@deh.de X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Nada Kapidzic Cicovic , Al Arsenault , Peter Gutmann , ietf-pkix Subject: Re: CRL reason codes References: <3.0.3.32.19990104115945.00c09a10@mail.cost.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Al, Nada, Peter, Do you know an example, where it is necessary to allow the CRL signed with a key that is on the same CRL? I think that a well-done key update of CRL signing key may help that this construction is avoidable. Apart from that I see the following cases: (1) CRL signing key compromise (see my last mail), (2) CA change of affiliation (i. e. a certification domain changes to another), (3) cessation of CA operation (Al´s lab observation?) I believe that the current PKIX drafts are quite silent about these topics. Nada, some comments in lines: > > I suppose you should never "trust" a self-signed certificate in the first > place. You should trust a CA's public key that you received in a trusted > way and installed in your PSE. I agree with you. But, this is a cost-intensive initialization procedure. Please note, that a CA´s key change is desirable unless the initialization procedure is repeated. > > If the CRL was signed with the private key corresponding to your CA's > trusted public key, then you regard all of the revocations from the CRL as > valid (thus even the self-signed certificate is invalid, if you ever come > to verifying it). > > You may raise the question about the way of getting the trusted CA's key. > Even if it is sent in the form of a self-signed certificate, it should not > be tested against the latest CRL, since you should trust the source of the > key and the means of the transportation (out-of-band). > > So, in my opinion in this particular chicken-and-egg problem, the trusted > public key is the oldest one. Surely, this is not applied, if the CRL signing key (= root key) is compromised. In the unlikely event of CRL signing key compromise the validation software must be aware of fake CRLs (especially additional CRL information). Apart from this case, I believe that the current certificate path validation algorithm does not work well. > > Regards, > > Nada > > Juergen From owner-ietf-pkix Mon Jan 4 08:04:58 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA14363 for ietf-pkix-bks; Mon, 4 Jan 1999 08:04:58 -0800 (PST) Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA14359 for ; Mon, 4 Jan 1999 08:04:56 -0800 (PST) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA11032 for ; Mon, 4 Jan 1999 17:05:33 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Mon, 4 Jan 1999 17:05:32 +0100 (MET) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id RAA15490 for ; Mon, 4 Jan 1999 17:05:32 +0100 From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id RAA06535 for ietf-pkix@imc.org; Mon, 4 Jan 1999 17:05:31 +0100 Date: Mon, 4 Jan 1999 17:05:31 +0100 Message-Id: <199901041605.RAA06535@emeriau.edelweb.fr> To: ietf-pkix@imc.org Subject: finding services : DCS, OCSP, Timestamping, .. Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: happy new year The current texts of DCS, OCSP, Timestaping do not specify how one can find the actual service. It seems useful to me to use some certificate extension. The service operate (or can operate) in 'signed' environments, thus a client has some knowledge of the public key of the service; there are some chances that this knowledge comes from a certificate. On the other hand the actual method of getting the service, http, ftp, xyz, and the addresses is not known. It seems logical to me to put extensions conforming to pkix part 1: 4.2.2.1 Authority Information Access into the certificate that describes the access point and method to that service. Peter Sylvester From owner-ietf-pkix Mon Jan 4 09:57:02 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA15251 for ietf-pkix-bks; Mon, 4 Jan 1999 09:57:02 -0800 (PST) Received: from pluto.deh.de (pluto.deh.de [194.162.233.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA15247 for ; Mon, 4 Jan 1999 09:57:00 -0800 (PST) Received: from chappi.deh.de (chappi.deh.de [194.162.234.60]) by pluto.deh.de (8.9.1a/8.9.1) with ESMTP id SAA07584; Mon, 4 Jan 1999 18:57:30 +0100 Received: from deh.de (juergen.deh.de [194.162.234.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id SAA13343; Mon, 4 Jan 1999 18:57:26 +0100 Message-ID: <3691018E.FFC0EA04@deh.de> Date: Mon, 04 Jan 1999 18:59:42 +0100 From: Juergen Walter Reply-To: Juergen.Walter@deh.de X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Al Arsenault , ietf-pkix Subject: Re: CRL reason codes References: <199901021715.JAA24081@mail.proper.com> <4.1.19990104075715.00a87180@209.172.119.123> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Al, > That's basically the scenario I'm talking about. I have obtained through > out of band methods the public key of a CA that I trust. (Maybe it came on > a tamper-resistant hardware token; maybe I got it by physically going to > the CA workstation and copying it onto a floppy disk, which I hand carried > back; maybe I used some other means to get it.) That public key is also > contained in that CA's self-signed certificate. > > Then, the certificate containing the public key is listed on a CRL. If it > makes a difference, the reason code can be "key compromise"; i.e., we > believe that the private key corresponding to the "trusted" public key has > been compromised. > > So - a certificate containing the key I trust has now been declared to be > revoked. The declaration comes in a CRL, signed with the very private key > that is now declared to be compromised. Do I believe it? In my opinion, you have to believe it. As a consequence, all certificates signed with the compromised key are invalid. Furthermore, it does not matter, whether the certificates are listed in the issued CRL. I have serious doubts that a validation software will detect this. The additional CRL informations (like revocation date, invalidity date, revocation reason, ...) are not authenticated. In this sense, your validation software must be aware of fake CRLs. > > >If the CRL was signed with the private key corresponding to your CA's > >trusted public key, then you regard all of the revocations from the CRL as > >valid (thus even the self-signed certificate is invalid, if you ever come > >to verifying it). > > > > Personally, that's my preference. I believe that if a certificate > containing a public key is revoked, and the revocation notice (e.g., the > CRL) is signed with the private key matching that public key, then the > revocation notice should be treated as valid, and the certificate only > marked revoked AFTER the revocation notice is processed. I'm interested in > other people's opinions, though. What is about the following case? Your validation software has to verify a certificate validity at T<"NOW". Supposed your software retrieves the CRL that contains a CRL entry for the CRL signing key, then you know that the revocation date is REV<"NOW", because the included revocation date is not properly authenticated. Your software is not able to decide, whether the certificate was valid at T. Otherwise, the certificate validation at T="NOW" would be still fine. Therefore, this handling is appropriate at least for those communities that set T="NOW". More sophisticated certificate validation (i.e. T<"NOW") requires additional certificate and revocation management. I think that the handling you described should be allowed. But, I am not sure, whether it is compliant to the current PKIX drafts or not. I would tend to say that it is not. [snip] > >Regards, > > > >Nada > > A variation on this occurs when that same key is used in multiple > different self-signed certificates, and only one of them is marked as > revoked. I personally believe that using the key this way is a bad idea, > and hope that it never occurs, but I suppose that it's theoretically possible. > I agree completely. This occurs when a CA operator wants to reuse the CA`s private key. In my opinion, the certificate path validation algorithm is quite clear. All certificates are invalid provided that one of the self-signed certificates is revoked. I dislike this reuse. -- Juergen From owner-ietf-pkix Mon Jan 4 10:49:52 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA15813 for ietf-pkix-bks; Mon, 4 Jan 1999 10:49:52 -0800 (PST) Received: from thehub.knight-hub.com (root@thehub.knight-hub.com [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA15809 for ; Mon, 4 Jan 1999 10:49:46 -0800 (PST) Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id NAA11552; Mon, 4 Jan 1999 13:50:00 -0500 Message-Id: <4.1.19990104133121.00a914a0@209.172.119.123> X-Sender: aarsenault#207.212.34.30@209.172.119.123 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 04 Jan 1999 13:45:44 -0500 To: Juergen.Walter@deh.de, Nada Kapidzic Cicovic , Peter Gutmann , ietf-pkix From: Al Arsenault Subject: Re: CRL reason codes In-Reply-To: <3690EE83.F0C44348@deh.de> References: <3.0.3.32.19990104115945.00c09a10@mail.cost.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 05:38 PM 1/4/99 +0100, Juergen Walter wrote: >Al, Nada, Peter, > >Do you know an example, where it is necessary to allow the CRL signed >with a key that is on the same CRL? > There are two scenarios I can think of. The first involves the compromise of the CA's private CRL-signing key, and the second involves cessation of CA operations. In the compromise case, there are at least two ways to avoid having a CRL signed with a key associated with a certificate that's on the list. The first involves the use of something like CRL Distribution Points and Indirect CRLs (ICRLs), where you have a "trusted authority" who can notify users that a CA's key has been compromised, and thus that any CRLs and/or new certificates from that CA should not be trusted. The second is to have pre-placed a "replacement" key; i.e., 'the current key used by the CA is key x, and the next key to be used by the CA will be key (x+1).' In the ICRL case, users have to go check a separate CRL (in addition to the CA's regular CRL) to ensure that the CA's cert hasn't been revoked. Other than this performance impact/user inconvenience, though, this approach works well as long as you can really trust the ICRL authority. Otherwise, you wind up with one node that can cause big-time denial of service problems, just by revoking CAs at will. In the "replacement" key approach, this works as long as key (x+1) is not compromised at the same time that key x is. If x is compromised, but (x+1) is not, then the CA switches to the new key, and sends out a CRL revoking any certificate associated with x. However, if x and (x+1) are compromised at the same time, you're back where you were when you didn't have a replacement key. If you don't have one of these two strategies - ICRL or replacement key - then I think that your only choice is to use the compromised key to sign a CRL revoking certificates associated with that very key. In the cessation of operations case, you can also use the ICRL approach to avoid signing with the key associated with the certificate to be revoked, because the ICRL Authority would outlive the CA. I suppose you could also use the replacement key approach, although it's not clear then how you'd revoke the certs associated with the replacement key (or if you'd really need to). Otherwise, you just live with the original problem. In this case, it seems clear to me that the "safe" thing to do is accept the CRL as valid, and then have applications refuse to honor the CA's key after that point. Al Arsenault -- these are my opinions only. They do not necessarily reflect the opinions of my employer, or of any other organization with which I have a relationship. From owner-ietf-pkix Tue Jan 5 09:51:38 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA19077 for ietf-pkix-bks; Tue, 5 Jan 1999 09:51:38 -0800 (PST) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA19073 for ; Tue, 5 Jan 1999 09:51:37 -0800 (PST) Received: id MAA08300; Tue, 5 Jan 1999 12:48:53 -0500 Received: by gateway id ; Tue, 5 Jan 1999 12:50:46 -0500 Message-ID: <91AE69321799D211AEC500105A9C4696196E9B@SOTHMXS05> From: Carlisle Adams To: "'Brian LaMacchia'" Cc: ietf-pkix@imc.org Subject: RE: CMC Comments? Date: Tue, 5 Jan 1999 12:49:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Brian, Now that I'm back after a long (but way too short!) Christmas break, let me jump in and address a couple of your points below. -----Original Message----- From: Brian LaMacchia [mailto:bal@microsoft.com] Sent: Wednesday, December 23, 1998 5:59 PM To: 'Luke Koops' Cc: ietf-pkix@imc.org; Barb Fox (Exchange) Subject: RE: CMC Comments? Luke-- (...stuff deleted...) 4) The absence of a client confirmation message means that there is no way to be sure that a client recieved a response, or that a client accepts the response. In what particular scenarios do you believe a confirmation message is required? In particular, could you expand on what it means for a client to "accept the response?" I know that CMP uses the client confirmation message as means of doing after-the-fact POP on an encryption key (the "indirect method" defined in section 2.3.2): the cert is issued to the encryption key before POP, the cert is returned to the client encrypted, the client demonstrates POP by decrypting the encrypted cert, and failure to respond requires that the CA now revoke the cert it just issued. CMC takes the approach that the cert should not be issued in the first place unless CA policy has been completely satisfied (e.g. POP for encryption keys demonstrated before the request is granted); this avoids extraneous revocations. Actually, CMP does not specify that "failure to respond requires that the CA now revoke the cert it just issued" (in fact, it suggests exactly the opposite -- see the final sentence of Section 3.3.4 -- because an encrypted certificate is of no use to anyone without the key to decrypt it, so it does not need to be revoked). However, POP for encryption key pairs is not the reason that CMP specifies a confirmation message. Recall that the CA has the power/authority/privilege/prerogative/etc. to modify the fields of any cert request that arrives. The confirmation message allows the EE to accept or deny the generated certificate, based upon whether or not any changes made are acceptable to it. Such a function is not merely "nice-to-have"; it may be legally required in some environments. Additionally, the confirmation message may simply be used to show that the EE did, in fact, receive the certificate, triggering the CA to make the certificate publicly available by some appropriate means. The fact that the confirmation message could simultaneously be used for proof-of-possession of a decryption key was a happy coincidence that CMP was pleased to exploit in order to achieve POP for all types of key pairs without requiring any extra messages. p.1, item 1 in Abstract: "need" should be replaced with "desire". I respectfully disagree :-), as there is clearly a need within the community to standardize current industry practice, as has long been identified within the PKIX WG. I respectfully disagree with your respectful disagreement. :-) Something that is really "current industry practice", something that is actually done by many/most products now, is already a de facto standard and does not *need* to be standardized. What needs to be standardized is the next step, the next level of functionality addressing greater generality or different environments (so that people know what to build). I can understand that there may be a *desire* to standardize current practice, simply to formalize it and get it written down in concrete, widely-accessible documents, but this is not actually a *need* if everyone has already implemented it the same way (of course, if they *haven't* implemented it the same way, then there really isn't "current industry practice", is there?). But this is a very minor quibble. p.2, section 2: "The two different request messages" should be replaced with "The three different request messages". There are only two different request messages: Simple Enrollment Request and Full PKI Request. What is the third? Simple Enrollment Request, Full PKI Request (using PKCS #10), and Full PKI Request (using CRMF) seem like three messages, but for me this is a minor quibble as well. p.7, section 3.3.2 [see also p.6, section 3.3.1]: MUST include both the subject name and public key fields, although the subject may be NULL. There is an attack here on the initialization mechanism whereby I can copy somebody else's request and then send in my own request, ending up with their public key and my identity in a valid verification certificate. In other words, the initialization mechanism is not secure. This has already been pointed out by Carlisle in his previous list comments; the authors are currently evaluating a number of proposals to nullify self-inflicted denial-of-service attacks, including this one. The attack mentioned here is not a "self-inflicted denial-of-service" attack. It allows me to get my name and your verification key put into a certificate which allows me, for example, to (legally) claim as mine documents that you have signed, or to substitute your certificate for mine in an authentication protocol that you are engaging in such that the other party thinks it is communicating with me. This is not denial-of-service stuff. p.7, section 3.3.3: "[DH-SIG] provides a way to product necessary signature." Change "product" to "produce the". Also, note that this mechanism is not strictly conformant with PKCS #10, which is very explicit about how you sign the request. This grammar will be fixed in the next draft. As for the signature in a PKCS#10, I'm not sure I understand your point. PKCS#10 (as available at ftp://ftp.rsa.com/pub/pkcs/doc/pkcs-10.doc, and as structurally included in CMC) defines a CertificationRequest as a SEQUENCE of CertificationRequestInfo, SignatureAlgorithm (an AlgorithmIdentifier) and a Signature (BIT STRING), equivalent to the X.509 SIGNED macro. All we need to do is define the AlgorithmIdentifier and semantics of the Signature BIT STRING for whatever DH-SIG ends up using. While syntactically conformant, such an interpretation of "signatureAlgorithm" and "signature" are not strictly conformant with PKCS #10 because the semantics are very different. Section 6.2 of PKCS #10 (specifically the 3rd bullet and the 2nd step) make this clear, especially when combined with Section 3.1 of the document "An Overview of the PKCS Standards", which defines digital signature. Again, however, this is a relatively minor quibble, since in Orlando it was agreed that the terminology "Diffie-Hellman *signature*" would no longer be used. p.9, section 4.2: it seems to me that digging into the bowels of a message in order to verify the outer envelope is a violation of the intent of CMS/PKCS7. Is there really no way to avoid this layering mismatch? Somehow you need to get a copy of the public component of the signature key pair in order to verify the signature. CMS provides two types of hints in SignerInfo to help you try to find the right key: an Issuer&SerialNumber pointer and a SubjectKeyIdentifier value (SKI was just added in Orlando). In S/MIMEv3 use, the I&SN identifies a cert for the corresponding public key, and typically a copy of that cert will be included in the CertificateSet. if you're signing your Full PKI Request with a previously-certified key that works fine. However, this approach doesn't work in CMC if you're signing the Full PKI Request with one of the key for which you are requesting certification. That's why draft -02 overloaded I&SN, putting the bodyPartID in the SN slot and NULL IssuerName. In the next draft CMC will take advantage of the SKI form to identify a particular key contained within the message. Taking advantage of the SKI to identify a particular key within the message does not address the question asked. The point is still that you need to dig into the contents of the message before you can verify the outer envelope for initialization messages. This seems to be a layering mismatch and seems to violate the intent of CMS/PKCS7. p.22, section 5.10.4.1: "DH-PrivateKey ::= INTEGER" should be "DH-PrivateKey ::= INTEGER, re-encoded as an OCTET STRING" (written in valid ASN.1). p.22, section 5.10.4.2: "RSAPrivateKey" should be "RSAPrivateKey, re-encoded as an OCTET STRING" (written in valid ASN.1). I don't understand this; are you asking for the INTEGER to be wrapped within an OCTET STRING? Why? PKIX Part 1 uses INTEGER for the public components of DSA an DH, and RSAprivate is pulled directly from PKCS#1. This comes from the definition of PrivateKeyInfo on the top of page 22, where privateKey is defined to be an OCTET STRING. In Sections 5.10.4.1 and 5.10.4.2 it says that privateKey must be INTEGER and RSAPrivateKey, respectively, but in order for these to fit into the specified PrivateKeyInfo structure, they must be re-encoded as OCTET STRINGs. Hope everyone else had a great Christmas as well! Carlisle. From owner-ietf-pkix Tue Jan 5 11:51:10 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA20084 for ietf-pkix-bks; Tue, 5 Jan 1999 11:51:10 -0800 (PST) Received: from gateway-ext.StructuredArts.COM (root@gateway-ext.structuredarts.com [206.127.192.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA20080 for ; Tue, 5 Jan 1999 11:51:08 -0800 (PST) Received: from structuredarts.com (kuma.structuredarts.com [206.127.206.4]) by gateway-ext.StructuredArts.COM (8.8.5/8.8.5) with ESMTP id MAA09136 for ; Tue, 5 Jan 1999 12:06:21 -0800 Message-ID: <36926DD0.A05DA7DC@structuredarts.com> Date: Tue, 05 Jan 1999 11:53:52 -0800 From: "Anil R. Gangolli" Organization: Structured Arts Computing Corporation X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Questions on Issuing Distribution Point CRL extension Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I have a couple of questions in reference to section 5.2.5 of draft 11. I think the draft could use a bit of clarification on these points. 1. Are the indications onlyContainsUserCerts and onlyContainsCACerts applicable to the CRL in which they appear, or to the CRL obtained at the distribution point, or both. My current reading is that they apply to both. One needs some indication within the CRL if it only contains some classes of certs, and I don't see another mechanism defined for that. 2. What does the indirectCRL indication mean? A description seems to be missing from the spec, (and might partly be a source of my confusion). 3. I have seen a test CRL issued with multiple distribution points bearing distinct indications of classes of certs "covered". Is this allowed? This might be appropriate for indicating where to get CRLs for other classes of certs in the case of partitioned CRLs, but then there is then a need to define some separate mechanism to indicate which indications apply directly to the CRL in which the extension appears. (Read item 1 above as well). I don't see one; my current interpretation is that the Issuing Distribution Point extension in a given CRL indicate only where to get updates for that one CRL, and that the indications that specify classes of certs "covered" by the CRL apply to that CRL and any update obtained at that distribution point. Is this correct? Could someone (maybe one of the draft 11 authors) suggest some revisions to 5.2.5 that clarify these points? --a. -- Anil R. Gangolli Structured Arts Computing Corporation mailto:gangolli@structuredarts.com http://www.structuredarts.com From owner-ietf-pkix Fri Jan 8 00:21:08 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA24460 for ietf-pkix-bks; Fri, 8 Jan 1999 00:21:08 -0800 (PST) Received: from krdl.org.sg (rodin.krdl.org.sg [137.132.252.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA24378; Fri, 8 Jan 1999 00:16:28 -0800 (PST) Received: from mailhost.krdl.org.sg (mailbox.krdl.org.sg [137.132.247.30]) by krdl.org.sg (8.9.0/8.9.0) with ESMTP id QAA19629; Fri, 8 Jan 1999 16:20:41 +0800 (SGT) Received: from colorado (colorado [137.132.249.218]) by mailhost.krdl.org.sg (8.9.0/8.9.0) with SMTP id QAA10492; Fri, 8 Jan 1999 16:14:52 +0800 (SGT) Date: Fri, 8 Jan 1999 16:14:09 +0800 (SGT) From: Jianying Zhou X-Sender: jyzhou@colorado To: aft@socks.nec.com, ietf-cat-wg@lists.stanford.edu, cryptography@c2.net, dns-security@tis.com, Firewalls@lists.gnac.net, ids@uow.edu.au, ietf-open-pgp@imc.org, ietf-otp@bellcore.com, ietf-pkix@imc.org, ietf-radius@livingston.com, ietf-smime@imc.org, ietf-ssh@clinet.fi, ietf-tls@consensus.com, ietf@ietf.org, ipsec@tis.com, OGsecurity@opengroup.org, pem-dev@tis.com, risks@csl.sri.com, spki@c2.net, virus-l@lehigh.edu, www-buyinfo@allegra.att.com, www-security@ns2.rutgers.edu Subject: Re: ACM CCS'99 CFP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I apology for sending a large attachment in an early message. Sorry. Jianying Zhou From owner-ietf-pkix Fri Jan 8 05:29:05 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA28721 for ietf-pkix-bks; Fri, 8 Jan 1999 05:29:05 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA28717 for ; Fri, 8 Jan 1999 05:29:04 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA11109; Fri, 8 Jan 1999 08:29:29 -0500 (EST) Message-Id: <199901081329.IAA11109@ietf.org> To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: The IESG SUBJECT: Last Call: Internet X.509 Public Key Infrastructure LDAPv2 Schema to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 08 Jan 1999 08:29:28 -0500 Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: The IESG has received a request from the Public-Key Infrastructure (X.509) Working Group to consider Internet X.509 Public Key Infrastructure LDAPv2 Schema as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 21, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldapv2-schema-02.txt From owner-ietf-pkix Fri Jan 8 05:27:45 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA28711 for ietf-pkix-bks; Fri, 8 Jan 1999 05:27:45 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA28707 for ; Fri, 8 Jan 1999 05:27:44 -0800 (PST) Received: from scoya.cnri.reston.va.us ([10.27.4.17]) by ietf.org (8.8.5/8.8.7a) with SMTP id IAA11074 for ; Fri, 8 Jan 1999 08:28:09 -0500 (EST) Date: Fri, 8 Jan 1999 08:28:19 -0500 (Eastern Standard Time) From: Steve Coya To: ietf-pkix@imc.org Subject: Last Call: Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP to Proposed Standard (fwd) Message-ID: X-X-Sender: scoya@odin.cnri.reston.va.us MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: fyi (sorry 'bout the oldd address....) ---------- Forwarded message ---------- Date: Fri, 08 Jan 1999 08:13:19 -0500 From: The IESG Reply-To: iesg@ietf.org To: IETF-Announce: ; Cc: ietf-pkix@tandem.com Subject: Last Call: Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP to Proposed Standard The IESG has received a request from the Public-Key Infrastructure (X.509) Working Group to consider Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 21, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-opp-ftp-http-04.txt From owner-ietf-pkix Fri Jan 8 05:46:25 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA28798 for ietf-pkix-bks; Fri, 8 Jan 1999 05:46:25 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA28794 for ; Fri, 8 Jan 1999 05:46:24 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA11647; Fri, 8 Jan 1999 08:46:48 -0500 (EST) Message-Id: <199901081346.IAA11647@ietf.org> To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: The IESG SUBJECT: Last Call: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 08 Jan 1999 08:46:48 -0500 Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: The IESG has received a request from the Public-Key Infrastructure (X.509) Working Group to consider X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 21, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-07.txt From owner-ietf-pkix Fri Jan 8 10:32:44 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA01079 for ietf-pkix-bks; Fri, 8 Jan 1999 10:32:44 -0800 (PST) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA01075 for ; Fri, 8 Jan 1999 10:32:42 -0800 (PST) Received: id NAA05656; Fri, 8 Jan 1999 13:29:41 -0500 Received: by gateway id ; Fri, 8 Jan 1999 13:31:35 -0500 Message-ID: <91AE69321799D211AEC500105A9C46961650DC@SOTHMXS05> From: Luke Koops To: "'Brian LaMacchia'" , ietf-pkix@imc.org Cc: "Barb Fox (Exchange)" Subject: RE: CMC Comments? Date: Fri, 8 Jan 1999 13:29:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Thanks to Carlisle for responding to many of your comments. I will attempt to reply to the few remaining outstanding issues. I have deleted the sections of the original message to which I am not responding. Hopefully the result is readable and fair. -Luke Koops luke.koops@entrust.com > ---------- > From: Brian LaMacchia[SMTP:bal@microsoft.com] > Sent: Wednesday, December 23, 1998 5:58 PM > To: 'Luke Koops' > Cc: ietf-pkix@imc.org; Barb Fox (Exchange) > Subject: RE: CMC Comments? > > Luke-- > > 1) It is not clear what a minimally compliant implementation MUST > support. It > seems to be: > [ ...MUNCH... ] > In order to be compliant with the protocol, clients just need to > continue > operating as they already do. > > No, they also need to understand the Full PKI Response message. A current > client (that only speaks PKCS#10/7) is not CMC-compliant because it does > not > support a standard mechanism for returning error information. > > Is there a need to lower the bar for PKIX compliance to this level? > > Obviously, the long-term goal is to use Full PKI Request and Response > messages throughout. I would not ascribe goals to a standard per se, and I do not claim to know what the goals of the authors are. It seems to me that this protocol will promote the status quo by embodying it within a standard. > However, CMC also has a goal of supporting > industry-standard PKCS#10/7 as a subset of the protocol, so that current > clients and servers can also participate in the CMC world. Current certificate clients could participate in the CMC world with minimal modifications (support for full response). A certificate server could also participate in the CMC world with minimal modifications as well (issue full response). But, such a server would not be CMC compliant. The standard has many more MUST clauses for a compliant server than it does for a compliant client. Your statement illustrates the confusion that will arise when vendors tout their product as "conforming with", "interoperating with", "complying to", or "supporting" the PKIX-CMC protocol. It seems likely that servers will be written to support minimally compliant clients. > PKIX-CMC needs to clearly state what MUST be supported by a > minimally > compliant implementation of the client and server. > > Agreed; I will suggest text to the authors for a Conformance section > (following the table at the top of this mail). > > 2) There is duplicate information in CRMF and CMC messages. [ ...MUNCH... ] > This comment is similar to the one Carlisle raised. The intent is that > controls should appear in the CMC control section, and not in individual > request bodies. If the intent is not specified in the standard, then other behaviour should be anticipated and addressed by the standard. > Putting the controls in CMC allows individual controls to > reference/apply to multiple request bodies. It also puts all the > processing > information up front, which facilitates one-pass processing. > > 3) The regInfo and respInfo controls are 'too open'. The result is > that a CA > or RA might not be able to interoperate with two different clients > which use > regInfo differently. A bit pattern could be a valid message from > both types > of clients, but with different semantics. It might not be possible > to > specify a parser which can handle both requests. > > It would be much better if regInfo and respInfo were not octet > strings, but > were defined in the following manner. > > ExtraInfo ::= SEQUENCE { > infoType OBJECT IDENTIFIER, > info ANY DEFINED BY infoType } > > (I assume you mean responseInfo, not respInfo...) > > I don't see the need to extend the definition of regInfo or responseInfo > into a SEQUENCE of OID/ANY as you suggest. If client and server choose to > define particular semantics for their specific information, and there's an > OID tagging a structure with those semantics, then that information can be > passed at top-level as just another CMC control attribute. It is expected > that clients and servers that choose to define additional information > specific to their agreements will pass this information through additional > control attributes; there's no reason to bury it down inside a > regInfo/responseInfo/ExtraInfo structure. > > (The regInfo and responseInfo controls themselves were defined for clients > and servers that have agreed on the semantics of that OCTET STRING through > some out-of-band mechanism. For example, in a Web-based enrollment > scenario > the server could construct the regInfo using form field values & script.) This creates the possibility that it would be impossible for a server to interoperate with the clients from several vendors that use these controls. My original statement remains unanswered. [ ...MUNCH... ] > ====================================================================== > Other observations (collected from other readers here): > [ ...MUNCH... ] > - it is not possible to securely send the CA root key in the > response > message. This might be a serious limitation in some environments. > > What do you mean by "securely send the CA root key"? Please expand on > this > remark. During initialization, a one time password could be used for _mutual_ authentication of the client and the server. Then the client could rely on the server to advise it of trusted root keys which would be used for verifying certificates. In some environments this might be a preferable way to seed the client with trusted root keys. Rather than have the software vendor decide which root keys are trusted, the end user would choose the trust network(s) in which she will participate. After making this choice, the user gets an i.d. and a one time password. This is all that is required to bootstrap the client into full participation. > Hope this answers your questions, > > --Brian LaMacchia > bal@microsoft.com > From owner-ietf-pkix Sun Jan 10 15:17:30 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA29919 for ietf-pkix-bks; Sun, 10 Jan 1999 15:17:30 -0800 (PST) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29915 for ; Sun, 10 Jan 1999 15:17:25 -0800 (PST) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Mon, 11 Jan 1999 10:15:50 +1100 Message-ID: From: Alan Lloyd To: "'Peter Sylvester'" , ietf-pkix@imc.org Subject: RE: finding services : DCS, OCSP, Timestamping, .. Date: Mon, 11 Jan 1999 10:15:48 +1100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Some thoughts: terms like "issuer" in the cert should be used - via a directory service. - these are logical names of objects in the real world that provide cert based services such a travel cards, etc. In addition a cert can be used for authentication in many services so it (the cert) should be as simple as possible re references to the services on which it is used. In addition services may change by name/location and physical properties due to error, compromise or failure - so in that case (where references to services are tied to a cert) - all the certs would have to be re issued. IMHO would be simpler to build a DN based directory service with logical issuer objects which support many cert based services than to hand configure references of many services in every cert. I do not think adding references in certs beyond that of issuer DN is the way to go. The danger is that each cert will end up like a web document and all PKIs will be like the WEB in terms of their management resources and overheads. regards alan > -----Original Message----- > From: Peter Sylvester [SMTP:Peter.Sylvester@edelweb.fr] > Sent: Tuesday, 5 January 1999 3:06 > To: ietf-pkix@imc.org > Subject: finding services : DCS, OCSP, Timestamping, .. > > happy new year > > The current texts of DCS, OCSP, Timestaping do not specify how one can > find the actual service. It seems useful to me to use some > certificate extension. > > The service operate (or can operate) in 'signed' environments, thus > a client has some knowledge of the public key of the service; > there are some chances that this knowledge comes from a certificate. > On the other hand the actual method of getting the service, > http, ftp, xyz, and the addresses is not known. It seems > logical to me to put extensions conforming to > > pkix part 1: 4.2.2.1 Authority Information Access > > into the certificate that describes the access point and method to > that service. > > > > Peter Sylvester From owner-ietf-pkix Sun Jan 10 20:50:34 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA01579 for ietf-pkix-bks; Sun, 10 Jan 1999 20:50:34 -0800 (PST) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA01575; Sun, 10 Jan 1999 20:50:31 -0800 (PST) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Mon, 11 Jan 1999 15:49:13 +1100 Message-ID: From: Alan Lloyd To: ietf-pkix@imc.org Cc: ietf-pkix@imc.org Subject: RE: Last Call: X.509 Internet Public Key Infrastructure Online Ce rtificate Status Protocol - OCSP to Proposed Standard Date: Mon, 11 Jan 1999 15:49:11 +1100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: All, HNY I put some comments in on the OCSP doc. Did they get incorporated? regards alan > -----Original Message----- > From: The IESG [SMTP:iesg-secretary@ietf.org] > Sent: Saturday, 9 January 1999 0:47 > Cc: ietf-pkix@imc.org > Subject: Last Call: X.509 Internet Public Key Infrastructure > Online Certificate Status Protocol - OCSP to Proposed Standard > > > The IESG has received a request from the Public-Key Infrastructure > (X.509) Working Group to consider X.509 Internet Public Key > Infrastructure Online Certificate Status Protocol - OCSP > as a Proposed Standard. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by January 21, 1999. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-07.txt > From owner-ietf-pkix Mon Jan 11 04:40:47 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA06142 for ietf-pkix-bks; Mon, 11 Jan 1999 04:40:47 -0800 (PST) Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA06138 for ; Mon, 11 Jan 1999 04:40:45 -0800 (PST) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA24226 for ; Mon, 11 Jan 1999 13:41:55 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Mon, 11 Jan 1999 13:41:55 +0100 (MET) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id NAA17274 for ; Mon, 11 Jan 1999 13:41:54 +0100 From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id NAA09960 for ietf-pkix@imc.org; Mon, 11 Jan 1999 13:41:54 +0100 Date: Mon, 11 Jan 1999 13:41:54 +0100 Message-Id: <199901111241.NAA09960@emeriau.edelweb.fr> To: ietf-pkix@imc.org Subject: RE: finding services : DCS, OCSP, Timestamping, .. Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > Some thoughts: > terms like "issuer" in the cert should be used - via a directory > service. - these are logical names of objects in the real world that > provide cert based services such a travel cards, etc. In addition a cert > can be used for authentication in many services so it (the cert) should > be as simple as possible re references to the services on which it is > used. In addition services may change by name/location and physical > properties due to error, compromise or failure - so in that case (where > references to services are tied to a cert) - all the certs would have to > be re issued. > > IMHO would be simpler to build a DN based directory service with > logical issuer objects which support many cert based services than to > hand configure references of many services in every cert. I guess you missed one point here: The extensions are not in the end user certs but in a cert that describes the service, for exemple in the public key certificate of some OCSP or DCS service. I am not talking about any protocol that tells you how to get from an end user cert to whatever service provider. Certificates for OCSP signing or DCS services are rather special things. They are really end user certificates but closely related to CAs. > > I do not think adding references in certs beyond that of issuer DN is > the way to go. The danger is that each cert will end up like a web > document and all PKIs will be like the WEB in terms of their management > resources and overheads. I fully agree with you that filling end user certificates with such information would not be a very good idea. From owner-ietf-pkix Mon Jan 11 10:04:57 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA08871 for ietf-pkix-bks; Mon, 11 Jan 1999 10:04:57 -0800 (PST) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA08867 for ; Mon, 11 Jan 1999 10:04:56 -0800 (PST) Received: from mail.securitydynamics.com by tholian.securitydynamics.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 11 Jan 1999 18:06:21 UT Received: by securitydynamics.com (8.7.6/8.7.3) with ESMTP id NAA04866; Mon, 11 Jan 1999 13:13:58 -0500 (EST) Received: by exna01.securitydynamics.com with Internet Mail Service (5.5.2232.9) id ; Mon, 11 Jan 1999 13:05:57 -0500 Message-ID: From: "Linn, John" To: ietf-pkix@imc.org, "'Peter Sylvester'" Subject: RE: finding services : DCS, OCSP, Timestamping, .. Date: Mon, 11 Jan 1999 13:09:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Peter, all, re: > > IMHO would be simpler to build a DN based directory service with > > logical issuer objects which support many cert based services than to > > hand configure references of many services in every cert. > I guess you missed one point here: The extensions are not in the > end user certs but in a cert that describes the service, for exemple > in the public key certificate of some OCSP or DCS service. > This isn't how I read ocsp-07, section 4.1, 1st paragraph, which states, "In order to convey to OCSP clients a well-known point of information access, CAs SHALL provide the capability to include the AuthorityInfoAccess extension (defined in [PKIX1], section 4.2.2.1) in certificates that can be checked using OCSP". Absent restatement or rescoping, this seems to include end users as well as OCSP services themselves within the set of certified entities for which OCSP-conformant CAs are expected to be able to include certificate-resident AIA extensions for use in locating an appropriate OCSP responder. The remainder of the paragraph notes that locally configured client data can be used as an alternative to inclusion of AIA extensions, suggesting that this required capability may not be used in all cases, but I don't see discussion suggesting that intended use is confined to certificates above the end-user level. --jl From owner-ietf-pkix Mon Jan 11 10:40:07 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09221 for ietf-pkix-bks; Mon, 11 Jan 1999 10:40:07 -0800 (PST) Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09217 for ; Mon, 11 Jan 1999 10:40:06 -0800 (PST) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA10467 for ; Mon, 11 Jan 1999 19:41:19 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Mon, 11 Jan 1999 19:41:18 +0100 (MET) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id TAA25252 for ; Mon, 11 Jan 1999 19:41:18 +0100 From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id TAA10145 for ietf-pkix@imc.org; Mon, 11 Jan 1999 19:41:17 +0100 Date: Mon, 11 Jan 1999 19:41:17 +0100 Message-Id: <199901111841.TAA10145@emeriau.edelweb.fr> To: ietf-pkix@imc.org Subject: RE: finding services : DCS, OCSP, Timestamping, .. Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Actually, the second and third paragraph of 4.1 seem to describe what I have been asking for if one changes the following text. In order to convey to OCSP clients a well-known point of information access, CAs SHALL provide the capability to include the AuthorityInfoAccess extension (defined in [PKIX1], section 4.2.2.1) in certificates that can be checked using OCSP + or in in certificates for CAs or Authorised Responders. Alternatively, the accessLocation for the OCSP provider may be configured locally at the OCSP client. Two scenarios: - A end-user client has some knowledge about one single local provider (kind of local proxy/broker). - An end user-client (which may be the proxy/broker) knows about CAs and the OCSP providers. The first case can be covered by 'a local configuration'. if one wants OCSP requests to be signed, then this local configuration would contain a public key of the local proxy, probably in a certificate, and it makes sense to me to have the indicated extension in this certificate. In the second case, I would see the extension in a certificate describing an issuer's service for ALL certificates issued by the issuer. Similar remarks for DCS etc. are left as an exercise From owner-ietf-pkix Mon Jan 11 10:39:17 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09215 for ietf-pkix-bks; Mon, 11 Jan 1999 10:39:17 -0800 (PST) Received: from exchng-fairfax.p-e-c.com (exchng-fairfax.pec.com [204.254.216.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09211 for ; Mon, 11 Jan 1999 10:39:15 -0800 (PST) Received: by exchang-fairfax.pec.com with Internet Mail Service (5.0.1460.8) id ; Mon, 11 Jan 1999 13:41:40 -0500 Message-ID: <3C7EABA3F6F1D1118FD90008C7F450FDEF78A5@exchang-fairfax.pec.com> From: WHenry To: ietf-pkix@imc.org Cc: "'digsig-arch@onelist.com'" Subject: Document-centric Digital Signatures Date: Mon, 11 Jan 1999 13:41:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BE3D92.05D97DE0" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: 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_01BE3D92.05D97DE0 Content-Type: text/plain All: Several months ago I started a discussion thread about the viability of embedding digital signatures within electronic documents (e.g. Word, Excel, etc). Some of the responses I received ranged from "use CMS!" to "it would be difficult to get application vendors on-board." There seemed to be some interest in establishing a BOF at the next IETF mtg to discuss this. In the absence of a BOF, I've set up a listserv for discussing this issue at http://www.onelist.com. You can subscribe to Disig-arch under Computers - Security or use the following URL http://www.onelist.com/viewarchive.cgi?listname=digsig-arch Subscribers post to the list using the following address: digsig-arch@onelist.com "Digsig-arch" is an unmoderated list intended to provide a forum for the discussion of issues related to the archiving of digitally signed electronic documents. The list focuses on public key infrastructure (PKI) associated digital signature issues vice biometric or electronic signature issues. Apologies for not providing an email subscribe/unsubscribe capability. However, the service is free and very easy to maintain (which we like!). Onelist will maintain a discussion archive at the site for those interested in reviewing previous postings. I've taken the liberty of posting my (and others) previous ietf-pkix postings regarding this issue in the archive (from May '98 timeframe). Regards, Bill Henry Performance Engineering Corporation Fairfax, VA ------ =_NextPart_001_01BE3D92.05D97DE0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Document-centric Digital Signatures

 All:

 Several months ago I started a = discussion thread about the viability of embedding digital signatures = within electronic documents (e.g. Word, Excel, etc).

 Some of the responses I received = ranged from "use CMS!" to "it would be difficult to get = application vendors on-board." There seemed to be some interest in = establishing a BOF at the next IETF mtg to discuss this.

 In the absence of a BOF, I've = set up a listserv for discussing this issue at http://www.onelist.com. You can subscribe to = Disig-arch under = Computers - Security or use the following URL http://www.onelist.com/viewarchive.cgi?listname=3Ddigs= ig-arch

 Subscribers = post to the list using the following address:
digsig-arch@onelist.com

 "Digsig-arch" is an unmoderated list = intended to provide a forum for the discussion of issues related to the = archiving of digitally signed electronic documents. The list focuses on = public key infrastructure (PKI) associated digital signature issues = vice biometric or electronic signature issues.

 Apologies for = not providing an email subscribe/unsubscribe capability.  However, = the service is free and very easy to maintain (which we like!). Onelist = will maintain a discussion archive at the site for those interested in = reviewing previous postings.

 I've taken the = liberty of posting my (and others) previous ietf-pkix postings = regarding this issue in the archive (from May '98 = timeframe).

 Regards,
 Bill = Henry
 Performance = Engineering Corporation
 Fairfax, = VA

------ =_NextPart_001_01BE3D92.05D97DE0-- From owner-ietf-pkix Mon Jan 11 18:28:18 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA15987 for ietf-pkix-bks; Mon, 11 Jan 1999 18:28:18 -0800 (PST) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA15980 for ; Mon, 11 Jan 1999 18:28:10 -0800 (PST) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Tue, 12 Jan 1999 13:26:49 +1100 Message-ID: From: Alan Lloyd To: "'Linn, John'" , ietf-pkix@imc.org, "'Peter Sylvester'" Subject: RE: finding services : DCS, OCSP, Timestamping, .. Date: Tue, 12 Jan 1999 13:26:48 +1100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Thanks for that John. My comments on OCSP also mentioned the use of this extension in that in a domain agile and global wanderer envrionment - and to deal with errors or failures in OCSP servers - it would be better if the certificate did not cryptographically tie its validation server to the users details. ie. if a "named" OCSP server failed the cert cannot be validated however, if a fault tollerant and replicated directory backbone service - that supported many OCSP validation processes failed, then an alternative validation process can be dealt with in the system. Its a question that OCSP seems to want to fix the OCSP server details in the cert, whereas a directory enabled OCSP approach with-distributed and replicated OCSP server funtions offers better utility and scaleability without the need to crypto-bind config info into certs. just thoughts regards alan > -----Original Message----- > From: Linn, John [SMTP:jlinn@securitydynamics.com] > Sent: Tuesday, 12 January 1999 5:09 > To: ietf-pkix@imc.org; 'Peter Sylvester' > Subject: RE: finding services : DCS, OCSP, Timestamping, .. > > Peter, all, re: > > > > IMHO would be simpler to build a DN based directory service with > > > logical issuer objects which support many cert based services than > to > > > hand configure references of many services in every cert. > > I guess you missed one point here: The extensions are not in the > > end user certs but in a cert that describes the service, for exemple > > in the public key certificate of some OCSP or DCS service. > > > This isn't how I read ocsp-07, section 4.1, 1st paragraph, which > states, "In > order to convey to OCSP clients a well-known point of information > access, > CAs SHALL provide the capability to include the AuthorityInfoAccess > extension (defined in [PKIX1], section 4.2.2.1) in certificates that > can be > checked using OCSP". Absent restatement or rescoping, this seems to > include > end users as well as OCSP services themselves within the set of > certified > entities for which OCSP-conformant CAs are expected to be able to > include > certificate-resident AIA extensions for use in locating an appropriate > OCSP > responder. The remainder of the paragraph notes that locally > configured > client data can be used as an alternative to inclusion of AIA > extensions, > suggesting that this required capability may not be used in all cases, > but I > don't see discussion suggesting that intended use is confined to > certificates above the end-user level. > > --jl > From owner-ietf-pkix Mon Jan 11 20:04:05 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA25476 for ietf-pkix-bks; Mon, 11 Jan 1999 20:04:05 -0800 (PST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA25470 for ; Mon, 11 Jan 1999 20:04:03 -0800 (PST) Received: from [128.33.238.144] (TC073.BBN.COM [128.33.238.73]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id XAA28164; Mon, 11 Jan 1999 23:04:44 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: Date: Mon, 11 Jan 1999 17:58:04 -0500 To: Alan Lloyd From: Stephen Kent Subject: RE: finding services : DCS, OCSP, Timestamping, .. Cc: "'Peter Sylvester'" , ietf-pkix@imc.org Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Alan, >terms like "issuer" in the cert should be used - via a directory >service. - these are logical names of objects in the real world that >provide cert based services such a travel cards, etc. In addition a cert >can be used for authentication in many services so it (the cert) should >be as simple as possible re references to the services on which it is >used. In addition services may change by name/location and physical >properties due to error, compromise or failure - so in that case (where >references to services are tied to a cert) - all the certs would have to >be re issued. I am not a believer in the one-size-fits-all certificate, so I am less concerned about the possible complexity that you suggest above. A reasonable model of cert issuance suggests that users acquire multiple certs, each of which has limited scope, just like the many forms of ID, membership, and charge cards we carry today. This simplifies many aspects of cert management, especially revocation, and avoids the complexities due to trying to "trust" one CA for many different credential forms. >IMHO would be simpler to build a DN based directory service with >logical issuer objects which support many cert based services than to >hand configure references of many services in every cert. Unfortunately, we don't have a global directory service of the sort envisioned by X.500, so finding a service based on the DN of the cert issuer is not easy. PKIX recommends use of an extension that we developed specifically so that the issuer of a cert can point users to the locations where anciliary services can be accessed. If one has suitable directory support, e.g., due to limited scope or as a result of config data, then it might be a fine alternative. However, in an effort to not hold up deployment of such services while waiting for ubiquitous directory service, ... >I do not think adding references in certs beyond that of issuer DN is >the way to go. The danger is that each cert will end up like a web >document and all PKIs will be like the WEB in terms of their management >resources and overheads. One could easily overdo it, but I don't think we're in danger of that yet. Steve From owner-ietf-pkix Mon Jan 11 20:22:02 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA28064 for ietf-pkix-bks; Mon, 11 Jan 1999 20:22:02 -0800 (PST) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA28031 for ; Mon, 11 Jan 1999 20:21:52 -0800 (PST) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Tue, 12 Jan 1999 15:20:33 +1100 Message-ID: From: Alan Lloyd To: "'Stephen Kent'" Cc: "'Peter Sylvester'" , ietf-pkix@imc.org Subject: RE: finding services : DCS, OCSP, Timestamping, .. Date: Tue, 12 Jan 1999 15:20:31 +1100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Agree with most you say and I am a realist you know. However, may I make the point, as below. > -----Original Message----- > From: Stephen Kent [SMTP:kent@bbn.com] > Sent: Tuesday, 12 January 1999 9:58 > To: Alan Lloyd > Cc: 'Peter Sylvester'; ietf-pkix@imc.org > Subject: RE: finding services : DCS, OCSP, Timestamping, .. > > Alan, > > >terms like "issuer" in the cert should be used - via a directory > >service. - these are logical names of objects in the real world that > >provide cert based services such a travel cards, etc. In addition a > cert > >can be used for authentication in many services so it (the cert) > should > >be as simple as possible re references to the services on which it is > >used. In addition services may change by name/location and physical > >properties due to error, compromise or failure - so in that case > (where > >references to services are tied to a cert) - all the certs would have > to > >be re issued. > > I am not a believer in the one-size-fits-all certificate, so I am less > concerned about the possible complexity that you suggest above. A > reasonable model of cert issuance suggests that users acquire multiple > certs, each of which has limited scope, just like the many forms of > ID, > membership, and charge cards we carry today. This simplifies many > aspects > of cert management, especially revocation, and avoids the complexities > due > to trying to "trust" one CA for many different credential forms. > > >IMHO would be simpler to build a DN based directory service with > >logical issuer objects which support many cert based services than to > >hand configure references of many services in every cert. > > Unfortunately, we don't have a global directory service of the sort > envisioned by X.500, so finding a service based on the DN of the cert > issuer is not easy. [Alan Lloyd] This comment is common in that we (the planet) does not have a global directory service, therefore we wont use it. In terms of engineering systems, a directory service is a function - and should be seen as just that ie. it is a distributed object oriented function - with auth and access control properties - and regardless of scale and operational deployment - if directory services are considered as a supporting information infrastructure that will be applied in many vertical markets and organisations for many operational, information management, security and service delivery reasons, then why not incorporate such functions into such things as PKI. Its like that when OCSP or LDAP or HTTP were invented they all assumed and relied on the fact that TCP/IP and the Internet existed and was serviceable and they used that. When X.500 was designed it assumed underlying comms/Internet were there to support inter directory operations. When X.509 and CAs and the X.500 distributed authentication model was put together it assumed a distributed directory service with DSP, DAP (and LDAP) were available. By putting and crypto binding system config/directory references into certs and mapping subjects and issuers to the URLs of servers - all we are doing is operationally placing single directory entries all over the place in a fragmented and possibly uncordinated way - ie operationally if a directory service is not used. The certficate by definition becomes a directory entry (ie it related names to server addresses) and the humans that manage (the millions of these cert/dir information things) - become the directory infrastructure. Not good for operational approaches re cost, reliability and scaling. I think directory supported OCSP servers will be the way to go. just thoughts and regards alan > PKIX recommends use of an extension that we developed specifically so > that > the issuer of a cert can point users to the locations where anciliary > services can be accessed. If one has suitable directory support, > e.g., due > to limited scope or as a result of config data, then it might be a > fine > alternative. However, in an effort to not hold up deployment of such > services while waiting for ubiquitous directory service, ... > > >I do not think adding references in certs beyond that of issuer DN is > >the way to go. The danger is that each cert will end up like a web > >document and all PKIs will be like the WEB in terms of their > management > >resources and overheads. > > One could easily overdo it, but I don't think we're in danger of that > yet. > > Steve From owner-ietf-pkix Tue Jan 12 07:36:11 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA17101 for ietf-pkix-bks; Tue, 12 Jan 1999 07:36:11 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.22]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA17097 for ; Tue, 12 Jan 1999 07:36:09 -0800 (PST) From: John_Wray@iris.com Received: by arista.iris.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 852566F7.0055C898 ; Tue, 12 Jan 1999 10:36:59 -0500 X-Lotus-FromDomain: IRIS To: ietf-pkix@imc.org Message-ID: <852566F7.0055C436.00@arista.iris.com> Date: Tue, 12 Jan 1999 10:37:25 -0500 Subject: Reason codes vs Reason flags Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: The reason code field in a CRL encodes the reason for a revocation as an enumerated type; the CMP revocation request field encodes it as a bitstring. What should a CA do if it receives a CMP revocation request with more than one reason bit set? Should it somehow prioritize the reasons, and put only the "most important reason" into the CRL? Should it put multiple revocation entries in the CRL, one for each requested reason? Should it reject the request as mal-formed? Should CMP use CRLReason instead of ReasonFlags? John From owner-ietf-pkix Wed Jan 13 04:59:14 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA19093 for ietf-pkix-bks; Wed, 13 Jan 1999 04:59:14 -0800 (PST) Received: from pluto.deh.de ([194.162.233.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA19089 for ; Wed, 13 Jan 1999 04:59:07 -0800 (PST) Received: from chappi.deh.de (chappi.deh.de [194.162.234.60]) by pluto.deh.de (8.9.1a/8.9.1) with ESMTP id OAA29483; Wed, 13 Jan 1999 14:00:09 +0100 Received: from deh.de (juergen.deh.de [194.162.234.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id OAA18267; Wed, 13 Jan 1999 14:00:00 +0100 Message-ID: <369C9963.17E989A0@deh.de> Date: Wed, 13 Jan 1999 14:02:27 +0100 From: Juergen Walter Reply-To: Juergen.Walter@deh.de X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: John_Wray@iris.com, Carlisle Adams , farrell@sse.ie, ietf-pkix Subject: Re: Reason codes vs Reason flags References: <852566F7.0055C436.00@arista.iris.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: John, I think, that reasonFlags should be used for the purpose of encoding revocationReasons for more than one CertTemplate. Therefore, the setting of more than one flag may be appropriate (see CRL profile in PKIX part 1). The current CMP draft has mapped one CertTemplate to one reasonFlags. In addition, ReasonCodes are contained in the optional Extensions. My suggestion: RevReqContent ::= SEQUENCE { revocationReason ReasonFlags OPTIONAL, -- the reason that revocation is requested revReqDetails SEQUENCE OF RevDetails } RevDetails ::= SEQUENCE { certDetails CertTemplate, -- allows requester to specify as much as they can about -- the cert. for which revocation is requested -- (e.g., for cases in which serialNumber is not available) badSinceDate GeneralizedTime OPTIONAL, -- indicates best knowledge of sender crlEntryDetails Extensions OPTIONAL -- requested crlEntryExtensions } So, the requester may send more than one CertTemplate. For each CertTemplate the requester may give a revocation reason in the crlEntryDetails structure. Then ReasonFlags may be set in the following way: Flag A is set if and only if there exists a CertTemplate that is requested to be revoked due to reason A. This may be done independently of reason codes optionally contained in crlEntryDetails. But I would prefer the following usage: If the revocation request contains more than one certificate templates and the corresponding revocation reasons are different, then reason codes (housed in the crlEntryDetails field) must be used. Optionally, reason flags may be set as above described. But if the revocation request contains only one certificate then the reason flag and/or the reason code may be encoded. Otherwise, if the revocation request contains more than one certificate templates and the corresponding revocation reason is in each case the same, then the appropriate flag of reason flag may be set. Futhermore, if there are any ambiguities with respect to revocation reasons, then the CA has to issue a CRL, where the worst case reason encoded in the request is referenced. John_Wray@iris.com wrote: > > The reason code field in a CRL encodes the reason for a revocation as an > enumerated type; the CMP revocation request field encodes it as a bitstring. > > What should a CA do if it receives a CMP revocation request with more than one > reason bit set? Should it somehow prioritize the reasons, and put only the > "most important reason" into the CRL? Should it put multiple revocation entries > in the CRL, one for each requested reason? Should it reject the request as > mal-formed? Should CMP use CRLReason instead of ReasonFlags? > > John From owner-ietf-pkix Wed Jan 13 07:47:37 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA20382 for ietf-pkix-bks; Wed, 13 Jan 1999 07:47:37 -0800 (PST) Received: from thehub.knight-hub.com (root@thehub.knight-hub.com [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA20378 for ; Wed, 13 Jan 1999 07:47:35 -0800 (PST) Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id KAA18826; Wed, 13 Jan 1999 10:26:33 -0500 Message-Id: <4.1.19990113095846.00a988c0@209.172.119.123> X-Sender: aarsenault#207.212.34.30@209.172.119.123 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 13 Jan 1999 10:21:27 -0500 To: Juergen.Walter@deh.de, John_Wray@iris.com, Carlisle Adams , farrell@sse.ie, ietf-pkix From: Al Arsenault Subject: Re: Reason codes vs Reason flags In-Reply-To: <369C9963.17E989A0@deh.de> References: <852566F7.0055C436.00@arista.iris.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Juergen, Whoa! While I appreciate your approach, I think it makes things way more complicated than they need to be. Why, for example, should my software have to deal with a single reasonFlags and multiple certTemplates, when I'll just have to go in and parse each certificate to see what reason it was revoked for, anyway? It doesn't seem to be any benefit to me to know that "of the following six certificates, one or more was revoked for keyCompromise, one or more for affiliationChanged, one or more for superseded, and one or more for certificateHold". I'm going to have to look at each individual certificate to see why it specifically should be revoked, so the extra reasonFlags doesn't buy me anything. The only time when I can see something like that being useful is if you consider one particular reason to be 'worse" than the others. For example, in some situations, keyCompromise may be more "important" than all the other reasons (that's clearly not always true, but it may well be in some circumstances). Thus, you could look at the initial reasonFlags to see if you had any keyCompromises, and if so, expedite processing of this revocation request. Other than that, I don't see a win, and I do see more complicated code. I looked at this differently. When John posed his question about whether any certificate should be revoked for multiple reasons, I looked at the reason codes listed in PKIX-1. They are: CRLReason ::= ENUMERATED { unspecified (0), keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6), removeFromCRL (8) } Now, it doesn't make sense to me to revoke a certificate for a reason of "unspecified" AND for another, specified reason at the same time. Besides, PKIX-1 discourages the use of "unspecified", anyway, so I think we can eliminate any combinations including "unspecified". Next, keyCompromise. I suppose it is possible to revoke a certificate because its private key and the private key of its issuer were simultaneously compromised, but only if the CRL-issuer is using a different key. Otherwise, in an event where the key was compromised at the same time the user's affiliation changed or the certificate was superseded (by one with a new key, I would hope :-), I would suggest that the requester just pick one - whichever is more important in her environment. Similarly, looking at other possible pairs, very few of them make sense. For example, I can't see where you would simultaneously want to revoke a certificate because it was superseded AND because of cessation of operations. Because of this, I'd prefer that CMP use CRLReason vice reasonFlags so that the sender can only specify one reason, but I'm willing to keep things the way they are so as not to delay CMP any further. So, from the standpoint of making everything interoperate, and making the software simpler to develop, I propose the following: - Senders of CMP revocation requests SHOULD only include one reason for each certificate in the request. (I'd personally prefer MUST, but I'm willing to accept that there might be some rare cases when two or more things pop up at once, and you want to let the recipient know all of the reasons.) Senders SHOULD choose the reason that is most important in their system, if there is a way of ranking them in importance. If not, senders SHOULD pick any one. - Recipients of CMP revocation requests MUST accept messages with multiple reasonFlags selected. If the request is accepted, the revoked certificate MUST only be placed on the CRL once, for one reason. If one reason is deemed to be more important than others in the revoker's environment, the revoker SHOULD choose that reason; otherwise, the revoker can choose any reason for revocation. Any changes based on this can be made later; for now, this can be left as "yeah, we implementers understand that this should happen this way." Hey - maybe it can even go in another version of the Roadmap. :-) Comments? Al Arsenault -- these are my opinions only. They do not necessarily reflect the opinions of my employer, or of any other organization with which I have a relationship. From owner-ietf-pkix Wed Jan 13 09:25:54 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA21352 for ietf-pkix-bks; Wed, 13 Jan 1999 09:25:54 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA21348 for ; Wed, 13 Jan 1999 09:25:50 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA12539; Wed, 13 Jan 1999 12:26:40 -0500 (EST) Message-Id: <199901131726.MAA12539@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-ipki3cmp-09.txt Date: Wed, 13 Jan 1999 12:26:40 -0500 Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --NextPart Note: This revision reflects comments received during the last call period. 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 : Internet X.509 Public Key Infrastructure Certificate Management Protocols Author(s) : C. Adams, S. Farrell Filename : draft-ietf-pkix-ipki3cmp-09.txt Pages : 67 Date : 12-Jan-99 This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocols. Protocol messages are defined for all relevant aspects of certificate creation and management. Note that 'certificate' in this document refers to an X.509v3 Certificate as defined in [COR95, X509-AM]. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki3cmp-09.txt 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-ipki3cmp-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html 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-ipki3cmp-09.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: <19990112161314.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ipki3cmp-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ipki3cmp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990112161314.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Wed Jan 13 10:03:47 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA21874 for ietf-pkix-bks; Wed, 13 Jan 1999 10:03:47 -0800 (PST) Received: from pluto.deh.de (pluto.deh.de [194.162.233.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21870 for ; Wed, 13 Jan 1999 10:03:43 -0800 (PST) Received: from chappi.deh.de (chappi.deh.de [194.162.234.60]) by pluto.deh.de (8.9.1a/8.9.1) with ESMTP id TAA19901; Wed, 13 Jan 1999 19:04:03 +0100 Received: from deh.de (juergen.deh.de [194.162.234.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id TAA19734; Wed, 13 Jan 1999 19:03:47 +0100 Message-ID: <369CE096.B4403981@deh.de> Date: Wed, 13 Jan 1999 19:06:14 +0100 From: Juergen Walter Reply-To: Juergen.Walter@deh.de X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Al Arsenault , "John_Wray@iris.com" , ietf-pkix , Carlisle Adams , farrell Subject: Re: Reason codes vs Reason flags References: <852566F7.0055C436.00@arista.iris.com> <4.1.19990113095846.00a988c0@209.172.119.123> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Al, John Al Arsenault wrote: > > Juergen, > > Whoa! While I appreciate your approach, I think it makes things way > more complicated than they need to be. I apologize. This was the result of doing mathematics during lunch time and thinking about reason codes vs reason flags afterwards. :-) >Why, for example, should my software > have to deal with a single reasonFlags and multiple certTemplates, when I'll > just have to go in and parse each certificate to see what reason it was revoked > for, anyway? Firstly, a huge number of certTemplates with identically revocation reasons, secondly ... (see below) > It doesn't seem to be any benefit to me to know that "of the > following six certificates, one or more was revoked for keyCompromise, one or > more for affiliationChanged, one or more for superseded, and one or more for > certificateHold". I'm going to have to look at each individual certificate to > see why it specifically should be revoked, so the extra reasonFlags doesn't buy > me anything. This is exactly the situation with respect to the current CMP draft. To each certTemplate one may find two sources of revocation reasons. Taking this into consideration I suggested that reason codes should be chosen. > > The only time when I can see something like that being useful is if you > consider one particular reason to be 'worse" than the others. For example, in > some situations, keyCompromise may be more "important" than all the other > reasons (that's clearly not always true, but it may well be in some > circumstances). Thus, you could look at the initial reasonFlags to see if you > had any keyCompromises, and if so, expe