From owner-ietf-pkix Mon Jan 3 12:35:10 2000 Received: from sentry (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21224 for ; Mon, 3 Jan 2000 12:35:09 -0800 (PST) Received: by sentry; id PAA28438; Mon, 3 Jan 2000 15:36:10 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma028428; Mon, 3 Jan 00 15:35:40 -0500 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id PAA00881 for ietf-pkix@imc.org; Mon, 3 Jan 2000 15:34:25 -0500 (EST) Date: Mon, 3 Jan 2000 15:34:25 -0500 (EST) From: "David M. Balenson" Message-Id: <200001032034.PAA00881@clipper.gw.tislabs.com> To: ietf-pkix@imc.org Subject: Jan. 6th early registration deadline for ISOC Netw. & Distr. Sys. Security Symp. (NDSS 2000) 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 , 2 0 0 0 THE INTERNET SOCIETY'S Year 2000 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM February 2-4, 2000 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Gene Tsudik, USC/Information Sciences Institute Avi Rubin, AT&T Labs - Research ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss2000 EARLY REGISTRATION DISCOUNT DEADLINE: January 6, 2000 The 7th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. KEYNOTE SPEAKER: Gene Spafford, Professor of Computer Sciences at Purdue University, an expert in information security, computer crime investigation and information ethics. Spaf (as he is known to his friends, colleagues, and students) is director of the Purdue CERIAS (Center for Education and Research in Information Assurance and Security), and was the founder and director of the (now superseded) COAST Laboratory. THIS YEAR'S TOPICS INCLUDE: - Automated Detection of Buffer Overrun Vulnerabilities - User-Level Infrastructure for System Call Interposition - Optimized Group Rekey for Group Communication Systems - IPSec-based Host Architecture for Secure Internet Multicast - The Economics of Security - Automatic Generation of Security Protocols - Security Protocols for SPKI-based Delegation Systems - Secure Border Gateway Protocol (S-BGP) - Analysis of a Fair Exchange Protocol - Secure Password-Based Protocols for TLS - Chameleon Signatures - Lightweight Tool for Detecting Web Server Attacks - Adaptive and Agile Applications Using Intrusion Detection - Secure Virtual Enclaves - Encrypted rlogin Connections Created With Kerberos IV - Accountability and Control of Process Creation in Metasystems - Red Teaming and Network Security PRE-CONFERENCE TECHNICAL TUTORIALS: - Network Security Protocol Standards, Dr. Stephen T. Kent - Deployed and Emerging Security Systems for the Internet, Dr. Radia Perlman and Charlie Kaufman - Mobile Code Security and Java 2 Architecture, Dr. Gary McGraw - Cryptography 101, Dr. Aviel D. Rubin - Public Key Infrastructure - The Truth and How to Find It, Dr. Daniel E. Geer, Jr. - An Introduction to Intrusion Detection Technology, Mr. Mark Wood FOR MORE INFORMATION contact the Internet Society: Internet Society, 11150 Sunset Hills Road, Reston, VA, 20190 USA Phone: +1-703-326-9880 Fax: +1-703-326-9881 E-mail: ndss2000reg@isoc.org URL: http://www.isoc.org/ndss2000/ SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Carla Rosenfeld at the Internet Society at +1-703-326-9880 or send e-mail to carla@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. From owner-ietf-pkix Mon Jan 3 16:56:07 2000 Received: from v4j31 (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA24231 for ; Mon, 3 Jan 2000 16:56:07 -0800 (PST) Message-Id: <4.2.1.20000103165351.00b73750@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Mon, 03 Jan 2000 16:56:06 -0800 To: ietf-pkix@imc.org From: Paul Hoffman / IMC Subject: Vagueness in empty CRLs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed RFC 2459, section 5.1.2 says: Optional fields include lists of revoked certificates and CRL extensions. The revoked certificate list is optional to support the case where a CA has not revoked any unexpired certificates that it has issued. This could be read two ways: a) If there are no revoked certs, do not include the optional field b) If there are no revoked certs, you can include and empty optional field because it is, after all, optional At least one developer has coded only for (a). Do people have a strong feeling one way or another? Either way, I think this should be clearer in 2459bis. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-pkix Mon Jan 3 17:39:43 2000 Received: from smtp.seeder.net.tw (smtp.seeder.net [202.43.64.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA24876 for ; Mon, 3 Jan 2000 17:39:42 -0800 (PST) From: u8142010@ms2.seeder.net Received: from babu ([210.61.251.92]) by smtp.seeder.net.tw with SMTP (IPAD 2.5) id 4092100 ; Tue, 04 Jan 2000 09:41:44 +0800 Message-ID: <003801bf5654$ab940770$ca1714ac@intranet.com.tw> To: Subject: Fw: MS and NS certificate format for SSL and S/MIME Date: Tue, 4 Jan 2000 09:40:20 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01BF5697.B7540310" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_0035_01BF5697.B7540310 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hello, Does anybody know where can I find the documents or URL that explain = what extensions to Mircosoft and Netscape expects in certificates for = SSL and S/MIME purpose? I want to know which certificate extensions = should be used for MS and NS applications, such as browser and email ap, = exactly? Best Regrards, James Lam. ------=_NextPart_000_0035_01BF5697.B7540310 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hello,
   Does anybody know where can  I = find the=20 documents or URL that explain what extensions to Mircosoft and Netscape = expects=20 in certificates for SSL and S/MIME purpose? I want to know which = certificate=20 extensions should be used for MS and NS applications, such as = browser and=20 email ap, exactly?
 
Best Regrards,
James Lam.
------=_NextPart_000_0035_01BF5697.B7540310-- From owner-ietf-pkix Tue Jan 4 08:59:53 2000 Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10370; Tue, 4 Jan 2000 08:59:52 -0800 (PST) Received: from rhousley_laptop.spyrus.com (russ-35.spyrus.com [207.212.35.226]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA16158; Tue, 4 Jan 2000 08:56:57 -0800 (PST) Message-Id: <4.2.0.58.20000104115502.00a5eaf0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 04 Jan 2000 11:56:00 -0500 To: Paul Hoffman / IMC From: Russ Housley Subject: Re: Vagueness in empty CRLs Cc: ietf-pkix@imc.org In-Reply-To: <4.2.1.20000103165351.00b73750@mail.imc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I wrote this sentence. I meant (a). If you think it is necessary, we can add a few words to remove the ambiguity in the next version. Russ At 04:56 PM 01/03/2000 -0800, Paul Hoffman / IMC wrote: >RFC 2459, section 5.1.2 says: > > Optional fields include lists of revoked certificates and CRL > extensions. The revoked certificate list is optional to support the > case where a CA has not revoked any unexpired certificates that it > has issued. > >This could be read two ways: > >a) If there are no revoked certs, do not include the optional field > >b) If there are no revoked certs, you can include and empty optional field >because it is, after all, optional > >At least one developer has coded only for (a). Do people have a strong >feeling one way or another? Either way, I think this should be clearer in >2459bis. > >--Paul Hoffman, Director >--Internet Mail Consortium From owner-ietf-pkix Tue Jan 4 09:47:08 2000 Received: from v4j31 (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11137; Tue, 4 Jan 2000 09:47:06 -0800 (PST) Message-Id: <4.2.1.20000104094701.00b7fb80@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Tue, 04 Jan 2000 09:47:22 -0800 To: Russ Housley From: Paul Hoffman / IMC Subject: Re: Vagueness in empty CRLs Cc: ietf-pkix@imc.org In-Reply-To: <4.2.0.58.20000104115502.00a5eaf0@mail.spyrus.com> References: <4.2.1.20000103165351.00b73750@mail.imc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:56 AM 1/4/00 -0500, Russ Housley wrote: >I wrote this sentence. I meant (a). If you think it is necessary, we can >add a few words to remove the ambiguity in the next version. I think it's necessary. And easy. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-pkix Tue Jan 4 10:44:34 2000 Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12099 for ; Tue, 4 Jan 2000 10:44:33 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA21999; Tue, 4 Jan 2000 13:42:01 -0500 (EST) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id NAA21994; Tue, 4 Jan 2000 13:42:00 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id NAA25525; Tue, 4 Jan 2000 13:41:06 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id NAA00805; Tue, 4 Jan 2000 13:40:30 -0500 (EST) Message-Id: <200001041840.NAA00805@ara.missi.ncsc.mil> Date: Tue, 4 Jan 2000 13:40:30 -0500 (EST) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Vagueness in empty CRLs To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: fqlBkbMe4DO0FnMwnvK8Kg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc It should also be clearer in X.509-Y2K. Perhaps the definition of revokedCertificates in CertificateList could be changed from: revokedCertificates ::= SEQUENCE OF SEQUENCE { serialNumber CertificateSerialNumber, revocationDate Time, crlEntryExtensions Extensions OPTIONAL } OPTIONAL, ... to: revokedCertificates ::= SEQUENCE SIZE(1..MAX) OF CrlEntry OPTIONAL, ... CrlEntry ::= SEQUENCE { serialNumber CertificateSerialNumber, revocationDate Time, crlEntryExtensions Extensions OPTIONAL } I notice that the size constraint for Extensions is present in RFC 2459 but not in X.509, so updating X.509 is not a strict prerequisite. Still, it would be nice if X.509 were clarified. Dave > Date: Tue, 04 Jan 2000 11:56:00 -0500 > To: Paul Hoffman / IMC > From: Russ Housley > Subject: Re: Vagueness in empty CRLs > Cc: ietf-pkix@imc.org > > I wrote this sentence. I meant (a). If you think it is necessary, we can > add a few words to remove the ambiguity in the next version. > > Russ > > > At 04:56 PM 01/03/2000 -0800, Paul Hoffman / IMC wrote: > >RFC 2459, section 5.1.2 says: > > > > Optional fields include lists of revoked certificates and CRL > > extensions. The revoked certificate list is optional to support the > > case where a CA has not revoked any unexpired certificates that it > > has issued. > > > >This could be read two ways: > > > >a) If there are no revoked certs, do not include the optional field > > > >b) If there are no revoked certs, you can include and empty optional field > >because it is, after all, optional > > > >At least one developer has coded only for (a). Do people have a strong > >feeling one way or another? Either way, I think this should be clearer in > >2459bis. > > > >--Paul Hoffman, Director > >--Internet Mail Consortium > From owner-ietf-pkix Tue Jan 4 12:43:28 2000 Received: from dell_srv.bankers.org (l85.ip.quake.net [198.68.224.85]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13986 for ; Tue, 4 Jan 2000 12:43:26 -0800 (PST) Received: by DELL_SRV with Internet Mail Service (5.5.2232.9) id ; Tue, 4 Jan 2000 12:41:18 -0800 Message-ID: <2F05D61D07F4D111A96900A0C90CD468259AE1@DELL_SRV> From: Peter Yeatrakas To: "'ietf-pkix@imc.org'" Subject: Date: Tue, 4 Jan 2000 07:59:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" subscribe From owner-ietf-pkix Tue Jan 4 23:22:12 2000 Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA11768 for ; Tue, 4 Jan 2000 23:22:11 -0800 (PST) Received: from l-mhs1.lannion.cnet.fr ([161.104.1.59]) by p-biset.issy.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id C16YJN2W; Wed, 5 Jan 2000 08:22:47 +0100 Received: from lsun607 (lsun607.lannion.cnet.fr [161.104.14.41]) by l-mhs1.lannion.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id C1XLNSS8; Wed, 5 Jan 2000 08:21:59 +0100 Sender: dubuisso Message-ID: <3872F110.1D0C@cnet.francetelecom.fr> Date: Wed, 05 Jan 2000 08:21:52 +0100 From: Olivier DUBUISSON Organization: France Telecom - Cnet - DTL/MSV - Lannion X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: "David P. Kemp" CC: ietf-pkix@imc.org Subject: Re: Vagueness in empty CRLs References: <200001041840.NAA00805@ara.missi.ncsc.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David P. Kemp wrote: > > It should also be clearer in X.509-Y2K. Perhaps the definition of > revokedCertificates in CertificateList could be changed from: > > revokedCertificates ::= SEQUENCE OF SEQUENCE { > serialNumber CertificateSerialNumber, > revocationDate Time, > crlEntryExtensions Extensions OPTIONAL } OPTIONAL, > ... > > to: > > revokedCertificates ::= SEQUENCE SIZE(1..MAX) OF CrlEntry OPTIONAL, > ... A minor point: this should read: ....... revokedCertificates SEQUENCE SIZE(1..MAX) OF CrlEntry OPTIONAL, ....... because "revokedCertificates" is a component defined in a SEQUENCE type and not a type assignment (in which case it should begin with an upper-case letter). Another minor point: it is better not to used "..." to mean "etc" inside SEQUENCE types because "..." could be interpreted as an extension marker ;-) Happy new year. -- Olivier DUBUISSON France Telecom - Branche Developpement _/_/_/_/ Centre National d'Etudes des Telecommunications _/_/_/_/ DTL/MSV - Piece WF025 - 22307 Lannion Cedex - France _/_/_/_/ tel: +33 2 96 05 38 50 - fax: +33 2 96 05 39 45 --> Site ASN.1 : http://asn1.elibel.tm.fr/ <-- From owner-ietf-pkix Wed Jan 5 11:43:59 2000 Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04547 for ; Wed, 5 Jan 2000 11:43:59 -0800 (PST) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jan 2000 14:43:30 -0500 Message-ID: From: Sharon Boeyen To: "'David P. Kemp'" , ietf-pkix@imc.org Cc: "'Hoyt Kesterson'" Subject: RE: Vagueness in empty CRLs Date: Wed, 5 Jan 2000 14:43:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" The ASN.1 in X.509 is the way it is, at least in part, for purposes of backward compatibility with v1 CRLs. I don't see any need to change that because the PKIX profile is accommodated with the current ASN.1. On the topic of how to issue a CRL that contains zero revocation notices, X.509 currently allows two ways. Either the optional revokedCertificates element can be absent, or it can be present with an empty SEQUENCE. That also is nothing new, but has been allowed since the early days of v1 CRLs. My understanding is that the PKIX profile mandates that the issuance of a CRL that contains no revocation notices be done by omiting the revokedCertificates element. I have no problem with that either because it is a profile. However, the proposal to be to make that same restriction in X.509 itself does concern me a bit, primarily from the standpoint of backward compatibility but also because we don't have a thorough way to ensure that making the change wouldn't break some existing systems and environments outside PKIX. While this would probably be a useful thing to do, we need to remember that PKIX is not the only group that is using and profiling X.509. I suppose we can check the profiles and groups we are aware of (e.g. FPKI, SEIS, TC 68, ANSI, WAP etc) and if all we know about uses the same method, we could raise a defect against X.509 to modify it. I'm not saying I'm opposed to that, but am raising the point that PKIX is not the only environment of concern. If we do go ahead with a proposed change to 509, I'd prefer it to be a text clarification rather than a restructuring of the ASN.1, again because of backward compatibility. Sharon > -----Original Message----- > From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] > Sent: Tuesday, January 04, 2000 1:41 PM > To: ietf-pkix@imc.org > Subject: Re: Vagueness in empty CRLs > > > It should also be clearer in X.509-Y2K. Perhaps the definition of > revokedCertificates in CertificateList could be changed from: > > revokedCertificates ::= SEQUENCE OF SEQUENCE { > serialNumber CertificateSerialNumber, > revocationDate Time, > crlEntryExtensions Extensions OPTIONAL } OPTIONAL, > ... > > to: > > revokedCertificates ::= SEQUENCE SIZE(1..MAX) OF CrlEntry > OPTIONAL, > ... > > CrlEntry ::= SEQUENCE { > serialNumber CertificateSerialNumber, > revocationDate Time, > crlEntryExtensions Extensions OPTIONAL } > > > I notice that the size constraint for Extensions is present > in RFC 2459 > but not in X.509, so updating X.509 is not a strict > prerequisite. Still, > it would be nice if X.509 were clarified. > > Dave > > > > > Date: Tue, 04 Jan 2000 11:56:00 -0500 > > To: Paul Hoffman / IMC > > From: Russ Housley > > Subject: Re: Vagueness in empty CRLs > > Cc: ietf-pkix@imc.org > > > > I wrote this sentence. I meant (a). If you think it is > necessary, we can > > add a few words to remove the ambiguity in the next version. > > > > Russ > > > > > > At 04:56 PM 01/03/2000 -0800, Paul Hoffman / IMC wrote: > > >RFC 2459, section 5.1.2 says: > > > > > > Optional fields include lists of revoked certificates and CRL > > > extensions. The revoked certificate list is optional > to support the > > > case where a CA has not revoked any unexpired > certificates that it > > > has issued. > > > > > >This could be read two ways: > > > > > >a) If there are no revoked certs, do not include the optional field > > > > > >b) If there are no revoked certs, you can include and > empty optional field > > >because it is, after all, optional > > > > > >At least one developer has coded only for (a). Do people > have a strong > > >feeling one way or another? Either way, I think this > should be clearer in > > >2459bis. > > > > > >--Paul Hoffman, Director > > >--Internet Mail Consortium > > > From owner-ietf-pkix Wed Jan 5 14:43:21 2000 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07024 for ; Wed, 5 Jan 2000 14:43:21 -0800 (PST) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by caladan.verisign.com (8.9.3/BCH1.7) with ESMTP id OAA11235; Wed, 5 Jan 2000 14:40:23 -0800 (PST) Received: from pbaker-pc.verisign.com ([192.168.7.110]) by postal-gw1.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CMBLR362; Wed, 5 Jan 2000 14:42:23 -0800 From: "Phillip M Hallam-Baker" To: "Sharon Boeyen" , "'David P. Kemp'" , Cc: "'Hoyt Kesterson'" Subject: RE: Vagueness in empty CRLs Date: Wed, 5 Jan 2000 17:44:02 -0500 Message-ID: <004901bf57ce$5ceeda20$6e07a8c0@pbaker-pc.verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 > However, the proposal to be to make that same restriction in X.509 itself > does concern me a bit, primarily from the standpoint of backward compatibility > but also because we don't have a thorough way to ensure that making the change > wouldn't break some existing systems and environments outside PKIX. Given the choice between ASN.1 DER purity and backwards compatibility, give me compatibility every time. I have never accepted that the DER rules met a real need and hearing the argument again a fiftieth time is unlikely to convince me. I must admit though that I am amazingly sensitive on this point having heard at length the same argument in the context of XML documents. Strikes me that people are going to want such a capability about as often as they stick $100 bills into the office shredder and stick them back together with Scotch tape. Regardless, we might well wish to consider that PKIX implementations should be restrictive in what they create and persmissive in what they accept. If there is a possible confusion we should perhaps state that implementations MUST issue the pukah DER form and SHOULD accept anything that is legal BER. Phill From owner-ietf-pkix Wed Jan 5 14:55:38 2000 Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07349 for ; Wed, 5 Jan 2000 14:55:38 -0800 (PST) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhwsx27762; Wed, 5 Jan 2000 22:54:37 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA16220; Wed, 5 Jan 00 17:52:09 EST Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id RAA14467; Wed, 5 Jan 2000 17:54:35 -0500 Date: Wed, 5 Jan 2000 17:54:35 -0500 Message-Id: <200001052254.RAA14467@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: pbaker@verisign.com Cc: sharon.boeyen@entrust.com, dpkemp@missi.ncsc.mil, ietf-pkix@imc.org, H.Kesterson@bull.com Subject: RE: Vagueness in empty CRLs References: <004901bf57ce$5ceeda20$6e07a8c0@pbaker-pc.verisign.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid >>>>> "Phillip" == Phillip M Hallam-Baker writes: Phillip> Given the choice between ASN.1 DER purity and backwards Phillip> compatibility, give me compatibility every time. That makes sense. Phillip> Regardless, we might well wish to consider that PKIX Phillip> implementations should be restrictive in what they create Phillip> and persmissive in what they accept. Definitely. That's the IETF protocol design rule. Phillip> If there is a possible confusion we should perhaps state Phillip> that implementations MUST issue the pukah DER form and Phillip> SHOULD accept anything that is legal BER. I'd say that's going too far. "Permissive" doesn't mean (to me) that you should accept a large superset of the supposed protocol at great expense in complexity. It means things like: 1. Don't do value checking if it serves no purpose other than to complain about "the wrong value". 2. Assume reserved fields can be any old value, not just zero. 3. *if it is no particular effort to do so* don't assume tagged field to be in a particular order But it doesn't mean that you should accept the full gruesome flexibility of BER. Relaxing some of the DER rules (e.g., on ordering) may be a good thing. But a big argument for the "permissive" rule is to make things simpler, not to make them more complex. paul From owner-ietf-pkix Wed Jan 5 17:47:51 2000 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09548 for ; Wed, 5 Jan 2000 17:47:50 -0800 (PST) Received: from [128.33.238.33] (TC033.BBN.COM [128.33.238.33]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id UAA23925; Wed, 5 Jan 2000 20:47:00 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <200001052254.RAA14467@tonga.xedia.com> References: <004901bf57ce$5ceeda20$6e07a8c0@pbaker-pc.verisign.com> <200001052254.RAA14467@tonga.xedia.com> Date: Wed, 5 Jan 2000 20:45:29 -0500 To: Paul Koning From: Stephen Kent Subject: RE: Vagueness in empty CRLs Cc: pbaker@verisign.com, sharon.boeyen@entrust.com, dpkemp@missi.ncsc.mil, ietf-pkix@imc.org, H.Kesterson@bull.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Folks, We're not debating a generic change re adherence to DER. We're just debating details of CRL encoding conventions. I agree with Sharon's analysis and suggest that we adopt that approach to dealing with this ambiguity. Steve From owner-ietf-pkix Thu Jan 6 07:12:10 2000 Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09280 for ; Thu, 6 Jan 2000 07:12:10 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA13229; Thu, 6 Jan 2000 10:12:39 -0500 (EST) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA13225; Thu, 6 Jan 2000 10:12:39 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id KAA19488; Thu, 6 Jan 2000 10:11:43 -0500 (EST) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id KAA01484; Thu, 6 Jan 2000 10:11:06 -0500 (EST) Message-Id: <200001061511.KAA01484@ara.missi.ncsc.mil> Date: Thu, 6 Jan 2000 10:11:06 -0500 (EST) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Vagueness in empty CRLs To: ietf-pkix@imc.org Cc: sharon.boeyen@entrust.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XECOMPCxtTxRR0t/uVjklw== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc > From: "Phillip M Hallam-Baker" > > [From Sharon Boeyen] > > However, the proposal to be to make that same restriction in X.509 itself > > does concern me a bit, primarily from the standpoint of backward > compatibility > > but also because we don't have a thorough way to ensure that making the > change > > wouldn't break some existing systems and environments outside PKIX. > > Given the choice between ASN.1 DER purity and backwards compatibility, give > me compatibility every time. > > I have never accepted that the DER rules met a real need and hearing the > argument again a fiftieth time is unlikely to convince me. I must have missed something, Phill -- who said anything about BER vs. DER? The issue is the encoding of a CRL which has no entries; the choices are 1) an empty SEQUENCE and 2) an absent SEQUENCE . Both options are legal in both BER and DER - there is nothing in X.690 section 10 or 11 which requires that empty optional sequences be elided. This is appropriate because in some cases there is a semantic difference between empty and absent. In the case of CRLs however, there is no semantic difference, just two different ways of saying "here's a CRL with no entries". You may believe that canonical encodings have no benefit; I believe they do. With regards to backwards compatibility, existing decoding software is not an issue; the only issue is whether "new" decoders would be broken by old encoders or old CRLs. Paul H. asked that question in the PKIX context; if a change were made to X.509 the question would have to be asked in a much larger context and answered to the satisfaction of every voting body. I agree with Sharon that there is no way to be 100% sure, but I would wager $0.50 that as of yesterday there was no CRL on earth (excluding deliberately-created test vectors) which has "no entries" represented as a zero-length SEQUENCE. And I agree with Sharon's position that it is appropriate for the PKIX profile to restrict X.509, as it already does by adding a SIZE constraint to Extensions. I disagree with Sharon's comment: > If we do go ahead with a proposed change to 509, I'd prefer it to be a > text clarification rather than a restructuring of the ASN.1, again > because of backward compatibility. There is no clarification possible; either both representations are allowed or only one is allowed. It doesn't matter whether the protocol is specified in prose, in ASN.1 comments, or in ASN.1 syntax, the protocol is as it is. If the ASN.1 is not changed, redundant text could be added to say that both cases are legal, but I don't believe there would be any value in adding such text. I do believe that adding text to allow only the absent sequence while leaving the ASN.1 unchanged would *not* be a clarification, it would be an obfuscation. The text (if present) and the syntax should agree, regardless of which outcomes are chosen for X.509 and for the PKIX profile. I recommend that PKIX add a SIZE constraint to revokedCertificates, but take no position with respect to X.509. From owner-ietf-pkix Thu Jan 6 07:47:13 2000 Received: from v4j31 (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10083 for ; Thu, 6 Jan 2000 07:47:13 -0800 (PST) Message-Id: <4.2.1.20000106073907.00c59e30@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Thu, 06 Jan 2000 07:47:55 -0800 To: ietf-pkix@imc.org From: Paul Hoffman / IMC Subject: RE: Vagueness in empty CRLs In-Reply-To: <200001061511.KAA01484@ara.missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:11 AM 1/6/00 -0500, David P. Kemp wrote: >I agree with Sharon that there is no way to be 100% sure, >but I would wager $0.50 that as of yesterday there was no CRL on earth >(excluding deliberately-created test vectors) which has "no entries" >represented as a zero-length SEQUENCE. You might owe me $0.50, depending on your definition of "yesterday". Oscar, a very capable open-source CA product (see , was generating empty CRLs with the zero-length SEQUENCE in version 3.1.3. 3.1.4 was issued last night that fixed this. Oscar is produced in Australia, so it was "today" there when it was "last night" here... Again, I think their reading of RFC 2459 was reasonable although not what the majority of people would have thought reading it. We have so many cases of "put a NULL in" or "must not put a NULL in" that we should be clear wherever we can. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-pkix Fri Jan 7 03:39:17 2000 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA17163 for ; Fri, 7 Jan 2000 03:39:17 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14115; Fri, 7 Jan 2000 06:39:25 -0500 (EST) Message-Id: <200001071139.GAA14115@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-time-stamp-05.txt Date: Fri, 07 Jan 2000 06:39:24 -0500 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP) Author(s) : C. Adams, P. Cain, D. Pinkas, R. Zuccherato Filename : draft-ietf-pkix-time-stamp-05.txt Pages : 20 Date : 06-Jan-00 A time stamping service allows to prove that a datum existed before a particular time and can be used as a Trusted Third Party (TTP) as one component in building reliable non-repudiation services (see [ISONR]). This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. An example on how to prove that a digital signature was generated during the validity period of the corresponding public key certificate is given in an annex. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-05.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-time-stamp-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-time-stamp-05.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: <20000106113436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-time-stamp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-time-stamp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000106113436.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Fri Jan 7 04:25:34 2000 Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA24273 for ; Fri, 7 Jan 2000 04:25:33 -0800 (PST) Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id NAA34066 for ; Fri, 7 Jan 2000 13:25:57 +0100 Message-ID: <3875DB42.7202CFA2@bull.net> Date: Fri, 07 Jan 2000 13:25:38 +0100 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.06 [fr] (Win95; I) MIME-Version: 1.0 To: IETF-PXIX Subject: TSP-05 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The latest draft is available at: http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-05.txt A few indications about the main changes: The error codes have been expanded to allow for a better indication about the reason of an error. A BOOLEAN has been added in the request so that it now become possible to ask for the inclusion or the exclusion of the TSA certificate in the response. The syntax of Accuracy has been changed so that it now becomes possible to have a precision of e.g. 1,5 seconds (this was not possible with the previous syntax !) An appendix (D) that contains the ASN1 module has been added. With this changes, I believe that the document is now ready for last call. Denis Note: At this time one OID value (for the ASN1 module) is still missing but will likely be obtained before the end of the last call. From owner-ietf-pkix Fri Jan 7 06:27:14 2000 Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05663 for ; Fri, 7 Jan 2000 06:27:13 -0800 (PST) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA16080; Fri, 7 Jan 2000 15:27:17 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 7 Jan 2000 15:27:16 +0100 (MET) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA08767; Fri, 7 Jan 2000 15:27:16 +0100 (MET) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA03913; Fri, 7 Jan 2000 15:27:15 +0100 (MET) Date: Fri, 7 Jan 2000 15:27:15 +0100 (MET) Message-Id: <200001071427.PAA03913@emeriau.edelweb.fr> To: Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: Re: TSP-05 Happy new year to all, The main change is that DEFINITIONS EXPLICIT TAGS ::= With that the EXPLICIT in extensions [3] EXPLICIT Extensions OPTIONAL seems to be redundant to me? Anyway, what is the purpose of that particular EXPLICIT and the global one? Is it a requirement to be able to decode a time stamp without knowing the syntax? From owner-ietf-pkix Fri Jan 7 06:27:44 2000 Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05730 for ; Fri, 7 Jan 2000 06:27:43 -0800 (PST) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jan 2000 09:27:23 -0500 Message-ID: From: Sharon Boeyen To: "'David P. Kemp'" Cc: ietf-pkix@imc.org Subject: RE: Vagueness in empty CRLs Date: Fri, 7 Jan 2000 09:27:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" David I agree with everything you said, and I'm certainly not going to bet against your wager and lose my $0.50 :-) I'm wondering if it would be useful to try to get a phrase added to 509 that "strongly recommends" that an empty SEQUENCE never be used. That might be helpful for guiding future implementations while still not breaking backward compatibility if David does lose his $0.50 wager. Do you think this is a "not worth the trouble" suggestion or something that would be good to try? I don't know how the 509 group would feel about it, since we're now at the DAM stage, but I could see a phrase of this sort being proposed as a clarification. Sharon > -----Original Message----- > From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] > Sent: Thursday, January 06, 2000 10:11 AM > To: ietf-pkix@imc.org > Cc: sharon.boeyen@entrust.com > Subject: RE: Vagueness in empty CRLs > > > > > From: "Phillip M Hallam-Baker" > > > > [From Sharon Boeyen] > > > However, the proposal to be to make that same restriction > in X.509 itself > > > does concern me a bit, primarily from the standpoint of backward > > compatibility > > > but also because we don't have a thorough way to ensure > that making the > > change > > > wouldn't break some existing systems and environments > outside PKIX. > > > > Given the choice between ASN.1 DER purity and backwards > compatibility, give > > me compatibility every time. > > > > I have never accepted that the DER rules met a real need > and hearing the > > argument again a fiftieth time is unlikely to convince me. > > > I must have missed something, Phill -- who said anything > about BER vs. DER? > > The issue is the encoding of a CRL which has no entries; the choices > are 1) an empty SEQUENCE and 2) an absent SEQUENCE . Both options are > legal in both BER and DER - there is nothing in X.690 section 10 or 11 > which requires that empty optional sequences be elided. This > is appropriate > because in some cases there is a semantic difference between empty and > absent. > > In the case of CRLs however, there is no semantic difference, just two > different ways of saying "here's a CRL with no entries". You > may believe > that canonical encodings have no benefit; I believe they do. > > With regards to backwards compatibility, existing decoding software is > not an issue; the only issue is whether "new" decoders would be broken > by old encoders or old CRLs. Paul H. asked that question in the PKIX > context; if a change were made to X.509 the question would have to be > asked in a much larger context and answered to the > satisfaction of every > voting body. I agree with Sharon that there is no way to be > 100% sure, > but I would wager $0.50 that as of yesterday there was no CRL on earth > (excluding deliberately-created test vectors) which has "no entries" > represented as a zero-length SEQUENCE. > > And I agree with Sharon's position that it is appropriate for the PKIX > profile to restrict X.509, as it already does by adding a SIZE > constraint to Extensions. > > I disagree with Sharon's comment: > > > If we do go ahead with a proposed change to 509, I'd prefer > it to be a > > text clarification rather than a restructuring of the ASN.1, again > > because of backward compatibility. > > There is no clarification possible; either both representations are > allowed or only one is allowed. It doesn't matter whether > the protocol > is specified in prose, in ASN.1 comments, or in ASN.1 syntax, > the protocol > is as it is. If the ASN.1 is not changed, redundant text could be > added to say that both cases are legal, but I don't believe > there would > be any value in adding such text. I do believe that adding text to > allow only the absent sequence while leaving the ASN.1 unchanged would > *not* be a clarification, it would be an obfuscation. The text (if > present) and the syntax should agree, regardless of which outcomes are > chosen for X.509 and for the PKIX profile. > > I recommend that PKIX add a SIZE constraint to > revokedCertificates, but > take no position with respect to X.509. > From owner-ietf-pkix Fri Jan 7 06:47:32 2000 Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07830 for ; Fri, 7 Jan 2000 06:47:30 -0800 (PST) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA16653; Fri, 7 Jan 2000 15:47:39 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 7 Jan 2000 15:47:39 +0100 (MET) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA08934; Fri, 7 Jan 2000 15:47:38 +0100 (MET) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA03927; Fri, 7 Jan 2000 15:47:37 +0100 (MET) Date: Fri, 7 Jan 2000 15:47:37 +0100 (MET) Message-Id: <200001071447.PAA03927@emeriau.edelweb.fr> To: ietf-pkix@imc.org, Denis.Pinkas@bull.net Subject: Re: TSP-05 Can you explain what you mean by: Conforming timestamping requesters MUST be able to recognize version 1 Timestamp tokens with all the optional fields present, but are not mandated to understand the semantics of any extension, if present. especially for critical extensions. Do you think about an actual requestor be a program that even regards the result? Ffor example a mail relay that adds a time stamp as a countersignature to an smime message while relaying it. In this case the requestor may be configured to not even look at the content and just verify the signature of the trustworthy tsa (and maybe the document type returned) From owner-ietf-pkix Fri Jan 7 15:45:41 2000 Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA14452 for ; Fri, 7 Jan 2000 15:45:40 -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.9.3/8.8.6/cs-master) with SMTP id MAA14003 for ; Sat, 8 Jan 2000 12:45:49 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <94728874918687>; Sat, 8 Jan 2000 12:45:49 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org Subject: Re: TSP-05 Sender: pgut001@cs.auckland.ac.nz Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Sat, 8 Jan 2000 12:45:49 (NZDT) Message-ID: <94728874918687@cs26.cs.auckland.ac.nz> Peter Sylvester writes: >The main change is that > > DEFINITIONS EXPLICIT TAGS ::= > >With that the EXPLICIT in > > extensions [3] EXPLICIT Extensions OPTIONAL > >seems to be redundant to me? Given that it's usual to use global implicit tags, isn't it kind of risky to use a setting which is the opposite to what everyone is expecting? If you drop the global EXPLICIT it'll be the same as the normal default, and the redundancy will go away. Peter. From owner-ietf-pkix Sat Jan 8 03:48:48 2000 Received: from energy.ogu.edu.tr (root@energy.ogu.edu.tr [193.140.141.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA09477 for ; Sat, 8 Jan 2000 03:48:43 -0800 (PST) From: blilrel16@aol.com Received: from energy.ogu.edu.tr (98C9FD37.ipt.aol.com [152.201.253.55]) by energy.ogu.edu.tr (8.8.8/8.8.4) with SMTP id NAA03408; Sat, 8 Jan 2000 13:42:58 +0200 Date: Sat, 08 Jan 00 01:43:26 EST To: Friend@public.com Subject: A Search Engine Just For You ! Message-ID: <> This e-mail is to inform you of a new search engine for adult web sites: http://www.adultfairlinks.com. Fairlinks is being built at this time and will be launched in a few months. We are contacting webmasters now so you can take a look at the site and give us any input you may have. This site will be unique since it will be a TRUE SEARCH ENGINE FOR ADULT SITES. There will be no banner ads, no support from any adult site. All categories will rotate so that each site will be at the top. Two thirds of all money collected will then be used to promote Fairlinks. Most advertising will be done off the web with plans already made to market the site on the Internet. We are going to pool thousands of adult sites together to form a partnership that will make a formidable force and to have funds for national advertising. Please take a look, join in and get your site promoted as it should be! http://www.adultfairlinks.com To be removed, call (888) 341-4786 and Clearly spell your email address and you will be removed. From owner-ietf-pkix Sat Jan 8 08:31:02 2000 Received: from ns1.tu-graz.ac.at (ns1.tu-graz.ac.at [129.27.2.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12092 for ; Sat, 8 Jan 2000 08:31:01 -0800 (PST) Received: from oben (isdn091.tu-graz.ac.at [129.27.240.91]) by ns1.tu-graz.ac.at (8.9.3/8.9.3) with SMTP id RAA09058 for ; Sat, 8 Jan 2000 17:31:13 +0100 (MET) Message-ID: <007001bf59fe$63ccbab0$0100a8c0@oben> From: "Petra Wuensche" To: Subject: OCSP Date: Sat, 8 Jan 2000 17:32:37 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Hello! I'm a student in Graz (Austria), university of technology. I'm working at a project where I have to implement OCSP. I'd now need a possibility to test my work. So could you tell me a server, which uses OCSP? Thanks in advance, Petra Wuensche From owner-ietf-pkix Sun Jan 9 04:05:09 2000 Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA11126 for ; Sun, 9 Jan 2000 04:05:08 -0800 (PST) Received: from secude.com ([141.12.156.32]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id NAA18168 for ; Sun, 9 Jan 2000 13:04:56 +0100 (MET) Message-ID: <3877681C.35FF3B31@secude.com> Date: Sat, 08 Jan 2000 17:38:52 +0100 From: Harald Giehl Organization: SECUDE GmbH X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: de MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: unsubscribe Content-Type: multipart/mixed; boundary="------------A3BEC50B90E854C960C82118" This is a multi-part message in MIME format. --------------A3BEC50B90E854C960C82118 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe --------------A3BEC50B90E854C960C82118 Content-Type: text/x-vcard; charset=us-ascii; name="giehl.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Harald Giehl Content-Disposition: attachment; filename="giehl.vcf" begin:vcard n:Giehl;Harald tel;fax:+49 61 51 - 88 00 6 26 tel;work:+49 61 51 - 88 00 60 x-mozilla-html:FALSE url:http://www.secude.com org:SECUDE Sicherheitstechnologie Informationssysteme GmbH adr:;;Landwehrstraße 50a;Darmstadt;;64293;Germany version:2.1 email;internet:giehl@secude.com x-mozilla-cpt:;-1 fn:Harald Giehl end:vcard --------------A3BEC50B90E854C960C82118-- From owner-ietf-pkix Mon Jan 10 04:28:32 2000 Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA05634 for ; Mon, 10 Jan 2000 04:28:31 -0800 (PST) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA11706; Mon, 10 Jan 2000 13:28:53 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Mon, 10 Jan 2000 13:28:52 +0100 (MET) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA19378; Mon, 10 Jan 2000 13:28:51 +0100 (MET) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA05352; Mon, 10 Jan 2000 13:28:51 +0100 (MET) Date: Mon, 10 Jan 2000 13:28:51 +0100 (MET) Message-Id: <200001101228.NAA05352@emeriau.edelweb.fr> To: Denis.Pinkas@bull.net Subject: Re: TSP-05 Cc: ietf-pkix@imc.org > Note: At this time one OID value (for the ASN1 module) is still > missing but will likely be obtained before the end of the last call. > I can't find a definition for id-kp-timeStamping . The TSA MUST sign all time stamp messages with one or more keys reserved specifically for that purpose. The corresponding certificate MUST contain only one instance of the extended key usage field extension as defined in [RFC2459] Section 4.2.1.13 with KeyPurposeID having value id-kp-timeStamping. This extension MUST be critical. From owner-ietf-pkix Mon Jan 10 05:25:42 2000 Received: from Newman.GSC.GTE.Com (SYSTEM@Newman.GSC.GTE.Com [192.160.62.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA06481 for ; Mon, 10 Jan 2000 05:25:41 -0800 (PST) Received: from gscex01.gsc.gte.com ("port 2405"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #38015) with ESMTP id <01JKJ76KYR4M003BUK@Newman.GSC.GTE.Com> for ietf-pkix@imc.org; Mon, 10 Jan 2000 08:26:03 EST Received: by GSCEX01.gsc.gte.com with Internet Mail Service (5.5.2448.0) id ; Mon, 10 Jan 2000 08:26:04 -0500 Content-return: allowed Date: Mon, 10 Jan 2000 08:26:00 -0500 From: "Sweigert, David" Subject: RE: OCSP To: Petra Wuensche , ietf-pkix@imc.org Message-id: <2575327B6755D211A0E100805F9FF954047A0578@ndhmex02.ndhm.gsc.gte.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: text/plain; charset="iso-8859-1" Verisign actively supports OCSP, as well as E-LOCK Technologies. -----Original Message----- From: Petra Wuensche [mailto:tintifax@sbox.tu-graz.ac.at] Sent: Saturday, January 08, 2000 12:33 PM To: ietf-pkix@imc.org Subject: OCSP Hello! I'm a student in Graz (Austria), university of technology. I'm working at a project where I have to implement OCSP. I'd now need a possibility to test my work. So could you tell me a server, which uses OCSP? Thanks in advance, Petra Wuensche From owner-ietf-pkix Mon Jan 10 06:22:02 2000 Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07514 for ; Mon, 10 Jan 2000 06:22:01 -0800 (PST) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA13813; Mon, 10 Jan 2000 15:22:18 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Mon, 10 Jan 2000 15:22:17 +0100 (MET) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA19758; Mon, 10 Jan 2000 15:22:17 +0100 (MET) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA05387; Mon, 10 Jan 2000 15:22:16 +0100 (MET) Date: Mon, 10 Jan 2000 15:22:16 +0100 (MET) Message-Id: <200001101422.PAA05387@emeriau.edelweb.fr> To: Denis.Pinkas@bull.net Subject: Re: TSP-05 Cc: ietf-pkix@imc.org > > > > I can't find a definition for id-kp-timeStamping . > Oops, sorry for the previous mail. Please ignore it, the value is defined in rfc2459 From owner-ietf-pkix Mon Jan 10 08:52:41 2000 Received: from mail.rdc1.az.home.com (imail@ha1.rdc1.az.home.com [24.1.240.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09988 for ; Mon, 10 Jan 2000 08:52:41 -0800 (PST) Received: from cyclonecommerce.com ([24.1.214.107]) by mail.rdc1.az.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000110165306.QBTG2369.mail.rdc1.az.home.com@cyclonecommerce.com>; Mon, 10 Jan 2000 08:53:06 -0800 Message-ID: <387A0F2E.A8F5FE54@cyclonecommerce.com> Date: Mon, 10 Jan 2000 09:56:14 -0700 From: Timothy Fisher X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Sweigert, David" CC: Petra Wuensche , ietf-pkix@imc.org Subject: Re: OCSP References: <2575327B6755D211A0E100805F9FF954047A0578@ndhmex02.ndhm.gsc.gte.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Do either of those vendors have an OCSP server available for testing with though? Tim "Sweigert, David" wrote: > Verisign actively supports OCSP, as well as E-LOCK Technologies. > > -----Original Message----- > From: Petra Wuensche [mailto:tintifax@sbox.tu-graz.ac.at] > Sent: Saturday, January 08, 2000 12:33 PM > To: ietf-pkix@imc.org > Subject: OCSP > > Hello! > > I'm a student in Graz (Austria), university of technology. I'm > working at a project where I have to implement OCSP. > I'd now need a possibility to test my work. So could you tell me a > server, which uses OCSP? > > Thanks in advance, > > Petra Wuensche From owner-ietf-pkix Mon Jan 10 09:24:48 2000 Received: from indy.gradient.com (indy.gradient.com [192.92.110.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10474 for ; Mon, 10 Jan 2000 09:24:47 -0800 (PST) Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id MAA28867; Mon, 10 Jan 2000 12:23:58 -0500 (EST) Received: by bigbird.gradient.com with Internet Mail Service (5.5.2448.0) id ; Mon, 10 Jan 2000 12:22:40 -0500 Message-ID: <899128A30EEDD1118FC900A0C9C74A344D7800@bigbird.gradient.com> From: John Herendeen To: "'Timothy Fisher'" , "Sweigert, David" Cc: Petra Wuensche , ietf-pkix@imc.org Subject: RE: OCSP Date: Mon, 10 Jan 2000 12:22:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Try www.valicert.com their ValiCert Enterprise VA is an OCSP server John Herendeen -----Original Message----- From: Timothy Fisher [mailto:tfisher@cyclonecommerce.com] Sent: Monday, January 10, 2000 11:56 AM To: Sweigert, David Cc: Petra Wuensche; ietf-pkix@imc.org Subject: Re: OCSP Do either of those vendors have an OCSP server available for testing with though? Tim "Sweigert, David" wrote: > Verisign actively supports OCSP, as well as E-LOCK Technologies. > > -----Original Message----- > From: Petra Wuensche [mailto:tintifax@sbox.tu-graz.ac.at] > Sent: Saturday, January 08, 2000 12:33 PM > To: ietf-pkix@imc.org > Subject: OCSP > > Hello! > > I'm a student in Graz (Austria), university of technology. I'm > working at a project where I have to implement OCSP. > I'd now need a possibility to test my work. So could you tell me a > server, which uses OCSP? > > Thanks in advance, > > Petra Wuensche From owner-ietf-pkix Mon Jan 10 09:28:30 2000 Received: from mail.rdc1.az.home.com (imail@ha1.rdc1.az.home.com [24.1.240.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10668 for ; Mon, 10 Jan 2000 09:28:30 -0800 (PST) Received: from cyclonecommerce.com ([24.1.214.107]) by mail.rdc1.az.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000110172856.QLMG2369.mail.rdc1.az.home.com@cyclonecommerce.com>; Mon, 10 Jan 2000 09:28:56 -0800 Message-ID: <387A1794.B940EDFF@cyclonecommerce.com> Date: Mon, 10 Jan 2000 10:32:04 -0700 From: Timothy Fisher X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: John Herendeen CC: "Sweigert, David" , Petra Wuensche , ietf-pkix@imc.org Subject: Re: OCSP References: <899128A30EEDD1118FC900A0C9C74A344D7800@bigbird.gradient.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Do they make it available for testing? Tim John Herendeen wrote: > Try > > www.valicert.com > > their ValiCert Enterprise VA is an OCSP server > > John Herendeen > > -----Original Message----- > From: Timothy Fisher [mailto:tfisher@cyclonecommerce.com] > Sent: Monday, January 10, 2000 11:56 AM > To: Sweigert, David > Cc: Petra Wuensche; ietf-pkix@imc.org > Subject: Re: OCSP > > Do either of those vendors have an OCSP server available for testing > with though? > > Tim > > "Sweigert, David" wrote: > > > Verisign actively supports OCSP, as well as E-LOCK Technologies. > > > > -----Original Message----- > > From: Petra Wuensche [mailto:tintifax@sbox.tu-graz.ac.at] > > Sent: Saturday, January 08, 2000 12:33 PM > > To: ietf-pkix@imc.org > > Subject: OCSP > > > > Hello! > > > > I'm a student in Graz (Austria), university of technology. I'm > > working at a project where I have to implement OCSP. > > I'd now need a possibility to test my work. So could you tell me a > > server, which uses OCSP? > > > > Thanks in advance, > > > > Petra Wuensche From owner-ietf-pkix Mon Jan 10 12:32:00 2000 Received: from atdev1.alphatrust.com ([209.39.43.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12774 for ; Mon, 10 Jan 2000 12:31:55 -0800 (PST) Received: by ATDEV1 with Internet Mail Service (5.5.2448.0) id ; Mon, 10 Jan 2000 14:36:29 -0600 Message-ID: <9E60D6A452AAD211904E00105A1973FD072ADE@ATDEV1> From: "Bill Brice (listserv)" To: "'Timothy Fisher'" , John Herendeen Cc: "Sweigert, David" , Petra Wuensche , ietf-pkix@imc.org Subject: RE: OCSP Date: Mon, 10 Jan 2000 14:36:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" John & Petra, You are welcome to validate against our OCSP server at: http://validate.alphatrust.com If you would like a copy of a revoked cert to test, please let me know off list. Thanks. Bill Brice http://alphatrust.com -----Original Message----- From: Timothy Fisher [mailto:tfisher@cyclonecommerce.com] Sent: Monday, January 10, 2000 11:32 AM To: John Herendeen Cc: Sweigert, David; Petra Wuensche; ietf-pkix@imc.org Subject: Re: OCSP Do they make it available for testing? Tim John Herendeen wrote: > Try > > www.valicert.com > > their ValiCert Enterprise VA is an OCSP server > > John Herendeen > > -----Original Message----- > From: Timothy Fisher [mailto:tfisher@cyclonecommerce.com] > Sent: Monday, January 10, 2000 11:56 AM > To: Sweigert, David > Cc: Petra Wuensche; ietf-pkix@imc.org > Subject: Re: OCSP > > Do either of those vendors have an OCSP server available for testing > with though? > > Tim > > "Sweigert, David" wrote: > > > Verisign actively supports OCSP, as well as E-LOCK Technologies. > > > > -----Original Message----- > > From: Petra Wuensche [mailto:tintifax@sbox.tu-graz.ac.at] > > Sent: Saturday, January 08, 2000 12:33 PM > > To: ietf-pkix@imc.org > > Subject: OCSP > > > > Hello! > > > > I'm a student in Graz (Austria), university of technology. I'm > > working at a project where I have to implement OCSP. > > I'd now need a possibility to test my work. So could you tell me a > > server, which uses OCSP? > > > > Thanks in advance, > > > > Petra Wuensche From owner-ietf-pkix Mon Jan 10 12:41:35 2000 Received: from saqr.astrid.net ([209.19.106.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13053 for ; Mon, 10 Jan 2000 12:41:34 -0800 (PST) Received: from xetex.com (adsl-63-194-208-146.dsl.snfc21.pacbell.net [63.194.208.146]) by saqr.astrid.net (8.9.3/8.9.3) with ESMTP id MAA06242; Mon, 10 Jan 2000 12:46:35 -0800 (PST) Message-ID: <387A43DB.DB230B1E@xetex.com> Date: Mon, 10 Jan 2000 12:40:59 -0800 From: Ed Posnak Organization: Xetex Corporation X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Timothy Fisher CC: John Herendeen , "Sweigert, David" , Petra Wuensche , ietf-pkix@imc.org, "Hicks, G Mack" Subject: Re: OCSP References: <899128A30EEDD1118FC900A0C9C74A344D7800@bigbird.gradient.com> <387A1794.B940EDFF@cyclonecommerce.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Timothy Fisher wrote: > Do they make it available for testing? There is an OCSP responder available for test at http://ocsp.xetex.com/servlet/ocsp. In order to get interesting responses, you will want to get our issuer name & key hash, or CA and end-entity certs. If anyone is interested, please contact me and I will provide these. ejp From owner-ietf-pkix Mon Jan 10 13:17:15 2000 Received: from surf2.ameritraininc.com (host29.cynet.net [207.224.29.29] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13564 for ; Mon, 10 Jan 2000 13:17:11 -0800 (PST) Received: from WIN2KTEST (netwalkr2.erols.com [216.164.109.18]) by surf2.ameritraininc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CN9BQAT3; Mon, 10 Jan 2000 16:25:27 -0500 From: "Chris" To: Subject: Date: Mon, 10 Jan 2000 16:20:35 -0500 Message-ID: <000501bf5bb0$890dadd0$0119040a@test.lab4.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01BF5B86.A037A5D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01BF5B86.A037A5D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subscribe ------=_NextPart_000_0006_01BF5B86.A037A5D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 

Subscribe<= /p>

------=_NextPart_000_0006_01BF5B86.A037A5D0-- From owner-ietf-pkix Mon Jan 10 13:31:13 2000 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13862 for ; Mon, 10 Jan 2000 13:31:13 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id NAA17334 for ; Mon, 10 Jan 2000 13:31:09 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id NAA00718 for ; Mon, 10 Jan 2000 13:31:09 -0800 X-Virus-Scanned: Mon, 10 Jan 2000 13:31:09 -0800 Nokia Silicon Valley AntiVirus Appliance Received: from (dhcp-15-43.iprg.nokia.com [205.226.15.43]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma000471; Mon, 10 Jan 00 13:31:03 -0800 Message-ID: <387A4F76.EC21D38F@iprg.nokia.com> Date: Mon, 10 Jan 2000 13:30:30 -0800 From: Tom Tang X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit subscribe From owner-ietf-pkix Mon Jan 10 15:24:22 2000 Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15161 for ; Mon, 10 Jan 2000 15:24:21 -0800 (PST) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jan 2000 15:18:21 -0800 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE25132AF@seine.valicert.com> From: Khaja Ahmed To: Petra Wuensche , ietf-pkix@imc.org Subject: RE: OCSP Date: Mon, 10 Jan 2000 15:18:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF5BC0.FBB1657E" 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_000_01BF5BC0.FBB1657E Content-Type: text/plain; charset="iso-8859-1" Petra, ValiCert runs an OCSP responder that may be used by third parties to test their OCSP implementation. This is intended as a reference site. The OCSP responder is ocsptest1.valicert.com. You may find more details about this on www.valicert.com. Khaja __________________________________________________________________ Khaja E. Ahmed, Director of Engineering; Core Product Development ValiCert Inc., 1215 Terra Bella Ave, Mountain View, CA 94043 Phone/Fax : 650.567.5485 (Work) ; 650.254.2148 (Fax) Email/Web : khajaa@valicert.com ; http://www.valicert.com/ Directions : NW Corner of Shoreline & Terra Bella, West of 101 ___________________________________________________________________ -----Original Message----- From: Petra Wuensche [mailto:tintifax@sbox.tu-graz.ac.at] Sent: Saturday, January 08, 2000 9:33 AM To: ietf-pkix@imc.org Subject: OCSP Hello! I'm a student in Graz (Austria), university of technology. I'm working at a project where I have to implement OCSP. I'd now need a possibility to test my work. So could you tell me a server, which uses OCSP? Thanks in advance, Petra Wuensche ------_=_NextPart_000_01BF5BC0.FBB1657E Content-Type: application/octet-stream; name="KhajaEAhmed.vcf" Content-Disposition: attachment; filename="KhajaEAhmed.vcf" BEGIN:VCARD VERSION:2.1 N:Ahmed;Khaja;E.;; FN:Khaja E. Ahmed ORG:ValiCert, Inc.;Engineering TITLE:Director Of Engineering; Core Products TEL;WORK;VOICE:(650) 567-5485 TEL;HOME;VOICE:(925) 462-0453 TEL;CELL;VOICE:(925) 989-6564 TEL;WORK;FAX:(650) 254-2148 ADR;WORK:;Mounatain View;1215 Terra Bella Av.;Mountain View;CA;94043-1833;United States of America LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Mounatain View=0D=0A1215 Terra Bella Av.=0D=0AMountain View, CA 94043-1833= =0D=0AUnited States of America URL: URL:http://www.valicert.com/ ROLE:Engineering EMAIL;PREF;INTERNET:khajaa@valicert.com REV:19991118T230251Z END:VCARD ------_=_NextPart_000_01BF5BC0.FBB1657E-- From owner-ietf-pkix Mon Jan 10 22:10:56 2000 Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA17464 for ; Mon, 10 Jan 2000 22:10:56 -0800 (PST) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jan 2000 22:04:55 -0800 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE234392D@seine.valicert.com> From: Ambarish Malpani To: "'Timothy Fisher'" , John Herendeen Cc: "Sweigert, David" , Petra Wuensche , ietf-pkix@imc.org, Khaja Ahmed , Venky Nakhate Subject: RE: OCSP Date: Mon, 10 Jan 2000 22:04:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Hi Tim, Yes, we do make our ocsp server available for testing. You can get instructions on how to reach it by going to: http://www.valicert.com/ocsp Unfortunately, the CA Delegated Trust mode of OCSP won't quite work, because the delegated cert has expired.... :-( Will try to fix that some time. Please let me know how it goes. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 1215 Terra Bella Ave. http://www.valicert.com Mountain View, CA 94043-1833 > -----Original Message----- > From: Timothy Fisher [mailto:tfisher@cyclonecommerce.com] > Sent: Monday, January 10, 2000 9:32 AM > To: John Herendeen > Cc: Sweigert, David; Petra Wuensche; ietf-pkix@imc.org > Subject: Re: OCSP > > > Do they make it available for testing? > > Tim > > John Herendeen wrote: > > > Try > > > > www.valicert.com > > > > their ValiCert Enterprise VA is an OCSP server > > > > John Herendeen > > > > -----Original Message----- > > From: Timothy Fisher [mailto:tfisher@cyclonecommerce.com] > > Sent: Monday, January 10, 2000 11:56 AM > > To: Sweigert, David > > Cc: Petra Wuensche; ietf-pkix@imc.org > > Subject: Re: OCSP > > > > Do either of those vendors have an OCSP server available for testing > > with though? > > > > Tim > > > > "Sweigert, David" wrote: > > > > > Verisign actively supports OCSP, as well as E-LOCK Technologies. > > > > > > -----Original Message----- > > > From: Petra Wuensche [mailto:tintifax@sbox.tu-graz.ac.at] > > > Sent: Saturday, January 08, 2000 12:33 PM > > > To: ietf-pkix@imc.org > > > Subject: OCSP > > > > > > Hello! > > > > > > I'm a student in Graz (Austria), university of technology. I'm > > > working at a project where I have to implement OCSP. > > > I'd now need a possibility to test my work. So could you tell me a > > > server, which uses OCSP? > > > > > > Thanks in advance, > > > > > > Petra Wuensche > From owner-ietf-pkix Thu Jan 13 06:02:18 2000 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA22014 for ; Thu, 13 Jan 2000 06:02:18 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA11291 for ; Thu, 13 Jan 2000 06:02:57 -0800 (PST) Received: from saguaro.East.Sun.COM (saguaro.East.Sun.COM [129.148.75.130]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA03869 for ; Thu, 13 Jan 2000 09:02:54 -0500 (EST) Received: (from aha@localhost) by saguaro.East.Sun.COM (8.9.1b+Sun/8.9.1) id JAA21180; Thu, 13 Jan 2000 09:02:53 -0500 (EST) From: Anne Anderson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14461.56077.26746.942076@gargle.gargle.HOWL> Date: Thu, 13 Jan 2000 09:02:53 -0500 (EST) To: ietf-pkix@imc.org Subject: Need certificate with CRLDistributionPoints extension X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Does anyone have a certificate containing a CRLDistributionPoints extension that I could test against? I'm having trouble separating what needs to be explicit encoding and what needs to be implicit encoding in the distributionPoint option. Anne -- Anne H. Anderson Email: aha@acm.org Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692 From owner-ietf-pkix Fri Jan 14 06:21:33 2000 Received: from cybergateway.net ([206.104.28.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA29253; Fri, 14 Jan 2000 06:21:32 -0800 (PST) From: becky2421@aol.com Received: from 206.104.28.14 [152.172.118.203] by cybergateway.net (SMTPD32-5.01) id A4879CD01FE; Fri, 14 Jan 2000 08:55:35 +0100 Received: from jason@gulfcoast.net by jason@gulfcoast.net (8.8.5/8.6.5) with SMTP id GAA07984 for < jason@gulfcoast.net>; Fri, 14 Jan 2000 07:38:29 -0600 (EST) Date: Fri, 14 Jan 00 07:38:29 EST To: jason@gulfcoast.net Subject: New USA and International Merchant Accounts Message-ID: <> Reply-To: jason@gulfcoast.net Comments: Authenticated sender is < jason@gulfcoast.net> NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW U.S.A. and INTERNATIONAL MERCHANT ACCOUNTS FOR THE WORLD. Click below to Apply http://hypermart.com@3462929566/%63ar%64%73%65%72%76%69%63%65/%64%65%66%61u%6C%74%2Eh%74%6D#@3626198025/%63%61%72d%73%65%72%76%69%63%65/d%65fa%75%6C%74%2E%68%74%6D#@3462929566/ca%72d%73%65%72%76%69%63%65%32/%69%6E%64%65%78%2E%68%74%6D@3491382728/%63a%72d%73e%72%76%69%63%65/%64e%66%61%75%6C%74%2E%68t%6D ARE YOU REALLY AN E-COMMERCE MERCHANT? Increase your revenues by up to 1500% by accepting credit cards and electronic checks. Increase your customer base 200- 400% with instant access to the World. ARE YOU PAYING TOO MUCH? Discount rates start at 2.1% Transaction fees start at 25 cents. DO YOU WAIT TOO LONG FOR YOUR MONEY? Funds available in 24-48 hours anywhere in the world DO YOU HAVE DIFFICULTY GETTING MERCHANT ACCOUNTS 99% of all applications are approved. ARE YOU LIMITED BY WHAT YOU CAN ACCEPT? Mastercard, Visa, Discover, Amex and Checks (USA checks only) All cards from ALL COUNTRIES - Including Eastern Europe and Asia - - - - - - - - - - - Click HERE to APPLY. http://hypermart.com@3462929566/%63ar%64%73%65%72%76%69%63%65/%64%65%66%61u%6C%74%2Eh%74%6D#@3626198025/%63%61%72d%73%65%72%76%69%63%65/d%65fa%75%6C%74%2E%68%74%6D#@3462929566/ca%72d%73%65%72%76%69%63%65%32/%69%6E%64%65%78%2E%68%74%6D@3491382728/%63a%72d%73e%72%76%69%63%65/%64e%66%61%75%6C%74%2E%68t%6D - NOTE: THIS IS NOT AN APPLICATION FOR A PERSONAL CREDIT CARD BUT FOR A MERCHANT ACCOUNT. - - - - - - - - - - - To be removed from our mailing list, call (888) 341-4786 Clearly spell your email address and you will be removed. 111 1 111 T From owner-ietf-pkix Sat Jan 15 06:12:37 2000 Received: from goliath.siemens.de (goliath.siemens.de [194.138.37.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA29090 for ; Sat, 15 Jan 2000 06:12:36 -0800 (PST) X-Envelope-Sender-Is: oliver.pfaff@mchp.siemens.de (at relayer goliath.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.9.3/8.9.3) with ESMTP id PAA12776 for ; Sat, 15 Jan 2000 15:13:25 +0100 (MET) Received: from mail-k.mchp.siemens.de (mail-k.mchp.siemens.de [139.23.202.237]) by mail2.siemens.de (8.9.3/8.9.3) with ESMTP id PAA14484 for ; Sat, 15 Jan 2000 15:13:25 +0100 (MET) Received: from mchp.siemens.de (m68939pp.mchp.siemens.de [139.23.202.121]) by mail-k.mchp.siemens.de (8.9.3/8.9.3) with ESMTP id PAA05778 for ; Sat, 15 Jan 2000 15:13:23 +0100 (MET) Message-ID: <38808078.1421C777@mchp.siemens.de> Date: Sat, 15 Jan 2000 15:13:12 +0100 From: Oliver Pfaff X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: CRMF support Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm trying to get an overview on vendors/systems that support CRMF as certificate request format. According to a quick Internet search, Netscape (CMS - Certificate Management System) and Baltimore (UniCERT) are supporting CRMF. Are there other vendors/systems supporting CRMF? Thanks, Oliver From owner-ietf-pkix Sat Jan 15 09:55:13 2000 Received: from mail.rdc1.az.home.com (imail@ha1.rdc1.az.home.com [24.1.240.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01689 for ; Sat, 15 Jan 2000 09:55:13 -0800 (PST) Received: from cyclonecommerce.com ([24.1.214.107]) by mail.rdc1.az.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000115175604.YOWJ2369.mail.rdc1.az.home.com@cyclonecommerce.com>; Sat, 15 Jan 2000 09:56:04 -0800 Message-ID: <3880B56C.BC17B406@cyclonecommerce.com> Date: Sat, 15 Jan 2000 10:59:08 -0700 From: Timothy Fisher X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Oliver Pfaff CC: ietf-pkix@imc.org Subject: Re: CRMF support References: <38808078.1421C777@mchp.siemens.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cyclone Commerce (www.cyclonecommerce.com) supports CRMF in our Crossworks Security Framework. Timothy Fisher tfisher@cyclonecommerce.com www.cyclonecommerce.com Oliver Pfaff wrote: > I'm trying to get an overview on vendors/systems that support CRMF as > certificate request format. According to a quick Internet search, > Netscape (CMS - Certificate Management System) and Baltimore (UniCERT) > are supporting CRMF. Are there other vendors/systems supporting CRMF? > Thanks, > Oliver From owner-ietf-pkix Mon Jan 17 06:22:23 2000 Received: from hpheger3.nm.informatik.uni-muenchen.de (vogt@hpheger3.nm.informatik.uni-muenchen.de [129.187.214.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07242 for ; Mon, 17 Jan 2000 06:22:16 -0800 (PST) Received: (from vogt@localhost) by hpheger3.nm.informatik.uni-muenchen.de (8.9.3 (PHNE_18979)/8.8.6) id PAA03391 for ietf-pkix@imc.org; Mon, 17 Jan 2000 15:23:10 +0100 (MET) Date: Mon, 17 Jan 2000 15:23:10 +0100 (MET) Message-Id: <200001171423.PAA03391@hpheger3.nm.informatik.uni-muenchen.de> From: USM 2000 Organisation Committee To: USM 2000 Subject: USM 2000 - Last Call for Papers (Please apologize, if you receive multiple copies of this CfP) USM 2000: LAST CALL FOR PAPERS 3rd IFIP/GI International Conference on Trends towards a Universal Service Market Munich, Germany September 12-14, 2000 General Information USM 2000 is the third event in a series of international IFIP conferences on Trends in Distributed Systems. It continues TreDS'96, held in Aachen, Germany and TrEC'98 with special focus on Electronic Commerce in Hamburg, Germany. The technological progress in internet and telecommunication domains as well as deregulation efforts of the telecommunication markets currently under way in many countries enable an integration of data and telecommunication. Distributed platforms get adapted to the needs of telecommunication networks. This leads to a global distributed system with millions of objects, running on top of a middleware kernel and interacting with each other to provide services. USM 2000 brings together researchers, service vendors and users in the field of universal service markets. USM 2000 takes place in Munich, Germany, the city of the famous Oktoberfest which will start two days after the conference on September 16, 2000. Topics The USM 2000 considers services of a universal market in relation to middleware, distributed applications and management. Areas of special interest include: * Component Based Systems, Service Creation * Service Market Models, Accounting and Customer Care * Quality of Service for Distributed Applications * Trading, Brokering and Information Management * Management of Virtual Networks * Service and Application Management * Ubiquitous Services and Nomadic Computing * Distributed and Mobile Objects * Agent Technology for Integrated Management * Advances in Middleware, e.g. CORBA, DCOM, Jini * Telecommunication Architectures related to Distributed Systems Submissions You are encouraged to submit full technical papers describing original, unpublished research or experience of about 12 pages. Extended abstracts of 3-5 pages will be accepted for poster session papers. For submission guidelines please visit our web server. The proceedings will be published in "Lecture Notes in Computer Science", Springer-Verlag. Submissions due: January 30th, 2000 Notice of Acceptance: April 15th, 2000 Camera-ready Paper due: June 1st, 2000 Further Information Contact Person: Helmut Reiser - Phone (Fax): +49 89 2178 2163 (~2147) e-mail: usm2000@informatik.uni-muenchen.de, WWW: http://usm2000.informatik.uni-muenchen.de/ Address: Ludwig Maximilians University Institute for Computer Science Oettingenstr. 67 D-80538 Munich GERMANY Conference Chairs Claudia Linnhoff-Popien and Heinz-Gerd Hegering, LMU Munich Program Committee Sebastian Abeck, Uni Karlsruhe, Germany Andrew T. Campbell, Center for Telecommunications Research, Columbia Uni New York, USA John Dilley, Hewlett Packard, Palo Alto, USA Kurt Geihs, Uni Frankfurt, Germany Bernd Heinrichs, Cisco Systems Europe, Düsseldorf, Germany Yigal Hoffner, IBM Zurich Research Laboratory, Switzerland Axel Küpper, RWTH Aachen, Germany Lea Kutvonen, Uni Helsinki, Finland Winfried Lamersdorf, Uni Hamburg, Germany Luigi Logrippo, Uni Ottawa, Canada Michael Merz, Ponton, Hamburg, Germany Zoran Milosevic, DSTC Brisbane, Australia Elie Najm, Ecole Nationale Superieure des Telecommunications, Paris, France Bernhard Neumair, DeTeSystem, Germany Jerome Rolia, Uni Ottawa, Canada Alexander Schill, TU Dresden, Germany Doug Schmidt, ARL St. Louis, USA Gerd Schürmann, GMD FOKUS, Germany Morris Sloman, Imperial College, London, UK Otto Spaniol, RWTH Aachen, Germany Michael Stal, Siemens ZT, München, Germany Ralf Steinmetz, TU Darmstadt, Germany Volker Tschammer, GMD FOKUS, Berlin, Germany Conference Organisation Helmut Reiser (Chair), Christian Ensel, Markus Garschhammer, Rainer Hauck, Bernhard Kempter, Annette Kostelezky, Igor Radisic, Holger Schmidt, Gerald Vogt, LMU Munich Sponsors Ludwig-Maximilians-University (LMU) International Federation for Information Processing (IFIP) German Informatics Society (GI) Computing Centre of the Bavarian Academy of Sciences (LRZ) BMW AG DG Bank Bavaria's Software Initiative Munich Network Management Team (MNM) and others From owner-ietf-pkix Mon Jan 17 10:23:46 2000 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11335 for ; Mon, 17 Jan 2000 10:23:46 -0800 (PST) From: tgindin@us.ibm.com Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA221350; Mon, 17 Jan 2000 13:23:37 -0500 Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id NAA249368; Mon, 17 Jan 2000 13:24:40 -0500 Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256869.00652195 ; Mon, 17 Jan 2000 13:24:37 -0500 X-Lotus-FromDomain: IBMUS To: Oliver Pfaff cc: ietf-pkix@imc.org Message-ID: <85256869.0064D4F9.00@D51MTA05.pok.ibm.com> Date: Mon, 17 Jan 2000 13:18:20 -0500 Subject: Re: CRMF support Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline IBM's Trust Authority also supports CMP, including CRMF. Its home page is http://www.ibm.com/software/security/trust/. Tom Gindin Oliver Pfaff on 01/15/2000 09:13:12 AM To: ietf-pkix@imc.org cc: Subject: CRMF support I'm trying to get an overview on vendors/systems that support CRMF as certificate request format. According to a quick Internet search, Netscape (CMS - Certificate Management System) and Baltimore (UniCERT) are supporting CRMF. Are there other vendors/systems supporting CRMF? Thanks, Oliver From owner-ietf-pkix Thu Jan 20 01:19:17 2000 Received: from www.cryptomathic.dk (cryptomathic.dk [194.239.238.251]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA08934 for ; Thu, 20 Jan 2000 01:19:06 -0800 (PST) Received: from cryptomathic.com (fw.cryptomathic.dk [10.0.1.1]) by www.cryptomathic.dk (8.9.3/8.9.3) with ESMTP id KAA14385; Thu, 20 Jan 2000 10:42:00 +0100 Message-ID: <3886D35E.67D3ABC5@cryptomathic.com> Date: Thu, 20 Jan 2000 10:20:30 +0100 From: Anette Byskov Reply-To: abyskov@cryptomathic.com Organization: Cryptomathic X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-pkix@imc.org" , Oliver Pfaff Subject: Re: CRMF support Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cryptomathic's CA product INCA also supports CRMF: http://www.cryptomathic.dk/products/inca/inca.html Oliver Pfaff wrote: > > I'm trying to get an overview on vendors/systems that support CRMF as > certificate request format. According to a quick Internet search, > Netscape (CMS - Certificate Management System) and Baltimore (UniCERT) > are supporting CRMF. Are there other vendors/systems supporting CRMF? > Thanks, > Oliver -- Anette Byskov Cryptomathic A/S Phone: +45 86 13 90 20 Klostergade 28 Fax: +45 86 20 29 75 DK-8000 Aarhus C http://www.cryptomathic.com/ Denmark From owner-ietf-pkix Thu Jan 20 01:42:59 2000 Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA10471 for ; Thu, 20 Jan 2000 01:42:56 -0800 (PST) Received: from HYDRA ([195.198.186.79]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id KAA28097; Thu, 20 Jan 2000 10:45:45 +0100 Received: by HYDRA with Microsoft Mail id <01BF6332.34EFD230@HYDRA>; Thu, 20 Jan 2000 10:36:27 +0100 Message-ID: <01BF6332.34EFD230@HYDRA> From: Anders Rundgren To: "'ietf-pkix@imc.org'" Cc: "'SEIS-List'" , "'Henrik Bergman'" Subject: US excport rules after Jan-12,2000 Date: Thu, 20 Jan 2000 10:36:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, A few months I put questions regarding this in this list and apparently the september-1999 deal was impossible to "swallow" or "interpret" and therefore the US department of commerce have made a new try. http://204.193.246.62/public.nsf/docs/60D6B47456BB389F852568640078B6C0 It looks much better but does it allow all users (from all but the seven "bad" countries) 1. To download US versions of Internet Explorer or Navigator 2. To buy (over the net) US-issued e-mail certificates with 1024-bit keys 3. To buy US-produced smart cards (using ordinary mail order) containing strong crypto 4. To buy US versions of Windows, Solaris etc. with the same ease as you today buy export versions If the answer is yes I would say that this would be the biggest boon to PKI since it was invented!!! Anders A strange piece of the new deal is that government users are discriminated Why? From owner-ietf-pkix Thu Jan 20 02:39:44 2000 Received: from mail.isel.pt (aquario.isel.pt [193.137.220.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA12669 for ; Thu, 20 Jan 2000 02:39:42 -0800 (PST) Received: from minho (dyn-96.cc.net.isel.pt [192.168.4.96]) by mail.isel.pt (8.9.3/8.9.3/PRNCAJ) with SMTP id KAA26893 for ; Thu, 20 Jan 2000 10:40:21 GMT Message-ID: <01ac01bf6333$18c419d0$6004a8c0@nb.isel.pt> From: =?iso-8859-1?Q?Pedro_F=E9lix?= To: Subject: Binding between keys and schemes? Date: Thu, 20 Jan 2000 10:42:48 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 1) As defined by PKCS#1 v2.0 an RSA key can be used in two diferent encryption schemes: rsaEncryption (PKCS#1 v1.5 scheme) and the new OAEP based scheme (id-RSAES-OAEP OID). Is a PKIX certificate with rsaEncryption OID (on the subjectPublicKeyInfo) binded only to the first scheme? 2) Probably in the future there will be various signature and encryption schemes using the same type of key. As an example the P1363 draft 11 defines two signature schemes IFSP-RSA1 and IFSP-RSA2 used with an Encoding method (EMSA2) that can be updated in the future. They all use the same type of IF (RSA) key. How will an certificate manage this 1<->N relation between keys and schemes? There will be a different certificate for each scheme or the same key certificate will be used with different schemes? If the second applies, how will the schemes capabilities of a certificate subject be identified? I gave a quick browse on the archives and didn't found any reference to this subject? I apologise if this question is off-topic or doesn't make sense in this context! I also thanks (in advance) any replies. Pedro Felix Centro de Calculo do Instituto Superior de Engenharia de Lisboa. From owner-ietf-pkix Thu Jan 20 03:58:09 2000 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA16735 for ; Thu, 20 Jan 2000 03:58:09 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25176; Thu, 20 Jan 2000 06:59:22 -0500 (EST) Message-Id: <200001201159.GAA25176@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-technr-00.txt Date: Thu, 20 Jan 2000 06:59:22 -0500 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Technical Requirements for a non-Repudiation Service Author(s) : T. Gindin Filename : draft-ietf-pkix-technr-00.txt Pages : 7 Date : 19-Jan-00 This document describes those features of a service which processes signed documents which must be present in order for that service to constitute a 'technical non-repudiation' service. A technical non-repudiation service must permit an independent verifier to determine whether a given signature was applied to a given data object by the private key associated with a given valid certificate, at a time later than the signature. The features of a technical non- repudiation service are expected to be necessary for a full non- repudiation service, although they may not be sufficient. This document is intended to clarify the definition of the 'non-repudiation' service in RFC 2459. It should thus serve as a guide to when the nonRepudiation bit of the keyUsage extension should be set and to when a Certificate Authority is required to archive CRL's. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-technr-00.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-technr-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-technr-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000119144609.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-technr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-technr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000119144609.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Thu Jan 20 04:17:36 2000 Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA17397 for ; Thu, 20 Jan 2000 04:17:35 -0800 (PST) Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Thu, 20 Jan 00 12:28:04 -0000 X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2 Received: from piers2k (host212-140-125-183.host.btclick.com [212.140.125.183]) by bjex1.bj.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Z3MS55VF; Thu, 20 Jan 2000 12:16:36 -0000 Reply-to: piers@bj.co.uk From: "Piers Chivers" To: ietf-pkix@imc.org Subject: SMIME conformance specs Date: Thu, 20 Jan 2000 12:19:07 -0000 Message-ID: <000601bf6340$8d7476a0$1a01a8c0@piers2k> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-WSS-ID: 149820DE1401-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi, Are there any publicly available docs that describe the conformance requirements for a PKIX/SMIME compliant messaging client? I know that the SMIME RFCs detail the protocol requirements for a conforming app but I was thinking at the level of "A conforming client must indicate to the user when a message fails a signature validation" or "A user must be able to encrypt and/or sign an outgoing message". Thanks, Piers From owner-ietf-pkix Thu Jan 20 05:47:55 2000 Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA20446 for ; Thu, 20 Jan 2000 05:47:48 -0800 (PST) From: yosimass@il.ibm.com Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id OAA17078; Thu, 20 Jan 2000 14:47:08 +0100 Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.8m2/NCO v2.06) with SMTP id OAA40188; Thu, 20 Jan 2000 14:47:02 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C125686C.004B4561 ; Thu, 20 Jan 2000 14:42:09 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ietf-pkix@imc.org, spki@c2.net, cryptography@c2.net, trustmgt@EAST.ISI.EDU cc: amir.herzberg@il.ibm.com Message-ID: Date: Thu, 20 Jan 2000 15:45:14 +0200 Subject: Trust Establishment on AlphaWorks Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi, TrustEstablishment (available now on AlphaWorks at http://www.alphaworks.ibm.com) is a set of Java packages that can be used to solve the Trust Management problem. Below is a short description of the Trust problem and how TE can be used to solve it. More info can be found at http://www.hrl.il.ibm.com/TrustEstablishment. Any feedback is most appreciated. Regards, Yosi Mass Trust Establishment Project Manager, IBM Haifa Research Lab, Tel Aviv Site E-mail: YosiMass@il.ibm.com Tel +972-3-6978624, Fax +972-3-6914736 A new approach to the deployment of public key infrastructure is presented, based on a separation between the issuing of certificates and the usage of certificates. Certificates are signed assertions by the issuer about the subject of the certificate (holder of corresponding private key), not necessarily identifying the subject. Typical use of certificate is for access control decisions, to determine whether the subject is allowed to perform a certain action (on some resource); this decision is based on the policy of the owner of the resource. Issuers do not need to be known to resource owners in advance; it is sufficient that they, in turn, will provide sufficient certificates to be considered a trusted authority according to the owner's policy. This allows bottom-up, `grassroots` build-up of trusted issuers. Our approach extends, rather than replaces, existing role-based access control mechanisms, by providing automated role assignment. Existing access control mechanisms use the identities to map the subject to a given role, based on a static table. Our system maps the subject of the certificates to a role, based on the subject's certificates, on a given role-assignment policy set by the owner of the resource, and on the roles of the issuers of the certificates. The role is then fed as input to the existing role-based access control mechanism. This provides a simple, modular architecture and role-assignment policies. We describe an implementation called "Trust Establishment (TE)" , which can be used to provide a complete PKI-enabled web server (or other e-commerce server), or to extend access control systems. A central element in our implementation is a simple yet powerful Certificate-based Role-Assignment Policy Language specified using XML. We believe that the policy language is expressive enough to allow complex policies, including e.g. non monotone (negative) certificates while being simple enough to allow automated policy checking and processing. Processing of the policy is essential, to ensure reasonable efficiency (e.g. in handling a new certificate or revocation), to check policy e.g. for conflicts, to collect missing certificates, to compose policies, and to allow subjects to select which certificates to present. Our system includes an intelligent certificate collector that automatically collects missing certificates from peer servers, allowing the use of standard browsers (that pass only one certificate to the server). Trust Establishment Software ======================== The TE module is written in Java and therefore includes the cross platform advantages available to Java applications. The module also includes an API toolkit that programmers can use to extend the access control abilities of existing applications or web servers. All certificates and signatures are implemented through the Zurich Crypto Framework package from ZRL. The TE software uses a reduced version that does not include encryption and therefore has no problems with export regulations. Certificate Format =============== The Trust Establishment module uses the X509 V3 certificate format . TE is designed to support other certificate types; this type was chosen since it is currently the most commonly used. The certificate subject and issuer are identified by X500 names, where X500 defines a global directory for all names and DN is the distinguished name. The TE does not use these X500 names, but keeps a unique identifier for a subject/issuer which is derived from their public key and is kept in the standard extensions : issuer/subject altName. The TE module decides on the role for the key so it is not interested in the identity of the user; hence, the X500 names are not really important. TE uses them because they are obligatory for the X509 format. Related Documents ================= For further information on Trust Establishment, see the following: Trust Establishment home page at http://www.hrl.il.ibm.com/TrustEstablishment White paper accepted to the 2000 IEEE Symposium on Security and Privacy available at http://www.hrl.il.ibm.com/TrustEstablishment/paper.asp From owner-ietf-pkix Thu Jan 20 09:26:26 2000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA24216 for ; Thu, 20 Jan 2000 09:26:25 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 20 Jan 2000 10:27:10 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 20 Jan 2000 10:25:57 -0700 From: "Tolga Acar" To: , Subject: Re: Binding between keys and schemes? Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_ECB55E7E.C8A989EC" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_ECB55E7E.C8A989EC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There are two relevant OIDs a. The OID encoded in the subjectPublicKeyInfo, which merely describeds = how to interpret the public key in it, b. the signature OID, that describes which algorithm is used to sign the = whole certificate These two OIDs don't have anything to do with each other - at least not = necessarily. In theory, you can put a custom encoded XYZ algorithm public key, and sign = it with ABC algorithm with "a" key. Following this, one can use a PKCS#1 encoded public key with more than one = algorithm, with each algorithm having its own OID - not the key; and i = don't see a problem here. The signature algorithm describes the math and the encoding of the output = from the math, not the key. Some of the signature algorithms may require = the input key in a certain format - but this relation doesn't have to be = bijective. Thus, 1) a PKCS#1 version x.y encoded public key can be used in N number of = different algorithms. And, this does not conflict with the key formatting, = i.e., PKCS#1 2) A certificate's signature algorithm can be anything (see RFC ABCD for = restrictions), and does not depend on the key format.=20 - Tolga >>> Pedro F=E9lix 1/20/00 3:42:48 >>> 1) As defined by PKCS#1 v2.0 an RSA key can be used in two diferent encryption schemes: rsaEncryption (PKCS#1 v1.5 scheme) and the new OAEP based scheme (id-RSAES-OAEP OID). Is a PKIX certificate with rsaEncryption OID (on the subjectPublicKeyInfo) binded only to the first scheme? 2) Probably in the future there will be various signature and encryption schemes using the same type of key. As an example the P1363 draft 11 = defines two signature schemes IFSP-RSA1 and IFSP-RSA2 used with an Encoding method (EMSA2) that can be updated in the future. They all use the same type of = IF (RSA) key. How will an certificate manage this 1<->N relation between keys and = schemes? There will be a different certificate for each scheme or the same key certificate will be used with different schemes? If the second applies, how will the schemes capabilities of a certificate subject be identified? I gave a quick browse on the archives and didn't found any reference to = this subject? I apologise if this question is off-topic or doesn't make sense in this context! I also thanks (in advance) any replies. Pedro Felix Centro de Calculo do Instituto Superior de Engenharia de Lisboa. --=_ECB55E7E.C8A989EC Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There are two relevant OIDs
a. The OID encoded in the subjectPublicKeyInfo, which merely describeds how to interpret the public key in it,
b. the signature OID, that describes which algorithm is used to sign the whole certificate
 
These two OIDs don't have anything to do with each other - at least not necessarily.
In theory, you can put a custom encoded XYZ algorithm public key, and sign it with ABC algorithm with "a" key.
Following this, one can use a PKCS#1 encoded public key with more than one algorithm, with each algorithm having its own OID - not the key; and i don't see a problem here.
The signature algorithm describes the math and the encoding of the output from the math, not the key. Some of the signature algorithms may require the input key in a certain format - but this relation doesn't have to be bijective.
 
Thus,
 
1) a PKCS#1 version x.y encoded public key can be used in N number of different algorithms. And, this does not conflict with the key formatting, i.e., PKCS#1
2) A certificate's signature algorithm can be anything (see RFC ABCD for restrictions), and does not depend on the key format.
 
- Tolga


>>> Pedro Félix <pfelix@isel.pt> 1/20/00 3:42:48 >>>
1) As defined by PKCS#1 v2.0 an RSA key can be used in two diferent
encryption schemes:
rsaEncryption (PKCS#1 v1.5 scheme) and the new OAEP based scheme
(id-RSAES-OAEP OID).
Is a PKIX certificate with rsaEncryption OID (on the subjectPublicKeyInfo)
binded only to the first scheme?

2) Probably in the future there will be various signature and encryption
schemes using the same type of key. As an example the P1363 draft 11 defines
two signature schemes IFSP-RSA1 and IFSP-RSA2 used with an Encoding method
(EMSA2) that can be updated in the future. They all use the same type of IF
(RSA) key.
How will an certificate manage this 1<->N relation between keys and schemes?
There will be a different certificate for each scheme or the same key
certificate will be used with different schemes?
If the second applies, how will the schemes capabilities of a certificate
subject be identified?

I gave a quick browse on the archives and didn't found any reference to this
subject?

I apologise if this question is off-topic or doesn't make sense in this
context!
I also thanks (in advance) any replies.

Pedro Felix
Centro de Calculo do Instituto Superior de Engenharia de Lisboa.


--=_ECB55E7E.C8A989EC-- From owner-ietf-pkix Thu Jan 20 14:05:13 2000 Received: from arista.iris.com (arista.iris.com [198.112.211.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28529 for ; Thu, 20 Jan 2000 14:05:12 -0800 (PST) From: Mary_Ellen_Zurko@iris.com Subject: NSPW 2000 Call For Papers To: ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.0.2 November 4, 1999 Message-ID: Date: Thu, 20 Jan 2000 17:11:14 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.2b |December 16, 1999) at 01/20/2000 05:06:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii ======================================================================== Call For Papers New Security Paradigms Workshop 2000 An ACM/SIGSAC sponsored workshop 19 - 21 September 2000 Ballycotton, County Cork, Ireland http://www.nspw.org/ ======================================================================== For eight years, the New Security Paradigms Workshop has provided a productive and highly interactive forum in which innovative new approaches (and some radical older approaches) to computer security have been offered, explored, refined, and published. The workshop offers a constructive environment where experienced researchers and practitioners work alongside newer participants in the field. The result is a unique opportunity to exchange ideas. New Security Paradigms Workshop (NSPW) 2000 will take place September 19 - 21, 2000 at the Bayview Hotel, Ballycotton, a 45 minute drive from the Cork airport. In order to preserve the small, intimate nature of the workshop, participation is limited to authors of accepted papers and conference organizers. Because these are new paradigms, we cannot predict what subjects will be covered. Any paper that presents a significant shift in thinking about difficult security issues or builds on a previous shift will be welcomed. The New Security Paradigms Workshop is highly interactive in nature. Authors are encouraged to present ideas that might be considered risky in some other forum. All participants are charged with providing feedback in a constructive manner. The resulting brainstorming environment has proven to be an excellent medium for furthering the development of these ideas. The proceedings, published after the workshop, have consistently benefited from the inclusion of workshop feedback. To participate, please submit your paper, justification, and attendance statement, preferably via e-mail, to both Program Chairs -- Cristina Serban (cserban@att.com) and Brenda Timmerman (btimmer@ecs.csun.edu) -- by Friday, March 31, 2000 (hardcopy submissions must be received by Friday, March 24, 2000). Further details on the required format of submissions follow. 1 - Your Paper You should submit either a research paper, a 5 - 10 page position paper, or a discussion topic proposal. Submissions of any type must not have been published elsewhere. Discussion topic proposals should include an in-depth description of the topic to be discussed, a convincing argument that the topic will lead to a lively discussion, and any other supporting materials. Softcopy submissions should be in Postscript or ASCII format. Papers may be submitted in hardcopy. To submit hardcopy, please mail 5 (five) copies to Program co-chair Cristina Serban. Please allow adequate time for delivery. 2 - Justification You should describe, in one page or less, why your paper is appropriate for the New Security Paradigms Workshop. A good justification will describe the new paradigm being proposed, explain how it is a departure from existing theory or practice, and identify those aspects of the status quo it challenges or rejects. 3 - Attendance Statement You should state how many authors wish to attend the workshop. Accepted papers require the attendance of at least one author. In order to ensure that all papers receive equally strong feedback, all attendees are expected to stay for the entire duration of the workshop. The program committee will referee the papers and notify the authors of acceptance status by June 9, 2000. We expect to be able to offer a limited number of scholarships. More information will be provided on our web site (http://www.nspw.org/) as it becomes available. Workshop Co-Chairs Mary Ellen Zurko Steven J. Greenwald Iris Associates 2521 NE 135th Street 230 Nashua Rd. North Miami, FL 33181 USA Groton, MA 01450 USA e-mail: sjg6@gate.net e-mail: mzurko@iris.com voice: +1 (305) 944-7842 voice: +1 (978) 392-6018 fax +1 (305) 489-8129 fax: +1 (978) 692-7365 Program Committee Co-Chairs Cristina Serban Brenda Timmerman AT&T Labs California State University 307 Middletown-Lincroft Rd. 18111 Nordhoff St. Lincroft, NJ 07738 USA Northridge, CA 91330-8281 USA e-mail: cserban@att.com e-mail: btimmer@ecs.csun.edu voice: +1 (732) 576-3279 voice: +1 (818) 677-7341 fax: +1 (732) 576-6406 fax: +1 (818) 677-2140 Program Committee Bob Blakley, Tivoli Heather Hinton, Tivoli Erland Jonsson, Chalmers University of Technology Clifford Kahn, EMC Corporation Darrell Kienzle, The MITRE Corporation Jun Li, UCLA Catherine Meadows, Naval Research Laboratory Susan Pancho, University of Cambridge Dean Povey, DSTC Thomas Riechmann, Siemens Marvin Schaefer, ARCA Systems John Michael Williams Local Arrangements Simon Foley (University College, Cork, Ireland) +353 21 902929 Scholarships Hilary Hosmer (Data Security Inc.) +1 (781) 275-8231 John McHugh (SEI/CERT) +1 (412) 268-7737 Publications Marvin Schaefer (ARCA Systems) +1 (410) 309-1780 Publicity Crispin Cowan (WireX Communications, Inc.) +1 (503) 241-6575 ACM-SIGSAC Chair Ravi Sandhu (George Mason University) +1 (703) 993-1659 Steering Committee Bob Blakley, Steven J. Greenwald, Hilary Hosmer, Darrell Kienzle, Catherine Meadows, Cristina Serban, Brenda Timmerman, Mary Ellen Zurko From owner-ietf-pkix Fri Jan 21 02:22:33 2000 Received: from mail.isel.pt (aquario.isel.pt [193.137.220.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA26971 for ; Fri, 21 Jan 2000 02:22:31 -0800 (PST) Received: from minho (dyn-96.cc.net.isel.pt [192.168.4.96]) by mail.isel.pt (8.9.3/8.9.3/PRNCAJ) with SMTP id KAA19201; Fri, 21 Jan 2000 10:22:56 GMT Message-ID: <027601bf63f9$e3396820$6004a8c0@nb.isel.pt> From: =?iso-8859-1?Q?Pedro_F=E9lix?= To: "Tolga Acar" , References: Subject: Re: Binding between keys and schemes? Date: Fri, 21 Jan 2000 10:25:35 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0273_01BF63F9.DAEEE8C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_0273_01BF63F9.DAEEE8C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable First of all, thanks for your reply. I apologise for not making my question clear. When I asked about the binding between a key and a scheme, I was not = refering to the scheme used to sign the certificate. Let's supose that ALICE, running protocol P, want's to send a PKCS#7 = Envelope to BOB, and has a X.509 certificate of BOB's public key (with = rsaEncryption OID on the subjectPublicKeyInfo field). The certificate = was signed with scheme X (eg. DSA) and was correctly verified by ALICE = using that scheme. Which ENCRYPTION scheme should ALICE use to build the Envelope? ( = RSAES-PKCS1-v1_5, RSAES-OAEP , ...) Probably ALICE would want to use the new RSAES-OAEP, but does BOB = support it? If I understood you correctly, this binding between the key and the = scheme IS NOT made by a X.509 certificate (except when the retation is = 1-1) and has to be built by other means (possibly defined by the = protocol P). I'm I right? I assume that the source of my initial confusion comes from the fact = that, in PKCS#1, the same OID (rsaEncryption) is used to identify both a = key and a encryption scheme. Once again, I thank you for your reply Best regards - Pedro Felix ------=_NextPart_000_0273_01BF63F9.DAEEE8C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
First of all, thanks for your = reply.
 
I apologise for not making my question=20 clear.
When I asked about the binding between a key and a scheme, I was = not=20 refering to the scheme used to sign the certificate.
 
Let's supose that  ALICE, running protocol P, want's to send a = PKCS#7=20 Envelope to BOB, and has a X.509 certificate of BOB's public key=20 (with rsaEncryption OID on the subjectPublicKeyInfo field). The = certificate=20 was signed with scheme X (eg. DSA) and was correctly verified by = ALICE=20 using that scheme.
Which ENCRYPTION scheme should ALICE use to build the = Envelope? (=20 RSAES-PKCS1-v1_5, RSAES-OAEP , ...)
Probably ALICE would want to use the new RSAES-OAEP, but does BOB = support=20 it?
If I understood you correctly, this binding between the key and the = scheme IS NOT made by a X.509 certificate (except when the retation = is 1-1)=20 and has to be built by other means (possibly defined by the protocol P). = I'm I=20 right?
 
I assume that the source of my initial confusion comes from the = fact that,=20 in PKCS#1, the same OID (rsaEncryption) is used to identify both a = key and=20 a encryption scheme.
 
 
Once again, I thank you for your reply
 
Best regards
 
- Pedro Felix
------=_NextPart_000_0273_01BF63F9.DAEEE8C0-- From owner-ietf-pkix Fri Jan 21 05:58:09 2000 Received: from 5sigexch7.hq.5sigcmd.army.mil (5sigexch7.hq.5sigcmd.army.mil [147.40.43.67]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA04447 for ; Fri, 21 Jan 2000 05:58:08 -0800 (PST) Received: by 5sigexch7.hq.5sigcmd.army.mil with Internet Mail Service (5.5.2650.10) id ; Fri, 21 Jan 2000 14:58:32 +0100 Message-ID: From: "Stringfield, Robert Mr." To: "'ietf-pkix@imc.org'" Subject: Use of DOD PKI Cert with the X.400 Address Date: Fri, 21 Jan 2000 14:58:31 +0100 X-Mailer: Internet Mail Service (5.5.2650.10) > I am the PM for the DOD PKI MGS Pilot > (http://www.5sigcmd.army.mil/pki/pki.htm) which is based in Germany. If > able to use either the X.400 or SMTP with the DOD PKI Cert it would be of > great benefit to the WarFighter because of restrictions between home and > base sites. > > Also I am looking into the tying of the cert to multiple email addresses > which would be another 'huge' benefit. Any advice would be extremely > helpful or pointers to the correct information source. Thanks.. > --bob > > Robert L. Stringfield > DMS/PKI 5th Signal Command > DSN: 380-5857 FAX: 380-5858 > mailto:stringfr@hq.5sigcmd.army.mil > http://www.5sigcmd.army.mil/DMS/dms.htm > http://www.5sigcmd.army.mil/pki/pki.htm > http://144.170.207.251/archives/index.html > Truth: We own the Night!!! - DeathStar Warriors > > From owner-ietf-pkix Sun Jan 23 14:10:16 2000 Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA09617 for ; Sun, 23 Jan 2000 14:10:15 -0800 (PST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 23 Jan 2000 14:11:28 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Sun, 23 Jan 2000 14:11:28 -0800 Message-ID: From: Trevor Freeman To: "Pkix List (E-mail)" Subject: Some Issues and observations with the son of 2459 Date: Sun, 23 Jan 2000 14:11:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF65EE.CBDFC588" 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_01BF65EE.CBDFC588 Content-Type: text/plain; charset="iso-8859-1" RFC 2459 chains vs. son of RFC 2459 chains We will have two sets of semantics under which certificates can be issued - RFC 2459, and son of RFC 2459, and two sets of rules for processing those chains. In moving forward, two objectives which we must meet are: * When a new son of 2459 client is deployed into an existing 2459 PKI it must not break with the deployed population of certificates * There must be no requirement to reissue certificates in order to deploy the new clients. At the root of the problem is the clarification of what a new son of 2459 client must do if it encounters a chain which does not comply with the more restrictive son of 2459 policy rules. If that chain was issued under the new rules, it is indeed a bad chain and verification should fail. If it was build under the 2459 rules, it is a "legacy chain" which is still valid. There must be some mechanism to indicate if a certificate was issued under son of 2459 rules. A possible solution to this would be to assign a "policy semantics version" OID which must be included in every non self signed certificate issued under the new rules in the policy extension. A single 2459 certificate in a chain potentially downgrades the chain to 2459 rules. We can continue to process policy as currently defined, but if we end up with an empty set, and one of the certificates in the chain does not contain the policy version OID, we return that verification was successful with an empty policy set. There are other possibilities for how to distinguish the certificates such as assigning a new OID to the policy extension and include both extensions in issued certificates, but at this stage, they seem more expensive so I would like to see a very strong case in there favour before I would consider them. Name Constraint Processing The current draft does not deal with the case where a certificate contains a name