From chandras@loc201.tandem.com Thu Jan 2 07:01:29 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id HAA17562; Thu, 2 Jan 1997 07:01:29 -0800 Received: from jucar.ait.uvigo.es by suntan.tandem.com (8.6.12/suntan5.961027) for id HAA17550; Thu, 2 Jan 1997 07:01:25 -0800 Received: by zamans.meiga (5.x/SMI-SVR4) id AA19780; Thu, 2 Jan 1997 16:00:20 +0100 Date: Thu, 2 Jan 1997 16:00:20 +0100 From: ffdez@ait.uvigo.es (Francisco Fernandez Massaguer) Message-Id: <9701021500.AA19780@zamans.meiga> To: ietf-pkix@tandem.com Subject: Standard documents availability. I would wish to revise the following documents: * ISO/IEC DIS 13888-3 (JTC 1 / SC 27) Information technology -- Security techniques -- Non-repudiation -- Part 3: Using asymmetric techniques * X9.57 -- Certificate Management The first is at draft status and is not yet available from ISO; it is a different (?) document than ISO 10181-4 also on non-repudiation. The second is not yet available from ANSI. Can anyone in this list tell me how to get these documents ?. Thanks ------------------------------------------------------------------------------- Francisco Fernandez Massaguer E-mail: ffernandez@ait.uvigo.es ETSI Telecomunicacion Vigo Tel: +34-86-812181 Vigo, SPAIN Fax: +34-86-812116 ------------------------------------------------------------------------------- From chandras@loc201.tandem.com Thu Jan 2 07:09:32 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id HAA18112; Thu, 2 Jan 1997 07:09:32 -0800 Received: from netcomsv.netcom.com by suntan.tandem.com (8.6.12/suntan5.961027) for id HAA18107; Thu, 2 Jan 1997 07:09:30 -0800 Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id HAA24547; Thu, 2 Jan 1997 07:08:40 -0800 Received: from cc:Mail by spysouth.spyrus.com id AA852217436 Thu, 02 Jan 97 07:03:56 Date: Thu, 02 Jan 97 07:03:56 From: "Housley, Russ" Encoding: 1728 Text Message-Id: <9700028522.AA852217436@spysouth.spyrus.com> To: gangolli@netscape.com CC: ietf-pkix@tandem.com Subject: Re: validity dates in latest draft-ietf-pkix-ipki-part1-03 Anil: The CHOICE proposal has been submitted to the ISO/ITU-T folks working on Directory standards. We see no reason why the change to the syntax will not be accepted. If it is not accepted, a paragraph pointing out the difference will be added to the profile. At the PKIX Working Group meeting in San Jose, several people raised concerns about the "sliding window" approach. It was agreed to change this portion of the profile. It was agreed that dates with years before 2051 will be encoded as UTCTime, and dates with years after 2050 will be encoded as GeneralizedTime. Thus, there will be only one way to encode any particular date. Russ ______________________________ Reply Separator _________________________________ Subject: validity dates in latest draft-ietf-pkix-ipki-part1-03.txt Author: gangolli@netscape.com Date: 12/25/96 3:12 AM The document presents the proposed validity date CHOICE UTCTime/GeneralizedTime as if it were part of the X.509 v3 definition. Did this in fact make it into the latest X.509 v3 Amendments? If this is in fact not in the X.509 v3 spec, the document needs to call this out as a IETF/IPKI difference. In addition, the following should be noted: - Between 2005 and 2015 one cannot obtain a DER encoding by knowing the (abstract) time values alone. (Two choices are possible.) This breaks DER principles (though most current usage does not rely on this stringent value-implies-encoding property). You need to have a single changeover date if you want to preserve this property. - The section on GeneralizedTime should be numbered 4.1.2.5.2. (There are two sections currently numbered 4.1.2.6) -anil. From chandras@loc201.tandem.com Thu Jan 2 07:34:41 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id HAA19854; Thu, 2 Jan 1997 07:34:41 -0800 Received: from cs20.cs.auckland.ac.nz by suntan.tandem.com (8.6.12/suntan5.961027) for id HAA19849; Thu, 2 Jan 1997 07:34:36 -0800 From: Received: from cs26.cs.auckland.ac.nz by cs20.cs.auckland.ac.nz (8.8.3/4.7) id EAA05910; Fri, 3 Jan 1997 04:34:18 +1300 (NZDT) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <85221926606694>; Fri, 3 Jan 1997 04:34:26 (NZDT) To: ietf-pkix@tandem.com Subject: X.509 guide/notes available 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: Fri, 3 Jan 1997 04:34:26 (NZDT) Message-ID: <85221926606694@cs26.cs.auckland.ac.nz> I've now made the X.509 notes I posted here some time ago available online at http://www.cs.auckland.ac.nz/~pgut001/x509guide.txt. They carry the rather pretentious title "X.509 Style Guide" because they started out as an attempt to clarify some rather unclear X.509 implementation issues and provide hints on potential problem spots. Here's the introduction: >There seems to be a lot of confusion out there about how to implement and work >with X.509 certificates, mainly due to either ASN.1 encoding issues, or becaus >the general non-presence of X.500 means people have to take guesses at what >some of the X.500-related fields are supposed to look like. For this reason I >decided to put together some guidelines which people could follow when creatin >software to work with X.509 certificates, CRL's, and other ASN.1-encoded data >types. The document is intended to be a collection of the experiences of >developers and implementors to help developers new to the area create >interoperable implementations. Before people point this out, I've just noticed that the comments about Y2K problems are out of date, I'll change that section of the text within the next few days. Peter. From chandras@loc201.tandem.com Fri Jan 3 04:34:17 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id EAA00821; Fri, 3 Jan 1997 04:34:17 -0800 Received: from jucar.ait.uvigo.es by suntan.tandem.com (8.6.12/suntan5.961027) for id EAA00801; Fri, 3 Jan 1997 04:34:06 -0800 Received: by zamans.meiga (5.x/SMI-SVR4) id AA27372; Fri, 3 Jan 1997 13:33:51 +0100 Date: Fri, 3 Jan 1997 13:33:51 +0100 From: ffdez@ait.uvigo.es (Francisco Fernandez Massaguer) Message-Id: <9701031233.AA27372@zamans.meiga> To: ietf-pkix@tandem.com Subject: Re: Re: standard docs. availability > > > > > I would wish to revise the following documents: > > > > * ISO/IEC DIS 13888-3 (JTC 1 / SC 27) > > Information technology -- Security techniques -- > > Non-repudiation > > -- Part 3: Using asymmetric techniques > > > > * X9.57 -- Certificate Management > > > > The first is at draft status and is not yet available from ISO; it is > > a different (?) document than ISO 10181-4 also on non-repudiation. > > The second is not yet available from ANSI. > > > > Can anyone in this list tell me how to get these documents ?. > > > > Try www.iso.ch. I tried to connect this evening but was unsuccesful. > I suspect that you will have to buy the ISO/IEC doc. Thanks Luc for your answer, I had already contacted ISO organization. His response was that ISO/IEC 13888-3 wasn't yet available, because it is in CD (Committee Draft) status. Regards From chandras@loc201.tandem.com Fri Jan 3 07:34:50 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id HAA10656; Fri, 3 Jan 1997 07:34:50 -0800 Received: from jucar.ait.uvigo.es by suntan.tandem.com (8.6.12/suntan5.961027) for id HAA10642; Fri, 3 Jan 1997 07:34:46 -0800 Received: by zamans.meiga (5.x/SMI-SVR4) id AA28334; Fri, 3 Jan 1997 16:34:44 +0100 Date: Fri, 3 Jan 1997 16:34:44 +0100 From: ffdez@ait.uvigo.es (Francisco Fernandez Massaguer) Message-Id: <9701031534.AA28334@zamans.meiga> To: ietf-pkix@tandem.com Subject: On-line revocation checking In the Part I draft of PKIX (draft-ietf-pkix-ipki-part1-03.txt) document, (end of 3.3 section) it is considered the possibility of (future ?) on-line recovation checking approaches. I have revised draft-ietf-pkix-ipki-part1-03.txt (Part I), draft-ietf-pkix-polfmwk-00.txt (Policy), and draft-ietf-pkix-ipki3cmd-02.txt (Part III) and apart from the mentioned 3.3 section in Part I and a little note in section 6.6.1 in the Policy document, I haven't found anything more about this theme. Is or will be this point considered in greater detail on some other of the various draft parts or versions of PKIX ?. Thanks. Francisco Fernandez. ------------------------------------------------------------------------ Francisco Fernandez Massaguer E-mail: ffernandez@ait.uvigo.es ETSI Telecomunicacion Vigo Tel: +34-86-812181 Vigo, SPAIN Fax: +34-86-812116 ------------------------------------------------------------------------ From chandras@loc201.tandem.com Fri Jan 3 08:38:41 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id IAA16509; Fri, 3 Jan 1997 08:38:41 -0800 Received: from jucar.ait.uvigo.es by suntan.tandem.com (8.6.12/suntan5.961027) for id IAA16500; Fri, 3 Jan 1997 08:38:35 -0800 Received: by zamans.meiga (5.x/SMI-SVR4) id AA28641; Fri, 3 Jan 1997 17:38:27 +0100 Date: Fri, 3 Jan 1997 17:38:27 +0100 From: ffdez@ait.uvigo.es (Francisco Fernandez Massaguer) Message-Id: <9701031638.AA28641@zamans.meiga> To: ietf-pkix@tandem.com Subject: On-line revocation checking In the Part I draft of PKIX (draft-ietf-pkix-ipki-part1-03.txt) document, (end of 3.3 section) it is considered the possibility of (future ?) on-line recovation checking approaches. I have reviewed: draft-ietf-pkix-ipki-part1-03.txt (Part I), draft-ietf-pkix-polfmwk-00.txt (Policy), and draft-ietf-pkix-ipki3cmd-02.txt (Part III) and apart from the mentioned 3.3 section in Part I and a little note in section 6.6.1 in the Policy document, I haven't found anything more about this theme. Is or will be this point considered in greater detail on some other of the various draft parts or versions of PKIX ?. Thanks. Francisco Fernandez. ------------------------------------------------------------------------ Francisco Fernandez Massaguer E-mail: ffernandez@ait.uvigo.es ETSI Telecomunicacion Vigo Tel: +34-86-812181 Vigo, SPAIN Fax: +34-86-812116 ------------------------------------------------------------------------ From chandras@loc201.tandem.com Fri Jan 3 11:43:10 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id LAA06881; Fri, 3 Jan 1997 11:43:10 -0800 Received: from gatekeeper.bankamerica.com by suntan.tandem.com (8.6.12/suntan5.961027) for id LAA06873; Fri, 3 Jan 1997 11:43:08 -0800 Received: from iwww.bankamerica.com (iwww.bankamerica.com [165.32.203.11]) by gatekeeper.bankamerica.com (8.7.5/8.7.3) with SMTP id LAA03398 for ; Fri, 3 Jan 1997 11:45:56 -0800 (PST) Received: by iwww.bankamerica.com; id AA23104; Fri, 3 Jan 1997 11:43:24 -0800 Received: by mailhub.bankamerica.com; Fri, 3 Jan 97 11:34:37 -0800 X400-Received: by /c=US/admd=attmail/; Relayed; 03 Jan 97 11:33:07 -0800 X400-Received: by mta BofA-MTA in /c=US/admd=attmail/; Relayed; 03 Jan 97 11:33:07 -0800 X400-Mts-Identifier: [/c=US/admd=attmail/; 0644032CD5EF300D-attmail] Content-Identifier: 0644032CD5EF300D Content-Return: Allowed X400-Content-Type: P2-1984 ( 2 ) Conversion: Allowed Conversion-With-Loss: Allowed Priority: normal Disclose-Recipients: Prohibited Alternate-Recipient: Allowed X400-Originator: Mack.Hicks@BankAmerica.com X400-Recipients: non-disclosure; Message-Id: <01039711350102607900.bankamerica.com> Date: 03 Jan 97 11:33:07 -0800 From: "G. Mack Hicks, VP Bank of America" To: ietf-pkix@tandem.com Cc: mack.hicks@bankamerica.com, pki@lists.commerce.net Subject: On-line revocation checking --------------------------------- Francisco Wrote on 01/03/97 From: (Francisco Fernandez Massaguer) In the Part I draft of PKIX (draft-ietf-pkix-ipki-part1-03.txt) document, (end of 3.3 section) it is considered the possibility of (future ?) on-line recovation checking approaches. I have reviewed: draft-ietf-pkix-ipki-part1-03.txt (Part I), draft-ietf-pkix-polfmwk-00.txt (Policy), and draft-ietf-pkix-ipki3cmd-02.txt (Part III) and apart from the mentioned 3.3 section in Part I and a little note in section 6.6.1 in the Policy document, I haven't found anything more about this theme. Is or will be this point considered in greater detail on some other of the various draft parts or versions of PKIX ?. Thanks. Francisco Fernandez. ------------------------------------------------------------------------ Francisco Fernandez Massaguer E-mail: ffernandez@ait.uvigo.es ETSI Telecomunicacion Vigo Tel: +34-86-812181 Vigo, SPAIN Fax: +34-86-812116 ------------------------------------------------------------------------ -- end of quote from Francisco ---------- For: IETF-PKI mail list CommerceNet PKI Mail list Allow me to add to Francisco's question regarding on-line revocation. There is a persistent belief that directories (repositories) will deliver to any user upon any request the CRL of designated CA's (designated by the CA as an 'official' repository) signed by the CA. The directory will also deliver all certificates for a particular Distinguished Name (DN) and there will be many for particular users like SSLv3 certs, S/MIME certs, signature certs, encryption certs, and so on. I believe this flies in the face of the reality of on-line transaction cost structures and business models. The CommerceNet PKI task force has several business models that are to be demonstrated. None of these provide for the model that is proposed by IETF. There is a "Relationship Validation Model" that provides for subscribers of a CA to request the repository for that CA for on-line certificate validation. It is the responsibility of the subscriber's repository to contact the repository of the subject certificate to validate the certificate. Repositories may exchange CRLs if the volume of traffic is sufficient. To the point: It seems unreasonable to ask that a subscriber's repository provide unlimited service upon request from anyone with its remuneration provided by the subscriber. Rather, the subscriber should have contractual relationship with its CA and associated repository to provide certificate validation within the community of interest. The futility of the current model (for free) allows for the following situation: a) Subscriber sends a message to every member of the US congress (over 500 copies) b) Each member of congress goes to the repository of the subscriber and asks for 1) all certificates for the DN of the subscriber 2) latest CRL for the CA of the subscriber The repository ends up with over messages for each single message of the subscriber. In addition, the receiver (who is the party that must rely on the message) has no contractual relationship with the CA of the subscriber and no contractual relationship with the repository. Further, the receiver's system (browser, mailer, ...) must process -- Certificate list - finding the right one for this particular message. (Could be two - signature cert and encryption cert.) Then must grind through the CRL for to make sure the cert(s) are still good. This is quite a bit of work to do and proposes that all receiving software is able to determine the validation process for all certs within the community of interest. Both IETF PKIX and NIST MISPC "allow" for on-line validation of certificates. It is my impression of the business community that on-line validation is what is called for by business doing open commerce. Finally, the work with NIST MISPC and IETF PKIX seems to be focused on the functions of the CA strictly. Therefore most of the heavy lifting (replys to messages, etc) is put to the repository and receiving software (emailer, browser, ...). To demonstrate interoperability and functionality, the easiest model is to have the repositories operate "for free" (i.e. without authentication). I agree, this facilitates testing; it does not enable electronic commerce. For an implementation of a "relationship validation model" see the Zion Data Systems implementation for the repository for the state of Utah. (I have no URL reference, maybe someone can provide to the lists.) From chandras@loc201.tandem.com Fri Jan 3 14:12:55 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id OAA21102; Fri, 3 Jan 1997 14:12:55 -0800 Received: from mailgate21 by suntan.tandem.com (8.6.12/suntan5.961027) for id OAA21099; Fri, 3 Jan 1997 14:12:53 -0800 Received: by mailgate21 (SMI-8.6/SMI-SVR4) id OAA22033; Fri, 3 Jan 1997 14:11:53 -0800 Received: from sdn-ts-001mabostp11.dialsprint.net(206.133.32.30) by mailfep4-hme1 via smap (KC5.24) id Q_10.1.1.10/Q_27836_3_32cd840b; Fri Jan 3 14:11:23 1997 Message-Id: <2.2.32.19970104011320.006e5e6c@pop.a001.sprintmail.com> X-Sender: wford@pop.a001.sprintmail.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 03 Jan 1997 17:13:20 -0800 To: ffdez@ait.uvigo.es (Francisco Fernandez Massaguer), ietf-pkix@tandem.com From: Warwick Ford Subject: Re: On-line revocation checking Francisco: I would consider on-line revocation checking an operational protocol, therefore, a topic for coverage in PKIX Part 2. Nobody has yet stepped forward to start development of Part 2. Warwick At 04:34 PM 1/3/97 +0100, Francisco Fernandez Massaguer wrote: > > In the Part I draft of PKIX (draft-ietf-pkix-ipki-part1-03.txt) document, >(end of 3.3 section) it is considered the possibility of (future ?) on-line >recovation checking approaches. > >I have revised > draft-ietf-pkix-ipki-part1-03.txt (Part I), > draft-ietf-pkix-polfmwk-00.txt (Policy), and > draft-ietf-pkix-ipki3cmd-02.txt (Part III) > >and apart from the mentioned 3.3 section in Part I and a little note in >section 6.6.1 in the Policy document, I haven't found anything more about >this theme. > >Is or will be this point considered in greater detail on some other of the >various draft parts or versions of PKIX ?. > >Thanks. >Francisco Fernandez. >------------------------------------------------------------------------ >Francisco Fernandez Massaguer E-mail: ffernandez@ait.uvigo.es >ETSI Telecomunicacion Vigo Tel: +34-86-812181 >Vigo, SPAIN Fax: +34-86-812116 >------------------------------------------------------------------------ > > > > > > > > > --------------------------------------------------------------------- Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 --------------------------------------------------------------------- From chandras@loc201.tandem.com Fri Jan 3 15:15:53 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id PAA28505; Fri, 3 Jan 1997 15:15:53 -0800 Received: from netcomsv.netcom.com by suntan.tandem.com (8.6.12/suntan5.961027) for id PAA28502; Fri, 3 Jan 1997 15:15:52 -0800 Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id PAA13016; Fri, 3 Jan 1997 15:04:35 -0800 Received: from cc:Mail by spysouth.spyrus.com id AA852332528 Fri, 03 Jan 97 15:02:08 Date: Fri, 03 Jan 97 15:02:08 From: "Housley, Russ" Encoding: 1707 Text Message-Id: <9700038523.AA852332528@spysouth.spyrus.com> To: ietf-pkix@tandem.com, ffdez@ait.uvigo.es (Francisco Fernandez Massaguer) Subject: Re: On-line revocation checking The private extension tells a certificate user how to contact the on-line service for revocation checking. After the last IETF meeting, this appears to be the only function that requires the private extension. The other features are provided by the URI form of GeneralName. No one has suggested a protocol for on-line revocation checks. Perhaps the USPS would like to share the one they plan to use? Russ ______________________________ Reply Separator _________________________________ Subject: On-line revocation checking Author: ffdez@ait.uvigo.es (Francisco Fernandez Massaguer) at internet Date: 1/3/97 8:25 AM In the Part I draft of PKIX (draft-ietf-pkix-ipki-part1-03.txt) document, (end of 3.3 section) it is considered the possibility of (future ?) on-line recovation checking approaches. I have revised draft-ietf-pkix-ipki-part1-03.txt (Part I), draft-ietf-pkix-polfmwk-00.txt (Policy), and draft-ietf-pkix-ipki3cmd-02.txt (Part III) and apart from the mentioned 3.3 section in Part I and a little note in section 6.6.1 in the Policy document, I haven't found anything more about this theme. Is or will be this point considered in greater detail on some other of the various draft parts or versions of PKIX ?. Thanks. Francisco Fernandez. ------------------------------------------------------------------------ Francisco Fernandez Massaguer E-mail: ffernandez@ait.uvigo.es ETSI Telecomunicacion Vigo Tel: +34-86-812181 Vigo, SPAIN Fax: +34-86-812116 ------------------------------------------------------------------------ From chandras@loc201.tandem.com Fri Jan 3 16:23:55 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id QAA06388; Fri, 3 Jan 1997 16:23:55 -0800 Received: from gw.quake.net by suntan.tandem.com (8.6.12/suntan5.961027) for id QAA06380; Fri, 3 Jan 1997 16:23:51 -0800 Received: from l140.wespay.org (l140.wespay.org [204.188.21.140]) by gw.quake.net (8.8.2/8.8.2) with SMTP id QAA23924; Fri, 3 Jan 1997 16:23:43 -0800 (PST) Message-ID: <32CDA1DB.4ED8@wespay.org> Date: Fri, 03 Jan 1997 16:18:35 -0800 From: Peter Yeatrakas Organization: WesPay X-Mailer: Mozilla 2.0 (Win16; I) MIME-Version: 1.0 To: "G. Mack Hicks, VP Bank of America" CC: ietf-pkix@tandem.com, pki@lists.Commerce.Net Subject: Re: On-line revocation checking References: <01039711345502606000.bankamerica.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Anyone who wants a copy of the Zions Bank implementation document referenced by Mack Hicks near the end of the posting below, can e-mail their snail-mail address to mailto:pyeatrakas@wespay.org for a hard copy (not available in electronic format). G. Mack Hicks, VP Bank of America wrote: > > +----------------------------------------------------------------------+> This message was addressed to: pki@lists.commerce.net > +----------------------------------------------------------------------+> > --------------------------------- Francisco Wrote on 01/03/97 > From: (Francisco Fernandez Massaguer) > > In the Part I draft of PKIX (draft-ietf-pkix-ipki-part1-03.txt) document, > (end of 3.3 section) it is considered the possibility of (future ?) on-line > recovation checking approaches. > > I have reviewed: > > draft-ietf-pkix-ipki-part1-03.txt (Part I), > draft-ietf-pkix-polfmwk-00.txt (Policy), and > draft-ietf-pkix-ipki3cmd-02.txt (Part III) > > and apart from the mentioned 3.3 section in Part I and a little note in > section 6.6.1 in the Policy document, I haven't found anything more about > this theme. > > Is or will be this point considered in greater detail on some other of the > various draft parts or versions of PKIX ?. > > Thanks. > Francisco Fernandez. > ------------------------------------------------------------------------> Francisco Fernandez Massaguer E-mail: ffernandez@ait.uvigo.es > ETSI Telecomunicacion Vigo Tel: +34-86-812181 > Vigo, SPAIN Fax: +34-86-812116 > ------------------------------------------------------------------------> -- end of quote from Francisco ---------- > > For: IETF-PKI mail list > CommerceNet PKI Mail list > > Allow me to add to Francisco's question regarding on-line revocation. > > There is a persistent belief that directories (repositories) will > deliver to any user upon any request the CRL of designated CA's > (designated by the CA as an 'official' repository) signed by the CA. The > directory will also deliver all certificates for a particular > Distinguished Name (DN) and there will be many for particular users like > SSLv3 certs, S/MIME certs, signature certs, encryption certs, and so on. > > I believe this flies in the face of the reality of on-line transaction > cost structures and business models. > > The CommerceNet PKI task force has several business models that are to > be demonstrated. None of these provide for the model that is proposed by > IETF. There is a "Relationship Validation Model" http://www.commerce.net/work/taskforces/pki/output.html#business> that > provides for subscribers of a CA to request the repository for that CA > for on-line certificate validation. It is the responsibility of the > subscriber's repository to contact the repository of the subject > certificate to validate the certificate. Repositories may exchange CRLs > if the volume of traffic is sufficient. > > To the point: It seems unreasonable to ask that a subscriber's > repository provide unlimited service upon request from anyone with its > remuneration provided by the subscriber. Rather, the subscriber should > have contractual relationship with its CA and associated repository to > provide certificate validation within the community of interest. > > The futility of the current model (for free) allows for the following > situation: > > a) Subscriber sends a message to every member of the US > congress (over 500 copies) > b) Each member of congress goes to the repository of the > subscriber and asks for > 1) all certificates for the DN of the subscriber > 2) latest CRL for the CA of the subscriber > > The repository ends up with over messages for each single message of the > subscriber. In addition, the receiver (who is the party that must rely > on the message) has no contractual relationship with the CA of the > subscriber and no contractual relationship with the repository. > > Further, the receiver's system (browser, mailer, ...) must process -- > Certificate list - finding the right one for this particular message. > (Could be two - signature cert and encryption cert.) Then must grind > through the CRL for to make sure the cert(s) are still good. This is > quite a bit of work to do and proposes that all receiving software is > able to determine the validation process for all certs within the > community of interest. > > Both IETF PKIX and NIST MISPC "allow" for on-line validation of > certificates. It is > my impression of the business community that on-line validation is what > is called for by business doing open commerce. > > Finally, the work with NIST MISPC and IETF PKIX seems to be focused on > the functions of the CA strictly. Therefore most of the heavy lifting > (replys to messages, etc) is put to the repository and receiving > software (emailer, browser, ...). To demonstrate interoperability and > functionality, the easiest model is to have the repositories operate > "for free" (i.e. without authentication). I agree, this facilitates > testing; it does not enable electronic commerce. > > For an implementation of a "relationship validation model" see the Zion > Data Systems implementation for the repository for the state of Utah. (I > have no URL reference, maybe someone can provide to the lists.) > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Anyone who wants a copy of the Zions Bank implementation document can e-mail snail-mail address to mailto:pyeatrakas@wespay.org for a hard copy (not available on the net). ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++> -- Best Regards Pete Yeatrakas WESPAY 1111 Bayhill Dr #150 San Bruno CA 94066-3035 http://www.wespay.com PH: 1-415/871-8762 FAX 1-415/871-9326 From chandras@loc201.tandem.com Fri Jan 3 17:03:39 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id RAA10446; Fri, 3 Jan 1997 17:03:39 -0800 Received: from relay7.UU.NET by suntan.tandem.com (8.6.12/suntan5.961027) for id RAA10438; Fri, 3 Jan 1997 17:03:36 -0800 Received: from labs-n.bbn.com by relay7.UU.NET with SMTP (peer crosschecked as: LABS-N.BBN.COM [128.89.0.100]) id QQbwyf27602; Fri, 3 Jan 1997 16:19:04 -0500 (EST) Received: from BELHAVEN.BBN.COM by LABS-N.BBN.COM id aa17667; 3 Jan 97 16:17 EST Message-Id: <2.2.32.19970103211724.006e42f8@labs-n.bbn.com> X-Sender: solo@labs-n.bbn.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 03 Jan 1997 16:17:24 -0500 To: Francisco Fernandez Massaguer , ietf-pkix@tandem.com From: David Solo Subject: Re: On-line revocation checking At 05:38 PM 1/3/97 +0100, Francisco Fernandez Massaguer wrote: > > In the Part I draft of PKIX (draft-ietf-pkix-ipki-part1-03.txt) document, >(end of 3.3 section) it is considered the possibility of (future ?) on-line >recovation checking approaches. > >I have reviewed: > > draft-ietf-pkix-ipki-part1-03.txt (Part I), > draft-ietf-pkix-polfmwk-00.txt (Policy), and > draft-ietf-pkix-ipki3cmd-02.txt (Part III) > >and apart from the mentioned 3.3 section in Part I and a little note in >section 6.6.1 in the Policy document, I haven't found anything more about >this theme. > >Is or will be this point considered in greater detail on some other of the >various draft parts or versions of PKIX ?. The original (and still current) plan was to have a number of parts. Part 2 is intended to cover client access protocols for other people's certificates (cert and crl retrieval, online validation, etc.) (as opposed to part 3 which include client protocols for one's own cert). Work on this hasn't started in any significant way yet. Since some work is going on now in piloting online validation mechanisms, I would hope that based on the results of such efforts we would attempt to capture a successful effort in part 2 rather than try to invent from paper. I'll admit there's no clear timetable for the document (we're looking for volunteers). >Thanks. >Francisco Fernandez. >------------------------------------------------------------------------ >Francisco Fernandez Massaguer E-mail: ffernandez@ait.uvigo.es >ETSI Telecomunicacion Vigo Tel: +34-86-812181 >Vigo, SPAIN Fax: +34-86-812116 >------------------------------------------------------------------------ > Thanks, Dave Solo From chandras@loc201.tandem.com Fri Jan 3 19:51:01 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id TAA22048; Fri, 3 Jan 1997 19:51:01 -0800 Received: from owlsnest.com by suntan.tandem.com (8.6.12/suntan5.961027) for id TAA22033; Fri, 3 Jan 1997 19:50:51 -0800 From: Received: (from owl@localhost) by owlsnest.com (8.7.5/8.7.3) id WAA29097; Fri, 3 Jan 1997 22:55:21 -0500 (EST) Date: Fri, 3 Jan 1997 22:55:21 -0500 (EST) Message-Id: <199701040355.WAA29097@owlsnest.com> To: ietf-pkix@tandem.com Reply-To: owl@owlsnest.com Subject: Is Your Web Site A Secret? Is your web site the best kept secret on the Internet? We'll promote it to 50 search engines and indexes for $85 and complete the job in 2 business days. Satisfaction is guaranteed! If you have a great product, but are not getting many inquiries from your Web site, you may not be adequately listed on the Web's search engines and indexes. Millions of viewers daily use these facilities to find the products and services they are looking for. But if your site is not listed, no one will see it. Listings on most of these services are free. However, locating and filling out the forms required to get a listing can take several days, and most people just don't have the time to do it. That is why we offer a web site promotion service. WHAT'S THE DEAL? We will submit your site to 50 indexes and search engines for $85. We will accept the return of this E-mail, with the form below filled out, as an order. We will bill you upon completion of the promotion. Our terms are net 15 days from date of invoice. Satisfaction guaranteed! HOW LONG WILL IT TAKE? Generally, we complete the submissions within 48 hours of receiving your order. It can take any individual search engine or index up to three weeks to process your submission, although most are much faster. WHAT SEARCH ENGINES AND INDEXES ARE INCLUDED IN THE PROMOTION? The list changes from time to time. This is our current list: Abaweb!, All Business Network, Alta Vista, Big Yellow, BizWeb, BizWiz, Brian's Revised Internet Yellow Pages, Central Source Yellow Pages, E!Net Galaxy, Enterpreneurs on the Web, Excite, Homecom's Global Village, I-Network, I-Systems Spiral Business Directory, Infoseek, Inktomi, Innovator's Network Yellow Pages, Internet Addressbook Yellow Pages, Internet Mall, ISP Internet Yellow Pages, Jumpcity, Jumper Hot Links, Linkmaster, Lycos, Magellan-McKinley Yellow Pages, NCSA What's New, Net-Happenings, NetMall, New Virtual Yellow Pages, NTG's List, OnLine's WWWeb Index, Open Market's Commercial Sites Index, Open Text Web Index, Rex, Spider's Pick of the Day, Starting Point, The Source, URL Tree, Web Central, Web Venture Hotlist, Webcrawler, Websurf, World Wide Yellow Pages, Worldwide Announce Archive, WWW Business Yellow Pages, WWW Worm, YelloWWWeb. HOW WILL I KNOW THAT YOU HAVE PROMOTED MY SITE? When we have completed the promotion, we will send you an HTML file as an attachment to your E-mail bill. Save this file to your disk, and view it through your Web browser. It provides links to the search engine we submitted your site to, plus any comments we received from them when we did it. ARE THERE ANY GUARANTEES? We do not require prepayment. Your satisfaction is guaranteed or you don't pay the bill. WHO IS OWL'S EYE PRODUCTIONS? We are a web site promotion company located at: Owl's Eye Productions, Inc. 260 E. Main Street Brewster, NY 10509 Phone: (914) 278-4933 Fax: (914) 278-4507 Email: owl@owlsnest.com HOW DO I ORDER? The easiest way to order is by e-mail. Just hit the REPLY button on your e-mail program and fill out the following information. (This information will be posted to the search engines/indexes): Your name: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: URL: http:// Site Title: Description (about 25 words): Key words (maximum of 25, in descending order of importance): If billing a different address, please complete the following: Addressee: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: We will bill via Email. (6D14) Terms: By returning this document via Email, you agree as follows: You have the authority to purchase this service on behalf of your company. Terms are net 15 days. Accounts sent to collections will be liable for collection costs. You agree to protect and indemnify Owl's Eye Productions, Inc. in any claim for libel, copyright violations, plagiarism, or privacy and other suits or claims based on the content or subject matter of your site. WHAT HAPPENS NEXT? When we receive your order, we will input the information into our system, and send you a proof. After we process any corrections, we will run your promotion, capturing any comments from search engines as we go. We will incorporate these into an HTML-formatted report to you, which we will attach to your bill. ===Web Promotions=====Press Releases=====Link Exchanges========= Owl's Eye Productions, Inc. 260 E. Main Street Brewster, NY 10509 Ph: 914-278-4933 Fx: 914-278-4507 E-mail: owlseye@owlsnest.com From chandras@loc201.tandem.com Mon Jan 6 08:17:06 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id IAA00701; Mon, 6 Jan 1997 08:17:06 -0800 Received: from netcomsv.netcom.com by suntan.tandem.com (8.6.12/suntan5.961027) for id IAA00697; Mon, 6 Jan 1997 08:17:05 -0800 Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id IAA06659; Mon, 6 Jan 1997 08:06:10 -0800 Received: from cc:Mail by spysouth.spyrus.com id AA852566344 Mon, 06 Jan 97 07:59:04 Date: Mon, 06 Jan 97 07:59:04 From: "Housley, Russ" Encoding: 4115 Text Message-Id: <9700068525.AA852566344@spysouth.spyrus.com> To: ietf-pkix@tandem.com, Mack.Hicks@bankamerica.com CC: pki@lists.commerce.net Subject: Re: On-line revocation checking Mack: What protocols are being used for on-line validation? And, does the private extension proposed in PKIX Part 1 provide all of the information necessary to perform on-line validation? Russ ______________________________ Reply Separator _________________________________ Subject: On-line revocation checking Author: "G. Mack Hicks, VP Bank of America" Date: 1/3/97 11:33 AM For: IETF-PKI mail list CommerceNet PKI Mail list Allow me to add to Francisco's question regarding on-line revocation. There is a persistent belief that directories (repositories) will deliver to any user upon any request the CRL of designated CA's (designated by the CA as an 'official' repository) signed by the CA. The directory will also deliver all certificates for a particular Distinguished Name (DN) and there will be many for particular users like SSLv3 certs, S/MIME certs, signature certs, encryption certs, and so on. I believe this flies in the face of the reality of on-line transaction cost structures and business models. The CommerceNet PKI task force has several business models that are to be demonstrated. None of these provide for the model that is proposed by IETF. There is a "Relationship Validation Model" that provides for subscribers of a CA to request the repository for that CA for on-line certificate validation. It is the responsibility of the subscriber's repository to contact the repository of the subject certificate to validate the certificate. Repositories may exchange CRLs if the volume of traffic is sufficient. To the point: It seems unreasonable to ask that a subscriber's repository provide unlimited service upon request from anyone with its remuneration provided by the subscriber. Rather, the subscriber should have contractual relationship with its CA and associated repository to provide certificate validation within the community of interest. The futility of the current model (for free) allows for the following situation: a) Subscriber sends a message to every member of the US congress (over 500 copies) b) Each member of congress goes to the repository of the subscriber and asks for 1) all certificates for the DN of the subscriber 2) latest CRL for the CA of the subscriber The repository ends up with over messages for each single message of the subscriber. In addition, the receiver (who is the party that must rely on the message) has no contractual relationship with the CA of the subscriber and no contractual relationship with the repository. Further, the receiver's system (browser, mailer, ...) must process -- Certificate list - finding the right one for this particular message. (Could be two - signature cert and encryption cert.) Then must grind through the CRL for to make sure the cert(s) are still good. This is quite a bit of work to do and proposes that all receiving software is able to determine the validation process for all certs within the community of interest. Both IETF PKIX and NIST MISPC "allow" for on-line validation of certificates. It is my impression of the business community that on-line validation is what is called for by business doing open commerce. Finally, the work with NIST MISPC and IETF PKIX seems to be focused on the functions of the CA strictly. Therefore most of the heavy lifting (replys to messages, etc) is put to the repository and receiving software (emailer, browser, ...). To demonstrate interoperability and functionality, the easiest model is to have the repositories operate "for free" (i.e. without authentication). I agree, this facilitates testing; it does not enable electronic commerce. For an implementation of a "relationship validation model" see the Zion Data Systems implementation for the repository for the state of Utah. (I have no URL reference, maybe someone can provide to the lists.) From chandras@loc201.tandem.com Mon Jan 6 08:15:29 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id IAA00567; Mon, 6 Jan 1997 08:15:29 -0800 Received: from netcomsv.netcom.com by suntan.tandem.com (8.6.12/suntan5.961027) for id IAA00563; Mon, 6 Jan 1997 08:15:27 -0800 Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id IAA06705; Mon, 6 Jan 1997 08:06:49 -0800 Received: from cc:Mail by spysouth.spyrus.com id AA852566353 Mon, 06 Jan 97 07:59:13 Date: Mon, 06 Jan 97 07:59:13 From: "Housley, Russ" Encoding: 782 Text Message-Id: <9700068525.AA852566353@spysouth.spyrus.com> To: ffdez@ait.uvigo.es (Francisco Fernandez Massaguer), ietf-pkix@tandem.com, Warwick Ford Subject: Re: On-line revocation checking I agree with Warwick that the protocol to be standardized for on-line validation is a subject for PKIX Part 2. However, the private extension must include the necessary information to properly invoke the on-line validation protocol. To this end, we need someone who is using the on-line validation approach to carefully review PKIX Part 1. Russ ______________________________ Reply Separator _________________________________ Subject: Re: On-line revocation checking Author: Warwick Ford at internet Date: 1/3/97 3:08 PM Francisco: I would consider on-line revocation checking an operational protocol, therefore, a topic for coverage in PKIX Part 2. Nobody has yet stepped forward to start development of Part 2. Warwick From chandras@loc201.tandem.com Mon Jan 6 09:07:33 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id JAA06642; Mon, 6 Jan 1997 09:07:33 -0800 Received: from relay3.UU.NET by suntan.tandem.com (8.6.12/suntan5.961027) for id JAA06639; Mon, 6 Jan 1997 09:07:31 -0800 Received: from relay.ieunet.ie by relay3.UU.NET with SMTP (peer crosschecked as: relay.ieunet.ie [192.111.39.1]) id QQbxiq18653; Mon, 6 Jan 1997 12:07:11 -0500 (EST) Received: from nixdub.sse.ie by relay.ieunet.ie with SMTP id aa24199; 6 Jan 97 17:02 +0000 Received: from baboo.sse.ie (baboo.sse.ie [193.120.33.34]) by nixdub.sse.ie (8.6.4/8.6.4) with ESMTP id RAA09807 for ; Mon, 6 Jan 1997 17:02:08 GMT Received: from baboo by baboo.sse.ie (SMI-8.6/SMI-SVR4) id RAA06676; Mon, 6 Jan 1997 17:02:43 GMT Message-Id: <199701061702.RAA06676@baboo.sse.ie> X-Mailer: exmh version 1.6.9 8/22/96 To: ietf-pkix@tandem.com Subject: RE: PKCS#7 in PKIX-3 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Jan 1997 17:02:43 +0000 From: Stephen Farrell Hi All, Given that we want to get another issue of PKIX-3 produced this month, I need to decide what to write about protection bits this week. I propose the following: 1. We keep the current protection bits definition and add text mandating support for these for some specific algorithm(s). That is, conforming implementations must be able to handle PKI messages which are protected using the specified algorithm(s) with the bits carried in the protectionBits field. 2. We add text highlighting the fact that, where available, any other (external) protection mechamism (e.g. S/MIME) may equally be used to protect PKI messages. (Probably the current text gives the impression that omitting the protection bits means that there is no protection.) In short, we mandate the ability to use the protection bits but do not mandate that every (or indeed, any) protected PKI message use the protection bits. The above allows us to produce a specificiation which supports interop (at least at the level of message protection) between any pair of implementations but which also leaves open the question as to what protection mechanisms are suitable for a given environment. In the absence of further discussion (optimism:-) this is what I'll put in the next draft. Regards, Stephen. -- ========================================================================== Stephen FARRELL.......................................tel: +353-1-676 9089 Software and Systems Engineering Ltd..................fax: +353-1-676 7984 Fitzwilliam Court............................email: stephen.farrell@sse.ie Leeson Close.....X.400: /c=ie/a=eirmail400/p=sse/o=sse/s=farrell/g=stephen Dublin 2...........................................www: http://www.sse.ie/ IRELAND................................................"A Siemens Company" ========================================================================== From chandras@loc201.tandem.com Mon Jan 6 12:46:22 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id MAA06595; Mon, 6 Jan 1997 12:46:22 -0800 Received: from verisign.com by suntan.tandem.com (8.6.12/suntan5.961027) for id MAA06590; Mon, 6 Jan 1997 12:46:21 -0800 Received: by PETER with Microsoft Mail id <01BBFBD0.147398B0@PETER>; Mon, 6 Jan 1997 12:49:39 -0800 Message-ID: <01BBFBD0.147398B0@PETER> From: Peter Williams To: "ietf-pkix@tandem.com" , "'Stephen Farrell'" Subject: RE: PKCS#7 in PKIX-3 Date: Mon, 6 Jan 1997 12:49:23 -0800 Encoding: 103 TEXT lets distinguish in the document two threat environments: (a) internal threats to the reliability of the certification system due to poor message handling (b) external threats to message communication affecting reliably auditable release, transport and auditable message delivery between distributed elements of the PKIX-3 agents (a) is countered by existing inband protection mechanism which support integrity and possibly confidentiality-based access control. (b) is countered by external protection mechanisms whose use (and possible generic reliance upon) is signalled by the PKIX-3 message This suggests that (i) PKIX-3 does not inherently change (the certification system and flows modelled in the PKIX-3 continues to resist the threats due to unreliable handling by end-points) as provided for by the inband protection mechanisms (ii) PKIX-3 mesage formats have an oid field, which identifies which external protection mechanism was used by an orignator to protect the release, transport and delivery of the message identified by msgId. I would expect that the PKIX-3 message would NOT be responsible for any end-end negotiation of, or specification of required capabilities of the external channels/controls (IPSEC would have to know how to agree algoirhtms, modes, services etc; likewise PKCS7 profiled for PKIX-3 protection, etc) Where a PKIX-3 access port provides for external protection models, the prevailing security policy text for the certification system (PKIX-3) should be responsible for stating the reliance upon the particular exernall security service, and detail how such events shall affect PKIX-3 handling The above sugegstion would suggest a syntax change to accommodate the OID, and specification of handling procedures for originator(s) and recipients for that element of service. The communication to a relying party of a cert that some std PKI policy was in effect (using the std extension profiled in PKIX-1) might be qualified by the fact that the certiifcation system used, in actual fact, external protection mechansm "foo" Such type of qualifier values are inherently local and exist for handling by the application to instrument reliance upon the cert based on evaulation of the id of that exernal protection process/control-system. A std qualifier might thus be formulated to satisfy this requirement. its qyntax might thus be only an organizationally-issued object identifier serving to discriminate amongnst highly localised external control systems. (one shoudl remember thath reliance upon a qualifier, to accept a policy, is an application entity decision, not a requirement of the X.509 std cert evaluation algorithm. Reliance policies for applications which choose to ignore the list of delivered qualifiers, are free to do so, as always. Peter. ---------- From: Stephen Farrell Sent: Monday, January 06, 1997 9:02 AM To: ietf-pkix@tandem.com Subject: RE: PKCS#7 in PKIX-3 Hi All, Given that we want to get another issue of PKIX-3 produced this month, I need to decide what to write about protection bits this week. I propose the following: 1. We keep the current protection bits definition and add text mandating support for these for some specific algorithm(s). That is, conforming implementations must be able to handle PKI messages which are protected using the specified algorithm(s) with the bits carried in the protectionBits field. 2. We add text highlighting the fact that, where available, any other (external) protection mechamism (e.g. S/MIME) may equally be used to protect PKI messages. (Probably the current text gives the impression that omitting the protection bits means that there is no protection.) In short, we mandate the ability to use the protection bits but do not mandate that every (or indeed, any) protected PKI message use the protection bits. The above allows us to produce a specificiation which supports interop (at least at the level of message protection) between any pair of implementations but which also leaves open the question as to what protection mechanisms are suitable for a given environment. In the absence of further discussion (optimism:-) this is what I'll put in the next draft. Regards, Stephen. -- ========================================================================== Stephen FARRELL.......................................tel: +353-1-676 9089 Software and Systems Engineering Ltd..................fax: +353-1-676 7984 Fitzwilliam Court............................email: stephen.farrell@sse.ie Leeson Close.....X.400: /c=ie/a=eirmail400/p=sse/o=sse/s=farrell/g=stephen Dublin 2...........................................www: http://www.sse.ie/ IRELAND................................................"A Siemens Company" ========================================================================== From chandras@loc201.tandem.com Tue Jan 7 11:58:03 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id LAA08553; Tue, 7 Jan 1997 11:58:03 -0800 Received: from mag1.magmacom.com by suntan.tandem.com (8.6.12/suntan5.961027) for id LAA08546; Tue, 7 Jan 1997 11:57:56 -0800 Received: (from mbartel@localhost) by mag1.magmacom.com (8.8.4/8.7.3) id OAA03127 for ietf-pkix@tandem.com; Tue, 7 Jan 1997 14:57:26 -0500 (EST) From: Mark Bartel Message-Id: <199701071957.OAA03127@mag1.magmacom.com> Subject: Error in encoding of subjectUniqueIdentifier To: ietf-pkix@tandem.com Date: Tue, 7 Jan 1997 14:57:26 -0500 (EST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I was searching for examples that use UniversalString in the Subject or Issuer names (anybody know of any?) when I found the following in a certificate example: A2 13 00 13 10 39 37 35 32 32 31 35 32 31 32 33 34 35 36 37 31 -- subjectUniqueIdentifier ("9752 2152 1234 5671") This is the only example I've ever found that uses subjectUniqueIdentifier. Shouldn't it be flagged primitive rather than constructed? As in 82 13 00 13 10 39 37 35 32 32 31 35 32 31 32 33 34 35 36 37 31 -- subjectUniqueIdentifier ("9752 2152 1234 5671") (The example is from the Swedish SEIS project, at http://www.seis.se/proj/card/seis3v1.html.) - Mark Bartel From chandras@loc201.tandem.com Wed Jan 8 00:49:12 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id AAA24118; Wed, 8 Jan 1997 00:49:12 -0800 Received: from argus.Posten.SE by suntan.tandem.com (8.6.12/suntan5.961027) for id AAA24109; Wed, 8 Jan 1997 00:48:59 -0800 Received: (from smap@localhost) by argus.Posten.SE (8.7.3/8.7.3) id JAA29721; Wed, 8 Jan 1997 09:48:33 +0100 (MET) Received: from unknown(192.36.235.11) by argus.Posten.SE via smap (V1.3) id sma029719; Wed Jan 8 09:48:17 1997 Received: from shogun.psab.posten.se by psab.posten.se (4.1/SMI-4.1) id AA25241; Wed, 8 Jan 97 09:48:43 +0100 Received: from bird.psab.posten.se by shogun.psab.posten.se with SMTP (5.65/25-1.0-eef) id AA09641; Wed, 8 Jan 97 10:01:52 +0100 Message-Id: <32D35E93.20C6@psab.posten.se> Date: Wed, 08 Jan 1997 09:45:07 +0100 From: Lars Johansson Organization: PSab X-Mailer: Mozilla 3.0 (Win95; I) Mime-Version: 1.0 To: Mark Bartel Cc: SEIS.kortgrupp@janus.swipnet.se, ietf-pkix@tandem.com Subject: Re: Error in encoding of subjectUniqueIdentifier References: <199701071957.OAA03127@mag1.magmacom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Bartel wrote: > > I was searching for examples that use UniversalString in the Subject > or Issuer names (anybody know of any?) when I found the following in a > certificate example: > > A2 13 00 13 10 39 37 35 32 32 31 35 32 31 32 33 34 35 36 37 31 > -- subjectUniqueIdentifier ("9752 2152 1234 5671") > > This is the only example I've ever found that uses subjectUniqueIdentifier. > Shouldn't it be flagged primitive rather than constructed? As in > > 82 13 00 13 10 39 37 35 32 32 31 35 32 31 32 33 34 35 36 37 31 > -- subjectUniqueIdentifier ("9752 2152 1234 5671") > > (The example is from the Swedish SEIS project, at > http://www.seis.se/proj/card/seis3v1.html.) > > - Mark Bartel You are absolutely correct! The tag should've been '82' instead of 'A2'. There are slightly more errors in the certificate example in the SEIS S3 document. However this spec is currently being updated. Thanks for your comment! /Lars Johansson Sweden Post From chandras@loc201.tandem.com Thu Jan 9 05:45:10 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id FAA18411; Thu, 9 Jan 1997 05:45:10 -0800 Received: from cale.checkpoint.com by suntan.tandem.com (8.6.12/suntan5.961027) for id FAA18400; Thu, 9 Jan 1997 05:44:49 -0800 Received: from gov.checkpoint.com (gov.checkpoint.com [199.203.71.9]) by cale.checkpoint.com (8.8.3/8.7.1) with SMTP id PAA02193; Thu, 9 Jan 1997 15:42:58 +0200 (IST) Received: by gov.checkpoint.com (SMI-8.6/SMI-SVR4) id PAA02511; Thu, 9 Jan 1997 15:42:01 +0200 Date: Thu, 9 Jan 1997 15:42:01 +0200 From: motif@checkpoint.com (Moti Frances) Message-Id: <199701091342.PAA02511@gov.checkpoint.com> To: ietf-pkix@tandem.com, ietf-asid@umich.edu Subject: LDAP server with X509 certificates X-Sun-Charset: US-ASCII Hello All, Does anybody know about LDAP servers that hold X509 certificates and are available for public usage ? Thanx, Moti. =========================================================================== Moti Frances motif@checkpoint.com Tel: + 972 3 6131833 extension 149 --------------------------------------------------------------------------- CheckPoint Software Technologies Ltd. 3A Jabotinsky St., Diamond Tower | Tel: + 972 3 6131833 Ramat-Gan 52511, ISRAEL | Fax: + 972 3 5759256 http://www.checkpoint.com ============================================================================ From chandras@loc201.tandem.com Thu Jan 9 07:24:48 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id HAA25387; Thu, 9 Jan 1997 07:24:48 -0800 Received: from cale.checkpoint.com by suntan.tandem.com (8.6.12/suntan5.961027) for id HAA25382; Thu, 9 Jan 1997 07:24:45 -0800 Received: from gov.checkpoint.com (gov.checkpoint.com [199.203.71.9]) by cale.checkpoint.com (8.8.3/8.7.1) with SMTP id RAA01834; Thu, 9 Jan 1997 17:23:08 +0200 (IST) Received: by gov.checkpoint.com (SMI-8.6/SMI-SVR4) id RAA02547; Thu, 9 Jan 1997 17:22:12 +0200 Date: Thu, 9 Jan 1997 17:22:12 +0200 From: motif@checkpoint.com (Moti Frances) Message-Id: <199701091522.RAA02547@gov.checkpoint.com> To: ietf-pkix@tandem.com Subject: LDAP server with X509 certificates Cc: motif@checpoint.com X-Sun-Charset: US-ASCII Hello All, Does anybody know about LDAP servers that hold X509 certificates and are available for public usage ? Thanx, Moti. =========================================================================== Moti Frances motif@checkpoint.com Tel: + 972 3 6131833 extension 149 --------------------------------------------------------------------------- CheckPoint Software Technologies Ltd. 3A Jabotinsky St., Diamond Tower | Tel: + 972 3 6131833 Ramat-Gan 52511, ISRAEL | Fax: + 972 3 5759256 http://www.checkpoint.com ============================================================================ From chandras@loc201.tandem.com Thu Jan 9 08:34:22 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id IAA02068; Thu, 9 Jan 1997 08:34:22 -0800 Received: from cale.checkpoint.com by suntan.tandem.com (8.6.12/suntan5.961027) for id IAA02046; Thu, 9 Jan 1997 08:34:18 -0800 Received: from gov.checkpoint.com (gov.checkpoint.com [199.203.71.9]) by cale.checkpoint.com (8.8.3/8.7.1) with SMTP id SAA05304; Thu, 9 Jan 1997 18:32:39 +0200 (IST) Received: by gov.checkpoint.com (SMI-8.6/SMI-SVR4) id SAA02564; Thu, 9 Jan 1997 18:31:42 +0200 Date: Thu, 9 Jan 1997 18:31:42 +0200 From: motif@checkpoint.com (Moti Frances) Message-Id: <199701091631.SAA02564@gov.checkpoint.com> To: ietf-pkix@tandem.com Subject: LDAP server with X509 certificates Cc: motif@checkpoint.com X-Sun-Charset: US-ASCII Hello All, Does anybody know about LDAP servers that hold X509 certificates and are available for public usage ? Thanx, Moti. =========================================================================== Moti Frances motif@checkpoint.com Tel: + 972 3 6131833 extension 149 --------------------------------------------------------------------------- CheckPoint Software Technologies Ltd. 3A Jabotinsky St., Diamond Tower | Tel: + 972 3 6131833 Ramat-Gan 52511, ISRAEL | Fax: + 972 3 5759256 http://www.checkpoint.com ============================================================================ From chandras@loc201.tandem.com Fri Jan 10 16:05:25 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id QAA10620; Fri, 10 Jan 1997 16:05:25 -0800 Received: from relay.hq.tis.com by suntan.tandem.com (8.6.12/suntan5.961027) for id QAA10610; Fri, 10 Jan 1997 16:05:21 -0800 Received: by relay.hq.tis.com; id TAA08845; Fri, 10 Jan 1997 19:08:23 -0500 (EST) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (3.2) id xma008806; Fri, 10 Jan 97 19:08:03 -0500 Received: from sol.hq.tis.com (sol [10.33.1.100]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id TAA17775; Fri, 10 Jan 1997 19:01:41 -0500 (EST) Received: from sol.hq.tis.com by sol.hq.tis.com (4.1/SMI-4.1) id AA23417; Fri, 10 Jan 97 19:01:40 EST Message-Id: <9701110001.AA23417@sol.hq.tis.com> To: cat-ietf@mit.edu, e-payment@bellcore.com, firewalls@greatcircle.com, ids@uow.edu.au, ietf-otp@bellcore.com, ietf-pkix@tandem.com, ietf-tls@w3.org, ietf@cnri.reston.va.us, ipsec@ans.net, pem-dev@tis.com, psrg@isi.edu, sndss-authors@isi.edu, sndss-chairs@tis.com, spki@c2.net, virus-l@lehigh.edu, www-buyinfo@allegra.att.com, www-security@ns2.rutgers.edu Subject: 2ND ANNOUNCEMENT: ISOC 97 SYMP NETWORK & DISTRIBUTED SYSTEM SECURITY Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <23400.852940884.1@tis.com> Date: Fri, 10 Jan 1997 19:01:26 -0500 From: "David M. Balenson" PLEASE NOTE THE EARLY REGISTRATION AND HOTEL ROOM AVAILABILITY AND SPECIAL RATES DEADLINES ARE APPROACHING!! RESERVATIONS AT THE PRINCESS RESORT MUST BE MADE NO LATER THAN JAN 13TH FOR THE GOVERNMENT RATE, AND NO LATER THAN JAN 20TH FOR THE REDUCED GROUP RATE. EARLY REGISTRATION FOR THE SYMPOSIUM MUST BE POSTMARKED NO LATER THAN JAN 22ND. --------------------------------------------------------------------------- THE INTERNET SOCIETY 1997 SYMPOSIUM ON NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS '97) 10-11 FEBRUARY 1997 SAN DIEGO PRINCESS RESORT, SAN DIEGO, CALIFORNIA This fourth annual symposium will bring together researchers, implementors, and users of network and distributed system security technologies to discuss today's important security issues and challenges. It will provide 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. We hope to foster the exchange of technical information and encourage the Internet community to deploy available security technologies and develop new solutions to unsolved problems. WHY YOU SHOULD ATTEND The use of the Internet is rapidly growing and expanding into all aspects of our society. Commercial organizations are coming under increasing pressure to make their services available on-line. This in turn is increasing the need for rapid and widespread deployment of usable and effective network and distributed system security technologies. High visibility attacks on the Internet underscore the vulnerabilities of the Internet and the need to solve its security problems. There is growing concern for securing the network infrastructure itself. Recent trends in software distribution (such as Java and ActiveX technologies) have made certain attacks easier to carry out. Privacy has become an important issue for the Internet. NDSS '97 will bring together researchers, implementors, and users of network and distributed system technologies to discuss today's important security issues and challenges. We have selected the technical papers and panel presentations that describe promising new approaches to security problems that are practical, and to the extent possible, have been implemented. Topics to be addressed include Internet infrastructure and routing security, security for the World Wide Web, Java and ActiveX security, cryptographic protocols, public key management, and protection of privacy. The symposium will have a positive impact on the state of Internet security. You will have the opportunity to actively participate in the dialog. Ask questions of the speakers, raise your important issues during the panel sessions, and let other participants know of your requirements, observations, and experience in this important area. We hope to encourage the wide-scale deployment of security technologies and to promote new research that can address the currently unmet security needs of the Internet community. CONTENTS Preliminary Program Organizing Committee San Diego Princess Resort Registration Information Registration Form --------------------------------------------------------------------------- P R E L I M I N A R Y P R O G R A M SUNDAY, FEBRUARY 9 6:00 P.M. - 8:00 P.M. RECEPTION - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MONDAY, FEBRUARY 10 7:30 A.M. CONTINENTAL BREAKFAST 8:30 A.M. OPENING REMARKS 9:00 A.M. SESSION 1: THINGS THAT GO BUMP IN THE NET Chair: Stephen T. Kent (BBN Corporation, USA) Experimental Results of Covert Channel Elimination in One-Way Communication Systems, Nick Ogurtsov, Hilarie Orman, Richard Schroeppel, Sean O'Malley, and Oliver Spatscheck (University of Arizona, USA) Blocking Java Applets at the Firewall, David M. Martin Jr., Sivaramakrishnan Rajagopalan and Aviel D. Rubin (Bellcore, USA) Continuous Assessment of a Unix Configuration: Integrating Intrusion Detection & Configuration Analysis, Abdelaziz Mounji and Baudouin Le Charlier (Institut D'Informatique, Namur, BELGIUM) 10:30 A.M. BREAK 11:00 A.M. SESSION 2: PANEL: SECURITY OF DOWNLOADABLE EXECUTABLE CONTENT Chair: Aviel Rubin (AT&T Research Labs, USA) Panelists: Li Gong (JavaSoft, USA), Jim Roskind (Netscape, USA), Edward W. Felten (Princeton University, USA) and Peter G. Neumann (SRI International, USA) 12:30 NOON LUNCH 2:00 P.M. SESSION 3: PROTOCOL IMPLEMENTATION AND ANALYSIS Chair: Christoph Schuba (Purdue University, USA) An Interface Specification Language for Automatically Analyzing Cryptographic Protocols, Stephen H. Brackin (Arca Systems, USA) Probable Plaintext Cryptanalysis of the IP Security Protocols, Steven M. Bellovin (AT&T Research, USA) Misplaced Trust: Kerberos Version 4 Session Keys, Bryn Dole (Sun Microsystems), Steve Lodin (Delco Electronics), and Eugene Spafford (Purdue University, USA) 3:30 P.M. BREAK 4:00 P.M. SESSION 4: PANEL: SECURITY OF THE INTERNET INFRASTRUCTURE Chair: Russ Mundy (Trusted Information Systems, USA) Panelists: Paul Lambert (Oracle, USA), Jeff Schiller (MIT, USA), Olafur Gudmundsson (Trusted Information Systems, USA) 7:00 P.M. DINNER BANQUET - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TUESDAY, FEBRUARY 11 7:30 A.M. CONTINENTAL BREAKFAST 8:30 A.M. SESSION 5: ROUTING SECURITY Chair: Hilarie Orman (DARPA, USA) Securing the Nimrod Routing Architecture, Karen E. Sirois and Stephen T. Kent (BBN Corporation, USA) Securing Distance-Vector Routing Protocols, Bradley R. Smith, Shree Murthy and J.J. Garcia-Luna-Aceves (University of California Santa Cruz, USA) Reducing the Cost of Security in Link-State Routing, R. Hauser, A. Przygienda and G. Tsudik (IBM and USC/ISI, USA) 10:00 A.M. BREAK 10:30 A.M. SESSION 6: SECURITY FOR THE WORLD WIDE WEB Chair: Win Treese (OpenMarket, USA) Securing Web Access with DCE, Brian C. Schimpf (Gradient Technologies, USA) PANEL: SECURITY FOR THE WORLD WIDE WEB Chair: Win Treese (OpenMarket, USA) 12:00 A.M. LUNCH 1:30 P.M. SESSION 7: PUBLIC KEY MANAGEMENT Chair: Jonathan Trostle (CyberSafe, USA) Hierarchical Organization of Certification Authorities for Secure Environments, Lourdes Lopez and Justo Carracedo (Universidad Politecnica de Madrid, SPAIN) Trust Models in ICE-TEL, Andrew Young and Nada Kapidzic Cicovic (Univeristy of Salford, UNITED KINGDOM) Distributed Authentication in Kerberos Using Public Key Cryptography, Marvin Sirbu and John Chung-I Chuang (Carnegie Mellon University, USA) 3:00 P.M. BREAK 3:30 P.M. SESSION 8: PANEL: WEB PRIVACY AND ANONYMITY Chair: Clifford Neuman (USC Information Sciences Institute, USA) --------------------------------------------------------------------------- O R G A N I Z I N G C O M M I T T E E GENERAL CHAIR David Balenson, Trusted Information Systems PROGRAM CHAIRS Clifford Neuman, USC Information Sciences Institute Matt Bishop, University of California at Davis PROGRAM COMMITTEE Steve Bellovin, AT&T Research Tom Berson, Anagram Laboratories Doug Engert, Argonne National Laboratory Warwick Ford, Verisign Richard Graveman, Bellcore Li Gong, JavaSoft Burt Kaliski, RSA Laboratories Steve Kent, BBN Corporation Tom Longstaff, CERT Doug Maughan, National Security Agency Dan Nessett, 3Com Corporation Hilarie Orman, DARPA/ITO Michael Roe, University of Cambridge Christoph Schuba, Purdue University Jonathan Trostle, CyberSafe Theodore Ts'o, Massachusetts Institute of Technology Doug Tygar, Carnegie Mellon University Vijay Varadharajan, University of W. Sydney Roberto Zamparo, Telia Research PUBLICATIONS CHAIR Steve Welke, Institute for Defense Analyses LOCAL ARRANGEMENTS CHAIR Thomas Hutton, San Diego Supercomputer Center REGISTRATIONS CHAIR Torryn Brazell, Internet Society STEERING GROUP Internet Research Task Force, Privacy and Security Research Group SPONSORED BY THE INTERNET SOCIETY Donald M. Heath, President & CEO Martin Burack, Executive Director --------------------------------------------------------------------------- S A N D I E G O P R I N C E S S R E S O R T LOCATION The Symposium venue is the San Diego Princess Resort, a tropical paradise on a forty-four acre island in Mission Bay, ten minutes from the international airport. Lush gardens landscaped with hundreds of species of tropical and subtropical plants are always ablaze with color and perfect for themed group events. Charming pathways wander among sparkling waterfalls, across quaint footbridges and sleepy lagoons filled with water lilies and waterfowl. A white sand beach curves around the island for over a mile, and the award-winning grounds encompass five swimming pools and six lighted tennis courts. Spouses and family members can catch a convenient Harbor Hopper for a quick trip to Sea World. Plan to visit La Jolla, the world famous San Diego Zoo or Mexico, only 30 minutes by car or Trolley. HOUSING INFORMATION We have reserved a special block of sleeping rooms at the San Diego Princess Resort at the following rates: Lanai Patio Rooms $ 81* Lanai Garden Rooms $114 * This represents the Government Rate for San Diego. A limited number of rooms are available at this rate. Reservations must be made no later than January 13, 1997. You must present a valid government id upon check-in. Based on room type and space availability, the special group rates are applicable two days prior to and two days after the symposium. Current Room Tax is 10.5%. Check-in availability cannot be committed prior to 4:00 p.m. Check-out time is 12:00 noon. The San Diego Princess Resort will make every effort to accommodate any early arrivals, so make sure you give them your arrival time when you make your reservation. TO MAKE A RESERVATION Contact the San Diego Princess Resort at +1-800-344-2626 (+1-619-274-4630 if outside the United States). To receive the special group rates, reservations must be made no later than January 20, 1997. To receive the special goverment rate, you must make your reservation by January 13, 1997. CLIMATE February weather in San Diego is normally very pleasant. Early morning temperatures average 55 degrees while afternoon temperatures average 67 degrees. Generally, a light jacket or sweater is adequate, although, occasionally it rains. --------------------------------------------------------------------------- R E G I S T R A T I O N I N F O R M A T I O N FEES ISOC Non- Members Member* Early registration (postmarked on/before Jan. 22) $305 $345 Late registration $375 $415 REGISTRATION INCLUDES - Attendance - Symposium Proceedings - Two luncheons - Reception - Banquet - Coffee Breaks * Non-Member fee includes one year Internet Society membership. FOR MORE INFORMATION Contact Carol Gray at the Internet Society at +1-703-648-9888 or send E-mail to Ndss97reg@isoc.org. WEB PAGE Additional information about the symposium and San Diego, plus on-line registration, are available via the Web at: http://www.isoc.org/conferences/ndss97 SPONSORSHIP OPPORTUNITIES AVAILABLE! Contact Torryn Brazell at the Internet Society at +1-703-648-9888 or send E-mail to Ndss97reg@isoc.org. --------------------------------------------------------------------------- R E G I S T R A T I O N F O R M INTERNET SOCIETY SYMPOSIUM ON NETWORK AND DISTRIBUTED SYSTEM SECURITY 10-11 FEBRUARY, 1997 SAN DIEGO, CALIFORNIA, USA Fill out this form and FAX it to NDSS'97 Registration at +1-703-648-9887, send it via E-mail to Ndss97reg@isoc.org, or mail it to NDSS97, 12020 Sunrise Valley Drive, Suite 210, Reston, VA, 20191, USA PERSONAL INFORMATION __Mr __Ms __Mrs __Dr __Prof __M __Prof Dr __Dip Ing __Ing __Miss __Mlle First Name: ________________________________ MI: ____________________ Family Name: ___________________________________ __Sr __Jr __II __III Badge Name: __________________________________________________________ Please enter your name as you would like it to appear on your name tag. CONTACT INFORMATION Title: _______________________________________________________________ Organization: ________________________________________________________ Street address: ______________________________________________________ ______________________________________________________________________ City: ________________________________________________________________ State/Province: ___________________________ Postal Code: ____________ Country: _____________________________________________________________ Telephone Number (work): _____________________________________________ Telephone Number (home): _____________________________________________ Fax Number: __________________________________________________________ E-mail address: ______________________________________________________ SPECIAL NEEDS? (Vegetarian meals, wheelchair access, etc?) ______________________________________________________________________ ______________________________________________________________________ APPEAR ON REGISTRANTS LIST? ___ Please check here if you would NOT like your name included in the list of registrants. PAYMENT INFORMATION All Payments must be in United States Dollars. Conference Fee -------------- If you are an Internet Society member, you are eligible for a reduced conference registration fee. Non-member symposium attendees will receive a one year Internet Society membership as part of the non-member registration fees. Check one: On/Before After January 22 January 22 ---------- ---------- ___ Internet Society Member Fee US$ 305.00 US$ 375.00 ___ Non-Member Fee US$ 345.00 US$ 415.00 Method of Payment ----------------- Payment must be received on/before February 7, 1997 or we will be unable to pre-register you. 1. ___ Check. Make payable to the Internet Society. 2. ___ Credit Card. ___ American Express ___ Visa ___ Mastercard Name on Credit Card: ____________________________________ Credit Card Number: _____________________________________ Expiration Date: ________________________________________ 3. ___ CyberCash. Account Number: _____________________________ 4. ___ First Virtual. Account Number: _________________________ 5. ___ Wire Transfer* Bank ABA Number: 054000030 Account Number: Internet Society 148 387 10 Riggs National Bank of Virginia 950 Herndon Parkway Herndon, VA 20171 USA Wire Transfer Confirmation Number: ______________________ * Please process wire transfer before sending registration form. 6. ___ U.S. Government Purchase Order* P.O. Number: ____________________________________________ * Please fax or mail a copy of your purchase order along with your registration form. Cancellation Policy ------------------- Refunds (less a $25 processing fee) will be issued for cancellations received on/before February 7, 1997. No refunds will be issued after February 7, 1997. ------------------------------------------------------------------------ From chandras@loc201.tandem.com Fri Jan 10 18:53:50 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id SAA27618; Fri, 10 Jan 1997 18:53:50 -0800 Received: from crack.x509.com by suntan.tandem.com (8.6.12/suntan5.961027) for id SAA27606; Fri, 10 Jan 1997 18:53:47 -0800 Received: from mac-50.x509.com ([199.175.148.50]) by crack.x509.com (8.8.3/8.8.3) with ESMTP id SAA20565; Fri, 10 Jan 1997 18:51:19 -0800 (PST) Received: (from patr@localhost) by mac-50.x509.com (8.6.12/8.6.12) id SAA00337; Fri, 10 Jan 1997 18:50:07 -0800 Date: Fri, 10 Jan 1997 18:50:06 -0800 (PST) From: "Patrick C. Richard" To: Moti Frances cc: ietf-pkix@tandem.com, motif@checkpoint.com Subject: Re: LDAP server with X509 certificates In-Reply-To: <199701091631.SAA02564@gov.checkpoint.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 9 Jan 1997, Moti Frances wrote: > Hello All, > > Does anybody know about LDAP servers that hold X509 certificates > and are available for public usage ? > Try https://www.xcert.com > Thanx, > Moti. > > > =========================================================================== > Moti Frances > motif@checkpoint.com > Tel: + 972 3 6131833 extension 149 > --------------------------------------------------------------------------- > CheckPoint Software Technologies Ltd. > 3A Jabotinsky St., Diamond Tower | Tel: + 972 3 6131833 > Ramat-Gan 52511, ISRAEL | Fax: + 972 3 5759256 > > http://www.checkpoint.com > ============================================================================ > ---- Pat Richard patr@x509.com From chandras@loc201.tandem.com Mon Jan 13 01:48:44 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id BAA23246; Mon, 13 Jan 1997 01:48:44 -0800 Received: from hitiij.hitachi.co.jp by suntan.tandem.com (8.6.12/suntan5.961027) for id BAA23236; Mon, 13 Jan 1997 01:48:34 -0800 Received: from hsdlgw92.sdl.hitachi.co.jp by hitiij.hitachi.co.jp (8.8.3+2.6Wbeta9/3.4Wbeta6-hitiij) id SAA09460; Mon, 13 Jan 1997 18:48:57 +0900 (JST) Received: from ([133.144.102.130]) by hsdlgw92.sdl.hitachi.co.jp (5.67+1.6W/2.7W-HSDL) id AA07893; Mon, 13 Jan 97 18:48:30 JST Received: from java by yokolab.sdl.hitachi.co.jp (5.67+1.6W/SMI-4.1) id AA19117; Mon, 13 Jan 97 18:48:30 JST Message-Id: <32DA0533.17DB@sdl.hitachi.co.jp> Date: Mon, 13 Jan 1997 18:49:39 +0900 From: Taketoshi Sakuraba Reply-To: sakuraba@sdl.hitachi.co.jp Organization: Hitachi, Ltd. X-Mailer: Mozilla 3.0 [ja] (Win95; I) Mime-Version: 1.0 To: ietf-pkix@tandem.com Subject: subscribe Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit subscribe sakuraba@sdl.hitachi.co.jp ietf-pkix From chandras@loc201.tandem.com Mon Jan 13 07:00:56 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id HAA10192; Mon, 13 Jan 1997 07:00:56 -0800 Received: from siamail by suntan.tandem.com (8.6.12/suntan5.961027) for id HAA10179; Mon, 13 Jan 1997 07:00:51 -0800 Received: from [190.9.155.27] by siamail with SMTP (1.38.193.4/16.2) id AA05254; Mon, 13 Jan 1997 16:00:39 +0100 X-Mailer: InterCon TCP/Connect II 2.2.1 Mime-Version: 1.0 Message-Id: <9701131703.AA33903@Mac di Adriano Santoni> Date: Mon, 13 Jan 1997 17:03:33 +0100 From: "Adriano Santoni" To: ietf-pkix@tandem.com Subject: About restrictions on length of certificate fields Content-Type: Multipart/Mixed;boundary=part_AF001B650008546500000002 --part_AF001B650008546500000002 Content-Type: Text/Plain; charset=US-ASCII Content-Disposition: Inline Hello PKIXers! Is anybody willing to explain whether is there any sort of restrictions, imposed either by consequences of standards or by practice or common sense, on the length of seemingly unlimited-length X.509 fields like subject, or subjectAltName, etc. ??? Many thanks to any volunteer, Adriano Santoni --part_AF001B650008546500000002 Content-Type: Text/Plain; charset=US-ASCII Content-Disposition: Inline Ing. Adriano Santoni Ufficio Progetti WAN c/o Direzione Rete SIA - Societa' Interbancaria per l'Automazione S.p.A. Viale Certosa 218, 20156 Milano, ITALIA vox: +39(2)3005.277 fax: +39(2)38003333 cell: 0338-8495592 --part_AF001B650008546500000002-- From chandras@loc201.tandem.com Tue Jan 14 06:44:34 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id GAA15428; Tue, 14 Jan 1997 06:44:34 -0800 Received: from hermes.research.kpn.com by suntan.tandem.com (8.6.12/suntan5.961027) for id GAA15385; Tue, 14 Jan 1997 06:43:54 -0800 Received: from ntl11.research.kpn.com by research.kpn.com (PMDF V5.1-5 #18053) with SMTP id <01IE7IJB8SW6001ORW@research.kpn.com> for ietf-pkix@tandem.com; Tue, 14 Jan 1997 15:43:39 +0100 Received: by ntl11.research.kpn.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC0231.DB272500@ntl11.research.kpn.com>; Tue, 14 Jan 1997 15:44:41 +0100 Date: Tue, 14 Jan 1997 15:44:46 +0100 From: "Sheedy, E.C.C." Subject: subscribe To: "'ietf-pkix@tandem.com'" Message-id: MIME-version: 1.0 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Kamer : B40 Telefoon : (050-58)22816 Fax : 050-3122415 Email : e.c.c.sheedy@research.kpn.com From chandras@loc201.tandem.com Tue Jan 14 08:57:17 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id IAA27900; Tue, 14 Jan 1997 08:57:17 -0800 Received: from mag1.magmacom.com by suntan.tandem.com (8.6.12/suntan5.961027) for id IAA27890; Tue, 14 Jan 1997 08:57:15 -0800 Received: (from mbartel@localhost) by mag1.magmacom.com (8.8.4/8.7.3) id LAA17005 for ietf-pkix@tandem.com; Tue, 14 Jan 1997 11:56:44 -0500 (EST) From: Mark Bartel Message-Id: <199701141656.LAA17005@mag1.magmacom.com> Subject: Questions about character sets and their encodings To: ietf-pkix@tandem.com Date: Tue, 14 Jan 1997 11:56:44 -0500 (EST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I've been searching for resources on the web on character sets for ASN.1 types, but haven't been able to find what I need. Does anybody know of such resources? More specifically, my questions are: IA5String: I've heard this is just 7-bit ASCII, but is that true? TeletexString: I understand that one can select different character sets with escape codes; does anybody have the set of escape codes and character sets they select? UniversalString: X.690 says that this is encoded in 4-octet canonical form, which I would imagine is 4 bytes, big-endian. Also, I believe that the subset of the 32-bit space with the high 16 bits set to 0 is equivalent to Unicode. Am I correct in these assumptions? X.690 says a bunch of things that I don't really understand (probably because I don't have X.680) about character string types and their encodings. Also, what is the tag for UniversalString? Does anybody have examples of certificates with UniversalString values in the Issuer or Subject? I've heard that Microsoft certificates do, but when I queried Verisign for Microsoft certificates they didn't. I couldn't get ahold of any Microsoft products that actually issue certificates to check that possibility. I know I could probably get the answers by ordering ISO/IEC 10646-1 and X.680, but from what I can see I'd have to do it snail mail. I'd rather not. - Mark Bartel From chandras@loc201.tandem.com Tue Jan 14 10:09:36 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id KAA08227; Tue, 14 Jan 1997 10:09:36 -0800 Received: from felix.austin.isode.com by suntan.tandem.com (8.6.12/suntan5.961027) for id KAA08200; Tue, 14 Jan 1997 10:09:29 -0800 Received: from prev.critical-angle.com by felix.austin.isode.com with Internet SMTP (PP); Tue, 14 Jan 1997 12:07:58 -0600 From: Mark Wahl To: Mark Bartel cc: ietf-pkix@tandem.com Subject: Re: Questions about character sets and their encodings Date: Tue, 14 Jan 1997 12:05:13 -0600 Message-ID: <2014.853265113@prev.critical-angle.com> Sender: M.Wahl@critical-angle.com > IA5String: I've heard this is just 7-bit ASCII, but is that true? Letters and number characters are the same as ASCII. Instead of a dollar sign, IA5String may have a "currency symbol". > TeletexString: I understand that one can select different > character sets with escape codes; does anybody have the set of escape > codes and character sets they select? The character sets are Japanese Kanji (JIS C 6226-1983, set No. 87), Chinese (GB 2312-80, set No. 58), and Greek. There are character set shifting codes in ITU-T Rec. T.61(88). IMHO it would probably be much easier to use UniversalString and BMPString than T.61 for non-Western-European character sets. > encodings. Also, what is the tag for UniversalString? I think UniversalString is UNIVERSAL 28 and BMPString is UNIVERSAL 30. BMPString is a two-byte encoding of the UniversalString characters in the 0/0 plane. Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From chandras@loc201.tandem.com Wed Jan 15 08:30:27 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id IAA02675; Wed, 15 Jan 1997 08:30:27 -0800 Received: from argus.Posten.SE by suntan.tandem.com (8.6.12/suntan5.961027) for id IAA02667; Wed, 15 Jan 1997 08:30:23 -0800 Received: (from smap@localhost) by argus.Posten.SE (8.7.3/8.7.3) id RAA11555 for ; Wed, 15 Jan 1997 17:29:54 +0100 (MET) Received: from unknown(192.36.235.11) by argus.Posten.SE via smap (V1.3) id sma011552; Wed Jan 15 17:29:32 1997 Received: from shogun.psab.posten.se by psab.posten.se (4.1/SMI-4.1) id AA16960; Wed, 15 Jan 97 17:30:20 +0100 Received: from bird.psab.posten.se by shogun.psab.posten.se with SMTP (5.65/25-1.0-eef) id AA14386; Wed, 15 Jan 97 17:36:22 +0100 Message-Id: <32DD052B.5F90@psab.posten.se> Date: Wed, 15 Jan 1997 17:26:19 +0100 From: Lars Johansson Organization: PSab X-Mailer: Mozilla 3.0 (Win95; I) Mime-Version: 1.0 To: ietf-pkix@tandem.com Subject: HMAC OID? Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi all, This question actually relates to the SET spec but perhaps someone on this list could answer it for me. Is there an OID for HMAC? In particular HMAC with SHA-1? In the previous version of the SET Specification (Book 2: Programmers Guide) the PANSecret value were just hashed with SHA-1 and the ASN.1 definition of the certificate included the id-sha OID from X9.30. Now, in the latest version, the hash algorithm is instead keyed HMAC (with SHA-1 replacing MD5) but no OIDs are given and the exact coding of the hashvalue is not specified. So, does somebody on this list know of an OID for HMAC with SHA-1? Please let me then know too. Thanks, /Lars Johansson Sweden Post From chandras@loc201.tandem.com Wed Jan 15 14:44:21 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id OAA27289; Wed, 15 Jan 1997 14:44:21 -0800 Received: from mag1.magmacom.com by suntan.tandem.com (8.6.12/suntan5.961027) for id OAA27270; Wed, 15 Jan 1997 14:44:13 -0800 Received: (from mbartel@localhost) by mag1.magmacom.com (8.8.4/8.7.3) id RAA25245 for ietf-pkix@tandem.com; Wed, 15 Jan 1997 17:42:20 -0500 (EST) From: Mark Bartel Message-Id: <199701152242.RAA25245@mag1.magmacom.com> Subject: Sample certificate sites To: ietf-pkix@tandem.com Date: Wed, 15 Jan 1997 17:42:20 -0500 (EST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I've resolved my character set questions (ie. figured out UniversalString, decided to ignore TeletexString) and it all seems to work fine, but I'd like to have certificates created by someone else that contain UniversalStrings to test it on. Just my general level of paranoia. I've tested previously by using certificates from Verisign, in addition to the samples that came with the various tools I use. I'd like to test with certificates from other vendors (not necessarily containing UniversalString values). Where are good sources of sample certificates? - Mark Bartel From chandras@loc201.tandem.com Wed Jan 15 16:22:59 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id QAA11033; Wed, 15 Jan 1997 16:22:59 -0800 Received: from verisign.com by suntan.tandem.com (8.6.12/suntan5.961027) for id QAA11024; Wed, 15 Jan 1997 16:22:57 -0800 Message-Id: <3.0.32.19970115162113.0068b92c@mail> X-Sender: peter@mail X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 15 Jan 1997 16:21:14 -0800 To: Mark Bartel , ietf-pkix@tandem.com From: Peter Williams Subject: Re: Sample certificate sites Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" i think it would be a service to the profiling community if you (as a result of this activity) publish to anonymous accessors a set of certificates which are conformant to the PKIX-1 I-D, which explore some of the more interesting options within that option space, inclduing char sets, length maximums, policy values, std qualifiers, etc, etc. Look at it as good advertising for yourself, or your product/service etc. We found lots of issues (and new business partners) when providing a similar community service for the SET-specified certficates. Peter. At 05:42 PM 1/15/97 -0500, Mark Bartel wrote: >I've resolved my character set questions (ie. figured out >UniversalString, decided to ignore TeletexString) and it all seems to >work fine, but I'd like to have certificates created by someone else >that contain UniversalStrings to test it on. Just my general level of >paranoia. > >I've tested previously by using certificates from Verisign, in >addition to the samples that came with the various tools I use. I'd >like to test with certificates from other vendors (not necessarily >containing UniversalString values). Where are good sources of sample >certificates? > >- Mark Bartel > > From chandras@loc201.tandem.com Wed Jan 15 20:24:22 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id UAA06842; Wed, 15 Jan 1997 20:24:22 -0800 Received: from cs20.cs.auckland.ac.nz by suntan.tandem.com (8.6.12/suntan5.961027) for id UAA06825; Wed, 15 Jan 1997 20:24:18 -0800 From: Received: from cs26.cs.auckland.ac.nz by cs20.cs.auckland.ac.nz (8.8.3/4.7) id RAA27159; Thu, 16 Jan 1997 17:24:14 +1300 (NZDT) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <85338865315188>; Thu, 16 Jan 1997 17:24:13 (NZDT) To: ietf-pkix@tandem.com Subject: Re: Sample certificate sites 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: Thu, 16 Jan 1997 17:24:13 (NZDT) Message-ID: <85338865315188@cs26.cs.auckland.ac.nz> >i think it would be a service to the profiling community if you (as a result >of this activity) publish to anonymous accessors a set of certificates which >are conformant to the PKIX-1 I-D, which explore some of the more interesting >options within that option space, inclduing char sets, length maximums, policy >values, std qualifiers, etc, etc. I've looked at doing that as part of my X.509 style guide, http://www.cs.auckland.ac.nz/pgut001/x509guide.txt, however all I've got is all of the more conventional certs (I've got one which mixes BER and DER, but that's about as far as it goes, so I never went any further than adding a list and saying "Can people send me any strange certs they find". The response to date has been underwhelming). If anyone has anything unusual, could you please send them to me and I'll include them in the guide. Peter. From chandras@loc201.tandem.com Wed Jan 15 23:36:53 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id XAA20672; Wed, 15 Jan 1997 23:36:53 -0800 Received: from internet-gateway.zurich.ibm.com by suntan.tandem.com (8.6.12/suntan5.961027) for id XAA20665; Wed, 15 Jan 1997 23:36:50 -0800 Received: from emme.zurich.ibm.com (emme.zurich.ibm.com [9.4.9.235]) by internet-gateway.zurich.ibm.com (AIX4.2/UCB 8.7/8.7) with SMTP id IAA20510 for ; Thu, 16 Jan 1997 08:36:02 +0100 (MET) Received: from notesmta.zurich.ibm.com by emme.zurich.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA43750 from ; Thu, 16 Jan 1997 08:36:16 +0100 Received: by notesmta.zurich.ibm.com(Lotus SMTP MTA Release 1.0.1) id C1256421.0029B365 ; Thu, 16 Jan 1997 08:35:29 +0200 X-Lotus-Fromdomain: ZURICH From: "Carl Binding" To: ietf-pkix@tandem.com Message-Id: <41256421:00297ABE.00@notesmta.zurich.ibm.com> Date: Thu, 16 Jan 1997 08:35:53 +0200 Subject: Re: Sample certificate sites Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii It certainly would be great to have a repository of "reference" X.509 certificates.... As an aside: does anybody know how to "read" the Netscape certificate "db" used by Navigator? There are few, albeit simple, test certificates right there. Any pointers into that direction would be appreciated. Carl Binding From chandras@loc201.tandem.com Thu Jan 16 02:59:25 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id CAA02704; Thu, 16 Jan 1997 02:59:25 -0800 Received: from cs20.cs.auckland.ac.nz by suntan.tandem.com (8.6.12/suntan5.961027) for id CAA02701; Thu, 16 Jan 1997 02:59:23 -0800 From: Received: from cs26.cs.auckland.ac.nz by cs20.cs.auckland.ac.nz (8.8.3/4.7) id XAA16743; Thu, 16 Jan 1997 23:59:19 +1300 (NZDT) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <85341235916035>; Thu, 16 Jan 1997 23:59:19 (NZDT) To: ietf-pkix@tandem.com Subject: Re: Sample certificate sites 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: Thu, 16 Jan 1997 23:59:19 (NZDT) Message-ID: <85341235916035@cs26.cs.auckland.ac.nz> >I've looked at doing that as part of my X.509 style guide, >http://www.cs.auckland.ac.nz/pgut001/x509guide.txt, This URL isn't quite right, something in this mailer is eating tildes and got the one before the 'p'. The correct URL is http://www.cs.auckland.ac.nz/~pgut001/x509guide.txt (I hope it works this time). Sorry about the confusion. Peter. From chandras@loc201.tandem.com Thu Jan 16 20:50:32 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id UAA26225; Thu, 16 Jan 1997 20:50:32 -0800 Received: from mag1.magmacom.com by suntan.tandem.com (8.6.12/suntan5.961027) for id UAA26222; Thu, 16 Jan 1997 20:50:31 -0800 Received: from dyn193.magmacom.com (dyn193.magmacom.com [205.250.113.193]) by mag1.magmacom.com (8.8.4/8.7.3) with SMTP id XAB28166 for ; Thu, 16 Jan 1997 23:49:43 -0500 (EST) Received: by dyn193.magmacom.com with Microsoft Mail id <01BC0408.3E267B10@dyn193.magmacom.com>; Thu, 16 Jan 1997 23:51:50 -0500 Message-ID: <01BC0408.3E267B10@dyn193.magmacom.com> From: Mark Bartel To: "'ietf-pkix@tandem.com'" Subject: RE: Sample certificate sites Date: Thu, 16 Jan 1997 23:51:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, I've gotten lots of pointers to various places to get sample = certificates, and have run a lot of them through my code (successfully). = Unfortunately, I still couldn't find any with UniversalString values. = The closest I came was managing to get the demo at http://www.xcert.com = to generate certificates containing TeletexString values; Verisign won't = even do that.=20 And I've tried importing my certificates into MS Internet Explorer 3.01, = and the UniversalString certificates do not work (MSIE can't display = them). Peter (Gutmann), you said (in your X.509 style guide) that = Microsoft generates certificates with UniversalString values, so = presumably MSIE will read such and I must assume that I've done = something wrong. I had figured that if Microsoft had a product that = generated such certificates, it would be easy to find examples, but I've = failed to dig any up. >From X.690: 8.20.7 For the "UniversalString" type, the octet string shall contain = the octets specified in ISO/IEC 10646-1, using the 4-octet canonical = form (see 14.2 of ISO/IEC 10646-1). Control functions and signatures = shall not be used. Does anybody know what this means? Could someone quote the above = section 14.2? I've assumed that 4-octet canonical form means 4-bytes, = big endian, per character, but that's just a guess. I'm hoping that = MSIE just doesn't work with UniversalString. As an example, I'd encode "AB" as 1C 08 00 00 00 41 00 00 00 42 (I also tried running my UniversalString certificates through a few = other programs; SSLeay identified the UniversalString values but didn't = try to parse them, and Certificate Viewer couldn't read the certificate = at all. I couldn't figure out how to get Netscape to look at the = certificates as such.) - Mark Bartel From chandras@loc201.tandem.com Fri Jan 17 02:00:54 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id CAA15163; Fri, 17 Jan 1997 02:00:54 -0800 Received: from argus.Posten.SE by suntan.tandem.com (8.6.12/suntan5.961027) for id CAA15159; Fri, 17 Jan 1997 02:00:51 -0800 Received: (from smap@localhost) by argus.Posten.SE (8.7.3/8.7.3) id LAA25388 for ; Fri, 17 Jan 1997 11:00:17 +0100 (MET) Received: from unknown(192.36.235.11) by argus.Posten.SE via smap (V1.3) id sma025382; Fri Jan 17 10:59:49 1997 Received: from shogun.psab.posten.se by psab.posten.se (4.1/SMI-4.1) id AA21065; Fri, 17 Jan 97 11:00:39 +0100 Received: from bird.psab.posten.se by shogun.psab.posten.se with SMTP (5.65/25-1.0-eef) id AA13405; Fri, 17 Jan 97 11:08:11 +0100 Message-Id: <32DF4CD1.630F@psab.posten.se> Date: Fri, 17 Jan 1997 10:56:33 +0100 From: Lars Johansson Organization: PSab X-Mailer: Mozilla 3.0 (Win95; I) Mime-Version: 1.0 To: ietf-pkix@tandem.com Subject: Interpretation of KeyUsage? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, This is a topic that has confused us a great deal in the swedish SEIS project (http://www.seis.se). One goal of SEIS is to agree on a standard of electronic ID-cards (i.e. smart cards primarly used for identification). The electronic ID-card shall be capable of performing the following cryptographic functions (all based on RSA): 1. Authentication ("signing" a random challenge). 2. Computing digital signatures (e.g. signing legal contracts). 3. Encryption For each function there is a separate key with a corresponding certificate. These three certificates must therefore include the X.509v3 extension keyUsage. It's quite clear that the encryption key can have the usage 'keyEncipherment' but what about the other two? After reading the X.509 DAM over and over (and even calling Warwick Ford) it was decided that the key we use for (what we call) digital signatures (function no. 2) would be 'nonRepudiation' in the X.509 terminology. This left us with the KeyUsage 'digitalSignatures' for the key we use for authentication. Although I think this interpretation of X.509v3 is correct it still worries me somehow. As we interpret the term authentication, it means encrypting some random data with your private key. Since the protocol uses random data, this type of signature mustn't be mixed with the ones performed on legally binding contracts (supporting non-repudiation). Now I'd like to know for what other purposes are people using keys with the X.509v3 extension 'digitalSignature'? As I see it there is a potential risk that the intepretation differs from country to country or even from application to application. Suppose that one service provider on the Internet accepts a digitally signed payment order using the extension 'digitalSignature' in the corresponding certificate. Do you all see the potential risk of fraud to our happily unworried swedish inhabitants that use their electronic ID-cards for authetication puposes? Please comment! /Lars Johansson Sweden Post From chandras@loc201.tandem.com Fri Jan 17 06:56:05 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id GAA04978; Fri, 17 Jan 1997 06:56:05 -0800 Received: from clbull.frcl.bull.fr by suntan.tandem.com (8.6.12/suntan5.961027) for id GAA04962; Fri, 17 Jan 1997 06:55:54 -0800 Received: from emsc.frcl.bull.fr (emsc.frcl.bull.fr [129.182.42.100]) by clbull.frcl.bull.fr (8.7.5/8.7.3) with SMTP id PAA67497; Fri, 17 Jan 1997 15:52:33 +0100 Received: from dese22.frcl.bull.fr by emsc.frcl.bull.fr (AIX 3.2/UCB 5.64/4.03) id AA29779; Fri, 17 Jan 1997 15:44:17 +0100 Message-Id: <32E01167.1024@frcl.bull.fr> Date: Fri, 17 Jan 1997 15:55:19 -0800 From: Denis Pinkas Reply-To: D.Pinkas@frcl.bull.fr Organization: Bull X-Mailer: Mozilla 3.0 (Win16; I) Mime-Version: 1.0 To: Lars Johansson Cc: ietf-pkix@tandem.com Subject: Re: Interpretation of KeyUsage? References: <32DF4CD1.630F@psab.posten.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lars Johansson wrote: > > Hi all, > > This is a topic that has confused us a great deal > in the swedish SEIS project (http://www.seis.se). > One goal of SEIS is to agree on a standard of > electronic ID-cards (i.e. smart cards primarly > used for identification). The electronic ID-card > shall be capable of performing the following > cryptographic functions (all based on RSA): > > 1. Authentication ("signing" a random challenge). > > 2. Computing digital signatures (e.g. signing > legal contracts). > > 3. Encryption > > For each function there is a separate key with a > corresponding certificate. These three certificates > must therefore include the X.509v3 extension keyUsage. > > It's quite clear that the encryption key can have the > usage 'keyEncipherment' but what about the other two? > > After reading the X.509 DAM over and over (and even > calling Warwick Ford) it was decided that the key we > use for (what we call) digital signatures (function no. 2) > would be 'nonRepudiation' in the X.509 terminology. No. This would be wrong. Non repudiation, as you point out later on, is legally binding people. A digital signature is just a mechanism that can be used for providing (and I am using there the ISO 7498-2 terminology) data origin authentication with integrity, or entity authentication. When used in conjonction with other information, like a counter-signature from a Time Stamping Authority, a digital signature can also provide non repudiation. The difference is introduced between "digital signature" and "non repudiation" so that if you use a key with a key usage "digital signature" then it is not intended to legally bind you. The key is restricted to authentication purposes (in the large sense). In other words, the digital signature may convince some one; but cannot be used, according to a security policy, to convince anyone. On the contrary the a key marked as non-repudiation is intended to bind you, once again, according to a security policy. > This left us with the KeyUsage 'digitalSignatures' > for the key we use for authentication. Although I think > this interpretation of X.509v3 is correct it still > worries me somehow. As we interpret the term authentication, > it means encrypting some random data with your private key. > Since the protocol uses random data, this type of signature > mustn't be mixed with the ones performed on legally binding > contracts (supporting non-repudiation). > > Now I'd like to know for what other purposes are people > using keys with the X.509v3 extension 'digitalSignature'? > As I see it there is a potential risk that the intepretation > differs from country to country or even from application to > application. > Suppose that one service provider on the Internet accepts > a digitally signed payment order using the extension > 'digitalSignature' in the corresponding certificate. The Internet service provider can do it, in order to be convinced itself, but it would not be able to use the received digital signature to convince a third party, like a judge. > Do you all see the potential risk of fraud to our happily > unworried swedish inhabitants that use their electronic > ID-cards for authentication purposes? > > Please comment! > /Lars Johansson > Sweden Post I take this opportunity to present my best wishes for the new year to the happily unworried swedish inhabitants that will use electronic ID-cards for authentication purposes. :-) Regards, Denis -- Denis Pinkas Bull S.A. E-mail : D.Pinkas@frcl.bull.fr Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 From chandras@loc201.tandem.com Fri Jan 17 07:34:26 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id HAA08685; Fri, 17 Jan 1997 07:34:26 -0800 Received: from argus.Posten.SE by suntan.tandem.com (8.6.12/suntan5.961027) for id HAA08673; Fri, 17 Jan 1997 07:34:23 -0800 Received: (from smap@localhost) by argus.Posten.SE (8.7.3/8.7.3) id QAA00358; Fri, 17 Jan 1997 16:32:53 +0100 (MET) Received: from unknown(192.36.235.11) by argus.Posten.SE via smap (V1.3) id sma000354; Fri Jan 17 16:32:45 1997 Received: from shogun.psab.posten.se by psab.posten.se (4.1/SMI-4.1) id AA07408; Fri, 17 Jan 97 16:33:21 +0100 Received: from bird.psab.posten.se by shogun.psab.posten.se with SMTP (5.65/25-1.0-eef) id AA26860; Fri, 17 Jan 97 16:41:02 +0100 Message-Id: <32DF9AC9.19FB@psab.posten.se> Date: Fri, 17 Jan 1997 16:29:13 +0100 From: Lars Johansson Organization: PSab X-Mailer: Mozilla 3.0 (Win95; I) Mime-Version: 1.0 To: D.Pinkas@frcl.bull.fr Cc: ietf-pkix@tandem.com Subject: Re: Interpretation of KeyUsage? References: <32DF4CD1.630F@psab.posten.se> <32E01167.1024@frcl.bull.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Denis Pinkas wrote: > > Lars Johansson wrote: > > > > After reading the X.509 DAM over and over (and even > > calling Warwick Ford) it was decided that the key we > > use for (what we call) digital signatures (function no. 2) > > would be 'nonRepudiation' in the X.509 terminology. > > No. This would be wrong. Non repudiation, as you point out later on, is > legally binding people. A digital signature is just a mechanism that > can be used for providing (and I am using there the ISO 7498-2 > terminology) data origin authentication with integrity, or entity > authentication. When used in conjonction with other information, like a > counter-signature from a Time Stamping Authority, a digital signature > can also provide non repudiation. Non repudiation of origin can also be achieved when the key is securely stored in a smart card and can only be accessed after a correct presentation of the PIN code. This is how our 'nonRepudiation'-key is used. > The difference is introduced between "digital signature" and "non > repudiation" so that if you use a key with a key usage "digital > signature" then it is not intended to legally bind you. The key is > restricted to authentication purposes (in the large sense). In other > words, the digital signature may convince some one; but cannot be used, > according to a security policy, to convince anyone. > > On the contrary the a key marked as non-repudiation is intended to bind > you, once again, according to a security policy. This is interesting since it is almost exactly the interpretation of keyUsage that we agreed upon. Hopefully everyone has the same interpration(?). This would also mean that e.g. a time-stamping service would use a key with nonRepudiation and let the policy indicate that it may only be used to legally sign time-stamps, not any contents of the time-stamped documents. > > Suppose that one service provider on the Internet accepts > > a digitally signed payment order using the extension > > 'digitalSignature' in the corresponding certificate. > > The Internet service provider can do it, in order to be convinced > itself, but it would not be able to use the received digital signature > to convince a third party, like a judge. ...which is the reason why signatures should be used in the first place, isn't it? No, I get the point. Thanks for clearifying it to me. > I take this opportunity to present my best wishes for the new year to > the happily unworried swedish inhabitants that will use electronic > ID-cards for authentication purposes. :-) Thanks, I'll pass your greeting to them. ;-) Kind regards, /Lars Johansson From chandras@loc201.tandem.com Fri Jan 17 12:44:34 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id MAA20251; Fri, 17 Jan 1997 12:44:34 -0800 Received: from netcomsv.netcom.com by suntan.tandem.com (8.6.12/suntan5.961027) for id MAA20247; Fri, 17 Jan 1997 12:44:32 -0800 Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id KAA28779; Fri, 17 Jan 1997 10:26:26 -0800 Received: from cc:Mail by spysouth.spyrus.com id AA853525045 Fri, 17 Jan 97 10:17:25 Date: Fri, 17 Jan 97 10:17:25 From: "Housley, Russ" Encoding: 2679 Text Message-Id: <9700178535.AA853525045@spysouth.spyrus.com> To: ietf-pkix@tandem.com, Lars Johansson Subject: Re: Interpretation of KeyUsage? My opinion: 1. Authentication is a 'digitalSignature' key. 2. Computing digital signatures (e.g. signing legal contracts) is both a 'digitalSignature' and a 'nonRepudiation' key. 3. Encryption is a 'keyEncipherment' or 'keyAgreement' key depending on the algorithm you use. RSA is a 'keyEncipherment' key. Diffie-Hellman is a 'keyAgreement' key. Russ ______________________________ Reply Separator _________________________________ Subject: Interpretation of KeyUsage? Author: Lars Johansson at internet Date: 1/17/97 3:06 AM Hi all, This is a topic that has confused us a great deal in the swedish SEIS project (http://www.seis.se). One goal of SEIS is to agree on a standard of electronic ID-cards (i.e. smart cards primarly used for identification). The electronic ID-card shall be capable of performing the following cryptographic functions (all based on RSA): 1. Authentication ("signing" a random challenge). 2. Computing digital signatures (e.g. signing legal contracts). 3. Encryption For each function there is a separate key with a corresponding certificate. These three certificates must therefore include the X.509v3 extension keyUsage. It's quite clear that the encryption key can have the usage 'keyEncipherment' but what about the other two? After reading the X.509 DAM over and over (and even calling Warwick Ford) it was decided that the key we use for (what we call) digital signatures (function no. 2) would be 'nonRepudiation' in the X.509 terminology. This left us with the KeyUsage 'digitalSignatures' for the key we use for authentication. Although I think this interpretation of X.509v3 is correct it still worries me somehow. As we interpret the term authentication, it means encrypting some random data with your private key. Since the protocol uses random data, this type of signature mustn't be mixed with the ones performed on legally binding contracts (supporting non-repudiation). Now I'd like to know for what other purposes are people using keys with the X.509v3 extension 'digitalSignature'? As I see it there is a potential risk that the intepretation differs from country to country or even from application to application. Suppose that one service provider on the Internet accepts a digitally signed payment order using the extension 'digitalSignature' in the corresponding certificate. Do you all see the potential risk of fraud to our happily unworried swedish inhabitants that use their electronic ID-cards for authetication puposes? Please comment! /Lars Johansson Sweden Post From chandras@loc201.tandem.com Mon Jan 20 01:29:24 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id BAA17388; Mon, 20 Jan 1997 01:29:24 -0800 Received: from argus.Posten.SE by suntan.tandem.com (8.6.12/suntan5.961027) for id BAA17381; Mon, 20 Jan 1997 01:29:21 -0800 Received: (from smap@localhost) by argus.Posten.SE (8.7.3/8.7.3) id KAA10790; Mon, 20 Jan 1997 10:28:36 +0100 (MET) Received: from unknown(192.36.235.11) by argus.Posten.SE via smap (V1.3) id sma010783; Mon Jan 20 10:28:05 1997 Received: from shogun.psab.posten.se by psab.posten.se (4.1/SMI-4.1) id AA17467; Mon, 20 Jan 97 10:29:00 +0100 Received: from bird.psab.posten.se by shogun.psab.posten.se with SMTP (5.65/25-1.0-eef) id AA19010; Mon, 20 Jan 97 10:38:40 +0100 Message-Id: <32E339D2.485A@psab.posten.se> Date: Mon, 20 Jan 1997 10:24:34 +0100 From: Lars Johansson Organization: PSab X-Mailer: Mozilla 3.0 (Win95; I) Mime-Version: 1.0 To: "Housley, Russ" Cc: ietf-pkix@tandem.com Subject: Re: Interpretation of KeyUsage? References: <9700178535.AA853525045@spysouth.spyrus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Housley, Russ wrote: > > My opinion: > > 1. Authentication is a 'digitalSignature' key. > > 2. Computing digital signatures (e.g. signing legal contracts) is both a > 'digitalSignature' and a 'nonRepudiation' key. This would be in line with the recommedation I received from Dennis Pinkas. However, I still find it somewhat troublesome. Suppose I want to take part in an authentication protocol with somebody with two keys as described above. Then which key do I pick? Many service providers may decide that a key with nonRepudiation "looks better" since then (they believe that) the other part can't repudiate the authentication protocol. The point is that authentication and non-repudiation keys may never be mixed. This could work with your suggestion as well as long as we're very clear what we mean with these key usages. Perhaps this definition would work: 1. Authentication is a key with keyUsage 'digitalSignature' set and 'nonRepudiation' not set. 2. Computing digital signatures (e.g. signing legal contracts) is a key with both keyUsage 'digitalSignature' and 'nonRepudiation' set. Notice that this definition doesn't differ from yours but it may be clearer. > 3. Encryption is a 'keyEncipherment' or 'keyAgreement' key depending on the > algorithm you use. RSA is a 'keyEncipherment' key. Diffie-Hellman is a > 'keyAgreement' key. We use RSA and have decided to set the key usage to 'keyEncipherment'. However, due to backward compatibility reasons, the SEIS specification also includes the key usage 'keyAgreement'. The meaning of that alludes to a protocol (DASP) defined in the swedish "Allterminal"-project using key-exchange based on RSA. Unfortunately the authentication key is used in this protocol. This is not a good solution but it was a compromise in order to be backward compatible with the "Allterminal" standard. Nevertheless, it's a lot harder to break this scheme than ordinary encryption because, in order to do so, you must attack both the communicating parties. Thanks for your patience and helpful comments! /Lars Johansson > ______________________________ Reply Separator _________________________________ > Subject: Interpretation of KeyUsage? > Author: Lars Johansson at internet > Date: 1/17/97 3:06 AM > > Hi all, > > This is a topic that has confused us a great deal > in the swedish SEIS project (http://www.seis.se). > One goal of SEIS is to agree on a standard of > electronic ID-cards (i.e. smart cards primarly > used for identification). The electronic ID-card > shall be capable of performing the following > cryptographic functions (all based on RSA): > > 1. Authentication ("signing" a random challenge). > > 2. Computing digital signatures (e.g. signing > legal contracts). > > 3. Encryption > > For each function there is a separate key with a > corresponding certificate. These three certificates > must therefore include the X.509v3 extension keyUsage. > > It's quite clear that the encryption key can have the > usage 'keyEncipherment' but what about the other two? > > After reading the X.509 DAM over and over (and even > calling Warwick Ford) it was decided that the key we > use for (what we call) digital signatures (function no. 2) > would be 'nonRepudiation' in the X.509 terminology. > > This left us with the KeyUsage 'digitalSignatures' > for the key we use for authentication. Although I think > this interpretation of X.509v3 is correct it still > worries me somehow. As we interpret the term authentication, > it means encrypting some random data with your private key. > Since the protocol uses random data, this type of signature > mustn't be mixed with the ones performed on legally binding > contracts (supporting non-repudiation). > > Now I'd like to know for what other purposes are people > using keys with the X.509v3 extension 'digitalSignature'? > As I see it there is a potential risk that the intepretation > differs from country to country or even from application to > application. > > Suppose that one service provider on the Internet accepts > a digitally signed payment order using the extension > 'digitalSignature' in the corresponding certificate. > Do you all see the potential risk of fraud to our happily > unworried swedish inhabitants that use their electronic > ID-cards for authetication puposes? > > Please comment! > /Lars Johansson > Sweden Post From chandras@loc201.tandem.com Mon Jan 20 03:06:23 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id DAA23547; Mon, 20 Jan 1997 03:06:23 -0800 Received: from pehtra.e5.ijs.si by suntan.tandem.com (8.6.12/suntan5.961027) for id DAA23541; Mon, 20 Jan 1997 03:06:20 -0800 Received: from [0.0.0.0] by pehtra.e5.ijs.si with SMTP id AA00995 (5.67b/IDA-1.5 for ); Mon, 20 Jan 1997 11:32:17 +0100 Message-Id: <199701201032.AA00995@pehtra.e5.ijs.si> X-Mailer: exmh version 1.6.5 12/11/95 To: chandras@loc201.tandem.com Cc: ietf-pkix@tandem.com, wg-i18n@terena.nl Subject: Questions about character sets and their encodings Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Jan 1997 11:32:15 +0100 From: Borka Jerman-Blazic >I've been searching for resources on the web on character sets for >ASN.1 types, but haven't been able to find what I need. Does anybody >know of such resources? >More specifically, my questions are: > IA5String: I've heard this is just 7-bit ASCII, but is that >true? Yes, IA5String is the same as 7-bit ASCII or ISO IRV 646 with one exception (the old one) instead of dollar sign it could be currency sign. > TeletexString: I understand that one can select different >character sets with escape codes; does anybody have the set of escape >codes and character sets they select? TeleString is mainly T.61 or T.50 (one of them is currently used in Teletex) or its international ISO version ISO 6937. This is 8-bit coding with changable use of a code lenght per character e.g. the accented letter of Latin alphabet are coded with 2 bytes, one for the so called "non-spacing" character (the acent or diacritic sign) and the other for the basic letter. > UniversalString: X.690 says that this is encoded in 4-octet >canonical form, which I would imagine is 4 bytes, big-endian. Also, I >believe that the subset of the 32-bit space with the high 16 bits set >to 0 is equivalent to Unicode. Am I correct in these assumptions? >X.690 says a bunch of things that I don't really understand (probably >because I don't have X.680) about character string types and their >encodings. Also, what is the tag for UniversalString? Does anybody >have examples of certificates with UniversalString values in the >Issuer or Subject? I've heard that Microsoft certificates do, but >when I queried Verisign for Microsoft certificates they didn't. I >couldn't get ahold of any Microsoft products that actually issue >certificates to check that possibility. UniversalString allows all methods of coding e.g. with the ISO 2022 standard which is basic standard for code extension techniques in 7-bit and 8-bit environment you can use any of the registred code tables in the International Register of Coded Character sets. The invocation is done with shift functions and there are 4 of them: Single shift and locked single shift for one characater from the code table and 2 others for invocation of the whole coded charcater set table. Every code table has his registered escape sequence for invocation, thus ISO 10 646 which first Multilingual plane is equal to Unicode has its one escape sequence and thus can be invoced in the UniversalString. The other way of use of different coded character sets in UniversalString is with an announcement mechanisms which are specified in ASN.1 or ISO 8825 and ISO 8824 standard. Every used coded charcater set has his OID. >I know I could probably get the answers by ordering ISO/IEC 10646-1 >and X.680, but from what I can see I'd have to do it snail mail. I'd >rather not. My recommendation is to use ISO 10 646 as this is the only remedy for the mess in the charcater set world. I am very interested in the solutions used by Microsoft. The new version of the X.500 standard allows used of "context" for different attributes which means specification of the used coded charcater set. Without proper spelling of people names and addresses there will be no value of the certificates as the names will differ from the names on the documents e.g. on the credit cards. Regards, Borka Jerman-blazic Chair, WG-I18N@TERENA.NL TERENA is European Association of the Research and Academic Networks From chandras@loc201.tandem.com Mon Jan 20 14:39:59 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id OAA05831; Mon, 20 Jan 1997 14:39:59 -0800 Received: from mailsrvr.az05.bull.com by suntan.tandem.com (8.6.12/suntan5.961027) for id OAA05815; Mon, 20 Jan 1997 14:39:56 -0800 Received: from smtplink.az05.bull.com (smtplink.az05.bull.com [141.112.29.62]) by mailsrvr.az05.bull.com (8.6.8.1/8.6.6) with SMTP id PAA07299; Mon, 20 Jan 1997 15:21:22 -0700 Received: from ccMail by smtplink.az05.bull.com (IMA Internet Exchange 2.02 Enterprise) id 2E3EFB80; Mon, 20 Jan 97 15:20:40 -0700 Mime-Version: 1.0 Date: Mon, 20 Jan 1997 15:18:11 -0700 Message-ID: <2E3EFB80.@smtplink.az05.bull.com> From: H.Kesterson@az05.bull.com (KESTERSON.H) Subject: Re: Questions about character sets and their encodings To: Borka Jerman-Blazic , chandras@loc201.tandem.com Cc: ietf-pkix@tandem.com, wg-i18n@terena.nl Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part asn1. also defines the type BMPString which is the Basic Multilingual Plane character set. This is the set of 16 bit character encodings that is "supposedly" equivalent to the unicode set (the intent was to make unicode and BMP identical - i believe they succeeded but i never verified it by checking the final version of the standard). the advantage of this asn.1 type is that it uses the asn.1 tage to indicate the selection from the rather large UniversalString set of character encodings. x.500 permits the use of BMPString in a distinguished name. therefore, the standard permits this characterset in a certificate, subject to profiles of course although 646 provides greater interoperability, one should consider national language and localization requirements for your product. the BMP set (Unicode) from 10646 is the best character set to address such requirements. the tag value for UniversalString is 28; BMPString is 30. The asn.1 standard does not recommend the use of UniversalString without constraints. you can order and retrieve itu recommendations electronically. see http:// www.itu.ch/POD/itut-123.html. this can help you get the asn.1 documents. iso does not offer such a service; however, i suspect that you would want a paper copy of 10646 since display of the glyphs from an electronic text would be a challenge for the font capability of most systems. hoyt _______________________________________________________________________________ Subject: Questions about character sets and their encodings From: Borka Jerman-Blazic at az05-smtp Date: 1/20/97 11:32 >I've been searching for resources on the web on character sets for >ASN.1 types, but haven't been able to find what I need. Does anybody >know of such resources? >More specifically, my questions are: > IA5String: I've heard this is just 7-bit ASCII, but is that >true? Yes, IA5String is the same as 7-bit ASCII or ISO IRV 646 with one exception (the old one) instead of dollar sign it could be currency sign. > TeletexString: I understand that one can select different >character sets with escape codes; does anybody have the set of escape >codes and character sets they select? TeleString is mainly T.61 or T.50 (one of them is currently used in Teletex) or its international ISO version ISO 6937. This is 8-bit coding with changable use of a code lenght per character e.g. the accented letter of Latin alphabet are coded with 2 bytes, one for the so called "non-spacing" character (the acent or diacritic sign) and the other for the basic letter. > UniversalString: X.690 says that this is encoded in 4-octet >canonical form, which I would imagine is 4 bytes, big-endian. Also, I >believe that the subset of the 32-bit space with the high 16 bits set >to 0 is equivalent to Unicode. Am I correct in these assumptions? >X.690 says a bunch of things that I don't really understand (probably >because I don't have X.680) about character string types and their >encodings. Also, what is the tag for UniversalString? Does anybody >have examples of certificates with UniversalString values in the >Issuer or Subject? I've heard that Microsoft certificates do, but >when I queried Verisign for Microsoft certificates they didn't. I >couldn't get ahold of any Microsoft products that actually issue >certificates to check that possibility. UniversalString allows all methods of coding e.g. with the ISO 2022 standard which is basic standard for code extension techniques in 7-bit and 8-bit environment you can use any of the registred code tables in the International Register of Coded Character sets. The invocation is done with shift functions and there are 4 of them: Single shift and locked single shift for one characater from the code table and 2 others for invocation of the whole coded charcater set table. Every code table has his registered escape sequence for invocation, thus ISO 10 646 which first Multilingual plane is equal to Unicode has its one escape sequence and thus can be invoced in the UniversalString. The other way of use of different coded character sets in UniversalString is with an announcement mechanisms which are specified in ASN.1 or ISO 8825 and ISO 8824 standard. Every used coded charcater set has his OID. >I know I could probably get the answers by ordering ISO/IEC 10646-1 >and X.680, but from what I can see I'd have to do it snail mail. I'd >rather not. My recommendation is to use ISO 10 646 as this is the only remedy for the mess in the charcater set world. I am very interested in the solutions used by Microsoft. The new version of the X.500 standard allows used of "context" for different attributes which means specification of the used coded charcater set. Without proper spelling of people names and addresses there will be no value of the certificates as the names will differ from the names on the documents e.g. on the credit cards. Regards, Borka Jerman-blazic Chair, WG-I18N@TERENA.NL TERENA is European Association of the Research and Academic Networks From chandras@loc201.tandem.com Mon Jan 20 14:08:24 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id OAA01669; Mon, 20 Jan 1997 14:08:24 -0800 Received: from mag1.magmacom.com by suntan.tandem.com (8.6.12/suntan5.961027) for id OAA01659; Mon, 20 Jan 1997 14:08:20 -0800 Received: (from mbartel@localhost) by mag1.magmacom.com (8.8.4/8.7.3) id RAA08197; Mon, 20 Jan 1997 17:04:46 -0500 (EST) From: Mark Bartel Message-Id: <199701202204.RAA08197@mag1.magmacom.com> Subject: Re: Questions about character sets and their encodings To: borka@e5.ijs.si (Borka Jerman-Blazic) Date: Mon, 20 Jan 1997 17:04:45 -0500 (EST) Cc: chandras@loc201.tandem.com, ietf-pkix@tandem.com, wg-i18n@terena.nl In-Reply-To: <199701201032.AA00995@pehtra.e5.ijs.si> from "Borka Jerman-Blazic" at Jan 20, 97 11:32:15 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Borka, It sounds to me like you are refering (in the quoted text at the end of this message) to the unrestricted string type, rather than the UniversalString type. X.690 describes a rather complicated structure (in 8.21.6) for that type that includes the object identifiers and such. But X.690 says: 8.20.5 For restricted character string apart from UniversalString and BMPString the octet string shall contain the octets specified in ISO 2022 for encodings in an 8-bit environment, using the escape sequence and character codings registered in accordance with ISO 2375. This would seem to imply that UniversalString and BMPString don't use escape sequences, since escape sequences aren't mentioned anywhere else in reference to UniversalString. Which would make sense, because it seems to me that the whole point of UniversalString is to be a "flat" character set, where you don't have to worry about escape sequences and modes. This seems to be confirmed by the fact that UniversalString doesn't appear in "Table 3 - Use of escape sequences", and also by 8.20.7 For the "UniversalString" type, the octet string shall contain the octets specified in ISO/IEC 10646-1, using the 4-octet canonical form (see 14.2 of ISO/IEC 10646-1). Control functions and signatures shall not be used. Since all values in the character set can be reproduced in 4 octets, there is no reason for escape codes. I think my current encoding is correct (nobody said my example was wrong) but I'd like to see other examples of UniversalString encodings (not necessarily even in certificates!), both because I'm paranoid :) and because nobody has indicated that they believe my encoding to be correct. Knowing this list, I wouldn't be surprised if it was just that the few people who actually know (at this point in time it's kind of an obscure issue) just were too busy to respond. But up until now, I haven't been able to find a single example of a UniversalString DER or BER encoding, in or out of a certificate. Arrrggghhh! Isn't *anybody* using UniversalString? Is anybody reading this thread? - Mark Bartel > > UniversalString: X.690 says that this is encoded in 4-octet > >canonical form, which I would imagine is 4 bytes, big-endian. Also, I > >believe that the subset of the 32-bit space with the high 16 bits set > >to 0 is equivalent to Unicode. Am I correct in these assumptions? > >X.690 says a bunch of things that I don't really understand (probably > >because I don't have X.680) about character string types and their > >encodings. Also, what is the tag for UniversalString? Does anybody > >have examples of certificates with UniversalString values in the > >Issuer or Subject? I've heard that Microsoft certificates do, but > >when I queried Verisign for Microsoft certificates they didn't. I > >couldn't get ahold of any Microsoft products that actually issue > >certificates to check that possibility. > > UniversalString allows all methods of coding e.g. with the ISO 2022 > standard which is basic standard for code extension techniques in > 7-bit and 8-bit environment you can use any of the registred code tables > in the International Register of Coded Character sets. The invocation > is done with shift functions and there are 4 of them: Single shift and > locked single shift for one characater from the code table and > 2 others for invocation of the whole coded charcater set table. Every code > table has his registered escape sequence for invocation, thus ISO > 10 646 which first Multilingual plane is equal to Unicode has its > one escape sequence and thus can be invoced in the UniversalString. > > The other way of use > of different coded character sets in UniversalString is > with an announcement mechanisms which > are specified in ASN.1 or ISO 8825 and ISO 8824 standard. Every used > coded charcater set has his OID. > > > >I know I could probably get the answers by ordering ISO/IEC 10646-1 > >and X.680, but from what I can see I'd have to do it snail mail. I'd > >rather not. > > My recommendation is to use ISO 10 646 as this is the only remedy for the > mess in the charcater set world. > > > I am very interested in the solutions used by Microsoft. The > new version of the X.500 standard allows used of "context" for different > attributes which means specification of the used coded charcater set. > Without proper spelling of people names and addresses there will be no > value of the certificates as the names will differ from the > names on the documents e.g. on the credit cards. > > > Regards, > > > Borka Jerman-blazic > Chair, WG-I18N@TERENA.NL > > TERENA is European Association of the Research and Academic Networks > > > > > From chandras@loc201.tandem.com Mon Jan 20 23:44:06 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id XAA22287; Mon, 20 Jan 1997 23:44:06 -0800 Received: from pehtra.e5.ijs.si by suntan.tandem.com (8.6.12/suntan5.961027) for id XAA22284; Mon, 20 Jan 1997 23:44:02 -0800 Received: from [0.0.0.0] by pehtra.e5.ijs.si with SMTP id AA02979 (5.67b/IDA-1.5 for ); Tue, 21 Jan 1997 08:11:38 +0100 Message-Id: <199701210711.AA02979@pehtra.e5.ijs.si> X-Mailer: exmh version 1.6.5 12/11/95 To: Mark Bartel Cc: borka@e5.ijs.si (Borka Jerman-Blazic), chandras@loc201.tandem.com, ietf-pkix@tandem.com, wg-i18n@terena.nl Subject: Re: Questions about character sets and their encodings In-Reply-To: Your message of "Mon, 20 Jan 1997 17:04:45 EST." <199701202204.RAA08197@mag1.magmacom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Jan 1997 08:11:32 +0100 From: Borka Jerman-Blazic Mark, You are right, I did a mistake taking UniversalString for GeneralString (which allows all 2022 coding and announcements). Obviously UniversalString is rserved for BMP of ISO 10 646, canonical form - 4 bytes per charcater. What is not clear here is the 4 bytes, which are used when you specify the group, the plane and the row and cell of every charcater. If it is just BMP ISO 10 646 1.1 then you do not need the first two bytes. Using them just take more space and bandwith. It will be intersting to see who else has done the same implementation as you. However. it is true that very soon we will have another plane which will code all ideographic scripts. That was solution recently endorsed by WG 2 of ISO JTC1 SC2. Regards, Borka > Borka, > > It sounds to me like you are refering (in the quoted text at the end > of this message) to the unrestricted string type, rather than the > UniversalString type. X.690 describes a rather complicated structure > (in 8.21.6) for that type that includes the object identifiers and > such. But X.690 says: > > 8.20.5 For restricted character string apart from UniversalString and > BMPString the octet string shall contain the octets specified in ISO > 2022 for encodings in an 8-bit environment, using the escape sequence > and character codings registered in accordance with ISO 2375. > > This would seem to imply that UniversalString and BMPString don't use > escape sequences, since escape sequences aren't mentioned anywhere > else in reference to UniversalString. Which would make sense, because > it seems to me that the whole point of UniversalString is to be a > "flat" character set, where you don't have to worry about escape > sequences and modes. This seems to be confirmed by the fact that > UniversalString doesn't appear in "Table 3 - Use of escape sequences", > and also by > > 8.20.7 For the "UniversalString" type, the octet string shall contain > the octets specified in ISO/IEC 10646-1, using the 4-octet canonical > form (see 14.2 of ISO/IEC 10646-1). Control functions and signatures > shall not be used. > > Since all values in the character set can be reproduced in 4 octets, > there is no reason for escape codes. > > I think my current encoding is correct (nobody said my example was > wrong) but I'd like to see other examples of UniversalString encodings > (not necessarily even in certificates!), both because I'm paranoid :) > and because nobody has indicated that they believe my encoding to be > correct. Knowing this list, I wouldn't be surprised if it was just > that the few people who actually know (at this point in time it's kind > of an obscure issue) just were too busy to respond. But up until now, > I haven't been able to find a single example of a UniversalString DER > or BER encoding, in or out of a certificate. Arrrggghhh! Isn't > *anybody* using UniversalString? Is anybody reading this thread? > > - Mark Bartel > From chandras@loc201.tandem.com Tue Jan 21 06:45:34 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id GAA15292; Tue, 21 Jan 1997 06:45:34 -0800 Received: from guardian.guard.ncsc.mil by suntan.tandem.com (8.6.12/suntan5.961027) for id GAA15287; Tue, 21 Jan 1997 06:45:31 -0800 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id JAA00684 for ; Tue, 21 Jan 1997 09:45:05 -0500 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma000681; Tue Jan 21 09:44:48 1997 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id JAA07531 for ; Tue, 21 Jan 1997 09:41:55 -0500 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id JAA17416; Tue, 21 Jan 1997 09:44:30 -0500 Date: Tue, 21 Jan 1997 09:44:30 -0500 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199701211444.JAA17416@argon.ncsc.mil> To: ietf-pkix@tandem.com Subject: Re: Interpretation of KeyUsage? X-Sun-Charset: US-ASCII > From: Lars Johansson > > Housley, Russ wrote: > > > > My opinion: > > > > 1. Authentication is a 'digitalSignature' key. > > > > 2. Computing digital signatures (e.g. signing legal contracts) is both a > > 'digitalSignature' and a 'nonRepudiation' key. > > This would be in line with the recommedation I received from Dennis > Pinkas. However, I still find it somewhat troublesome. Suppose I want > to take part in an authentication protocol with somebody with two keys > as described above. Then which key do I pick? Many service providers > may decide that a key with nonRepudiation "looks better" since then > (they believe that) the other part can't repudiate the authentication > protocol. > > The point is that authentication and non-repudiation keys may never be > mixed. This could work with your suggestion as well as long as we're > very clear what we mean with these key usages. Perhaps this definition > would work: > > 1. Authentication is a key with keyUsage 'digitalSignature' set and > 'nonRepudiation' not set. > > 2. Computing digital signatures (e.g. signing legal contracts) is a key > with both keyUsage 'digitalSignature' and 'nonRepudiation' set. > > Notice that this definition doesn't differ from yours but it may be > clearer. Amendment 1 to ISO 9594-8:1995(E) includes the following text under 12.2.2.3 Key Usage field: "Bits in the KeyUsage type are as follows: a) digitalSignature: for verifying digital signatures that have purposes other than those identified in b), f), or g) below; b) nonRepudiation: for verifying digital signatures used in providing a nonrepudiation service which protects against the signing entity falsely denying some action (excluding certificate or CRL signing, as in f) or g) below); ... f) keyCertSign: ... g) cRLSign: ..." My interpretation of this text is that a key which may be used only for authentication would have 'digitalSignature' set and 'nonRepudiation' not set (as everyone agrees, above). But a key which is to be used only for signing contracts (and not for authentication) would have 'nonRepudiation' set and 'digitalSignature' *not* set. A single key which may used for both purposes would, of course, have both bits set. Lars' definition would disallow the issuance of a single key that could be used for both purposes, so I prefer the current DAM definition as it stands. dpk From chandras@loc201.tandem.com Tue Jan 21 08:25:46 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id IAA24988; Tue, 21 Jan 1997 08:25:46 -0800 Received: from relay1.UU.NET by suntan.tandem.com (8.6.12/suntan5.961027) for id IAA24884; Tue, 21 Jan 1997 08:24:43 -0800 Received: from internet.jetform.com by relay1.UU.NET with SMTP (peer crosschecked as: gateway.jetform.com [207.6.34.2]) id QQbzlx29295; Tue, 21 Jan 1997 11:24:32 -0500 (EST) Received: from [172.16.4.147] ([172.16.4.147]) by internet with SMTP (DuhMail/2.0) id LAA12381; Tue, 21 Jan 1997 11:06:49 -0500 X-Authentication-Warning: internet: Host [172.16.4.147] claimed to be GUERNSEY Received: by GUERNSEY with Microsoft Mail id <01BC078C.C37B60F0@GUERNSEY>; Tue, 21 Jan 1997 11:18:01 -0500 Message-ID: <01BC078C.C37B60F0@GUERNSEY> From: Mark Bartel To: "'Borka Jerman-Blazic'" Cc: "ietf-pkix@tandem.com" Subject: RE: Questions about character sets and their encodings Date: Tue, 21 Jan 1997 11:17:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Borka, There are two ISO 10646-1 types: UniversalString and BMPString. = UniversalString is encoded in "4-octet canonical form," (X.690, 8.20.7) = whatever that is (that's what I'm trying to determine!) and BMPString is = encoded in "2-octet BMP form," (X.690, 8.20.8) whatever that is. I = assume they're encoded as I suggested (in the obvious fashion), but = there doesn't seem to be anybody who can confirm this. I'd rather use = BMPString, but I'm assuming I can't because DirectoryString only gives = the choice of TeletexString, PrintableString, and UniversalString. As an aside, the tag number for UniversalString is 28, for BMPString is = 30, and for the unrestricted type (GeneralString?) is 29. - Mark Bartel -----Original Message----- From: Borka Jerman-Blazic [SMTP:borka@e5.ijs.si] Sent: Tuesday, January 21, 1997 2:12 AM To: Mark Bartel Cc: Borka Jerman-Blazic; chandras@loc201.tandem.com; = ietf-pkix@tandem.com; wg-i18n@terena.nl Subject: Re: Questions about character sets and their encodings=20 Mark, You are right, I did a mistake taking UniversalString for GeneralString (which allows all 2022 coding and announcements). Obviously UniversalString is rserved for BMP of ISO 10 646, canonical = form - 4 bytes per charcater. What is not clear here is the 4 bytes, which = are used when you specify the group, the plane and the row and cell of every charcater. If it is just BMP ISO 10 646 1.1 then you do not = need the first two bytes. Using them just take more space and bandwith. It will be intersting to see who else has done the same implementation as you. However. it is true that very soon we will have another plane which will code all ideographic scripts. That was solution recently endorsed by WG 2 of ISO JTC1 SC2. Regards, Borka > Borka,=20 >=20 > It sounds to me like you are refering (in the quoted text at the end > of this message) to the unrestricted string type, rather than the > UniversalString type. X.690 describes a rather complicated structure > (in 8.21.6) for that type that includes the object identifiers and > such. But X.690 says: >=20 > 8.20.5 For restricted character string apart from UniversalString and > BMPString the octet string shall contain the octets specified in ISO > 2022 for encodings in an 8-bit environment, using the escape sequence > and character codings registered in accordance with ISO 2375. >=20 > This would seem to imply that UniversalString and BMPString don't use > escape sequences, since escape sequences aren't mentioned anywhere > else in reference to UniversalString. Which would make sense, because > it seems to me that the whole point of UniversalString is to be a > "flat" character set, where you don't have to worry about escape > sequences and modes. This seems to be confirmed by the fact that > UniversalString doesn't appear in "Table 3 - Use of escape sequences", > and also by >=20 > 8.20.7 For the "UniversalString" type, the octet string shall contain > the octets specified in ISO/IEC 10646-1, using the 4-octet canonical > form (see 14.2 of ISO/IEC 10646-1). Control functions and signatures > shall not be used. >=20 > Since all values in the character set can be reproduced in 4 octets, > there is no reason for escape codes. >=20 > I think my current encoding is correct (nobody said my example was > wrong) but I'd like to see other examples of UniversalString encodings > (not necessarily even in certificates!), both because I'm paranoid :) > and because nobody has indicated that they believe my encoding to be > correct. Knowing this list, I wouldn't be surprised if it was just > that the few people who actually know (at this point in time it's kind > of an obscure issue) just were too busy to respond. But up until now, > I haven't been able to find a single example of a UniversalString DER > or BER encoding, in or out of a certificate. Arrrggghhh! Isn't > *anybody* using UniversalString? Is anybody reading this thread? >=20 > - Mark Bartel >=20 From chandras@loc201.tandem.com Tue Jan 21 08:24:03 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id IAA24726; Tue, 21 Jan 1997 08:24:03 -0800 Received: from internet.jetform.com by suntan.tandem.com (8.6.12/suntan5.961027) for id IAA24717; Tue, 21 Jan 1997 08:24:00 -0800 Received: from [172.16.4.147] ([172.16.4.147]) by internet with SMTP (DuhMail/2.0) id LAA12148; Tue, 21 Jan 1997 11:06:39 -0500 X-Authentication-Warning: internet: Host [172.16.4.147] claimed to be GUERNSEY Received: by GUERNSEY with Microsoft Mail id <01BC078C.BD729430@GUERNSEY>; Tue, 21 Jan 1997 11:17:51 -0500 Message-ID: <01BC078C.BD729430@GUERNSEY> From: Mark Bartel To: "'H.Kesterson@az05.bull.com'" Cc: "ietf-pkix@tandem.com" Subject: Re: Questions about character sets and their encodings Date: Tue, 21 Jan 1997 11:17:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hoyt, In the version of X.520 that I have, it says (at the start of section 2, = just before 5.1) DirectoryString { INTEGER : maxSize } ::=3D CHOICE { teletexString TeletexString (SIZE (1..maxSize)), printableString PrintableString (SIZE (1..maxSize)), universalString UniversalString (SIZE (1..maxSize)) } This is 1993 version however, has it been revised to include BMPString? = I'd be quite happy to use BMPString if I could. As far as I've heard, = BMP and Unicode are identical, and my products use Unicode internally. And I'm aware of the ITU site, and have gotten several recommendations = from there. However, X.680 and X.681 are not among the recommendations = that are available electronically. I really hate the idea of ordering a = paper copy, and of having to use snail mail, although I suspect I may = break down soon. =20 I don't think I really need ISO/IEC 10646-1, because all I need to know = is what "4-octet canonical form" is (or if I use BMPString, what = "2-octet BMP form" is). I can't imagine that those forms are anything = other than the obvious (four octets, big endian format, or in the case = of BMPString, two octets, big endian) but nobody seems to be able to = confirm this. - Mark Bartel >-----Original Message----- >From: KESTERSON.H [SMTP:H.Kesterson@az05.bull.com] >Sent: Monday, January 20, 1997 5:18 PM >To: Borka Jerman-Blazic; chandras@loc201.tandem.com >Cc: ietf-pkix@tandem.com; wg-i18n@terena.nl >Subject: Re: Questions about character sets and their encodings > >asn1. also defines the type BMPString which is the Basic Multilingual = Plane >character set. This is the set of 16 bit character encodings that is >"supposedly" equivalent to the unicode set (the intent was to make = unicode and >BMP identical - i believe they succeeded but i never verified it by = checking the >final version of the standard). the advantage of this asn.1 type is = that it uses >the asn.1 tage to indicate the selection from the rather large = UniversalString >set of character encodings. x.500 permits the use of BMPString in a >distinguished name. therefore, the standard permits this characterset = in a >certificate, subject to profiles of course >although 646 provides greater interoperability, one should consider = national language=20 >and localization requirements for your product. the BMP set (Unicode) = from 10646=20 >is the best character set to address such requirements. >the tag value for UniversalString is 28; BMPString is 30. The asn.1 = standard does=20 >not recommend the use of UniversalString without constraints. >you can order and retrieve itu recommendations electronically. see = http:// www.itu.ch/POD/itut-123.html.=20 >this can help you get the asn.1 documents. iso does not offer such a = service; however,=20 >i suspect that you would want a paper copy of 10646 since display of = the glyphs=20 >from an electronic text would be a challenge for the font capability of = most systems. >hoyt >________________________________________________________________________= _______ >Subject: Questions about character sets and their encodings >From: Borka Jerman-Blazic at az05-smtp >Date: 1/20/97 11:32 > > > >>I've been searching for resources on the web on character sets for >>ASN.1 types, but haven't been able to find what I need. Does anybody >>know of such resources? > >>More specifically, my questions are: > >> IA5String: I've heard this is just 7-bit ASCII, but is that >>true? > > >Yes, IA5String is the same as 7-bit ASCII or ISO IRV 646 with one = exception (the=20 >old one) instead of dollar sign it could be currency sign. >> TeletexString: I understand that one can select different >>character sets with escape codes; does anybody have the set of escape >>codes and character sets they select? > > >TeleString is mainly T.61 or T.50 (one of them is currently used in = Teletex) or=20 >its international ISO version ISO 6937. This is 8-bit coding with = changable use=20 >of a code lenght per character e.g. the accented letter of Latin = alphabet are coded=20 >with 2 bytes, one for the so called "non-spacing" character (the acent = or diacritic=20 >sign) and the other for the basic letter. >> UniversalString: X.690 says that this is encoded in 4-octet >>canonical form, which I would imagine is 4 bytes, big-endian. Also, I >>believe that the subset of the 32-bit space with the high 16 bits set >>to 0 is equivalent to Unicode. Am I correct in these assumptions? >>X.690 says a bunch of things that I don't really understand (probably >>because I don't have X.680) about character string types and their >>encodings. Also, what is the tag for UniversalString? Does anybody >>have examples of certificates with UniversalString values in the >>Issuer or Subject? I've heard that Microsoft certificates do, but >>when I queried Verisign for Microsoft certificates they didn't. I >>couldn't get ahold of any Microsoft products that actually issue >>certificates to check that possibility. > >UniversalString allows all methods of coding e.g. with the ISO 2022 = standard which=20 >is basic standard for code extension techniques in 7-bit and 8-bit = environment you=20 >can use any of the registred code tables in the International Register = of Coded=20 >Character sets. The invocation is done with shift functions and there = are 4 of them:=20 >Single shift and locked single shift for one characater from the code = table and=20 >2 others for invocation of the whole coded charcater set table. Every = code table=20 >has his registered escape sequence for invocation, thus ISO 10 646 = which first Multilingual=20 >plane is equal to Unicode has its one escape sequence and thus can be = invoced in=20 >the UniversalString. >The other way of use of different coded character sets in = UniversalString is with=20 >an announcement mechanisms which are specified in ASN.1 or ISO 8825 = and ISO 8824=20 >standard. Every used coded charcater set has his OID.=20 > >>I know I could probably get the answers by ordering ISO/IEC 10646-1 >>and X.680, but from what I can see I'd have to do it snail mail. I'd >>rather not. > >My recommendation is to use ISO 10 646 as this is the only remedy for = the mess in=20 >the charcater set world. > >I am very interested in the solutions used by Microsoft. The new = version of the=20 >X.500 standard allows used of "context" for different attributes which = means specification=20 >of the used coded charcater set. Without proper spelling of people = names and addresses=20 >there will be no value of the certificates as the names will differ = from the names=20 >on the documents e.g. on the credit cards. > >Regards, > > >Borka Jerman-blazic >Chair, WG-I18N@TERENA.NL > >TERENA is European Association of the Research and Academic Networks > > > > > =00 From chandras@loc201.tandem.com Tue Jan 21 11:38:36 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id LAA23553; Tue, 21 Jan 1997 11:38:36 -0800 Received: from blinky.ccmail.com by suntan.tandem.com (8.6.12/suntan5.961027) for id LAA23550; Tue, 21 Jan 1997 11:38:34 -0800 Received: from smtpgate.ccmail.com by blinky.ccmail.com (4.1/SMI-4.1) id AA01768; Tue, 21 Jan 97 11:46:07 PST Received: from ccMail by smtpgate.ccmail.com (ccMail Link to SMTP R6.00.01) id AA853875423; Tue, 21 Jan 97 11:37:06 -0800 Message-Id: <9701218538.AA853875423@smtpgate.ccmail.com> X-Mailer: ccMail Link to SMTP R6.00.01 Date: Mon, 20 Jan 97 14:21:45 -0800 From: "Kirpal Khalsa" To: , Cc: , Subject: Re:Questions about character sets and their encodings Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, I'm moderately confused by some of the information being passed regarding T.50. I have a copy dated 09/92 titled International Reference Alphabet (IRA) (Formerly International Alphabet No. 5 or IA5). There were two characters that used to be ambiguous (also referred to as alternate graphic characters): hex23 (2/3) which could be either a pound sign or a number sign and hex24 (2/4) which could be either a dollar sign or the universal currency sign. This is still referenced in Table 2. You can have versions of T.50 that are different from the IRV by selecting non-IRV combinations of 2/3 and 2/4. However the G0 part of the IRV shown in Table 5 no longer has alternates. It specifies 2/3 as the number sign and 2/4 as the dollar sign. So as far as I can tell, the IRV of IA5 is now identical to 7-bit ASCII. Am I missing something? Regards, Kirpal Khalsa Lotus Development >>I've been searching for resources on the web on character sets for >>ASN.1 types, but haven't been able to find what I need. Does anybody >>know of such resources? >>More specifically, my questions are: >> IA5String: I've heard this is just 7-bit ASCII, but is that true? >Yes, IA5String is the same as 7-bit ASCII or ISO IRV 646 with one >exception (the old one) instead of dollar sign it could be >currency sign. From chandras@loc201.tandem.com Tue Jan 21 14:42:26 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id OAA17678; Tue, 21 Jan 1997 14:42:26 -0800 Received: from mailsrvr.az05.bull.com by suntan.tandem.com (8.6.12/suntan5.961027) for id OAA17669; Tue, 21 Jan 1997 14:42:22 -0800 Received: from smtplink.az05.bull.com (smtplink.az05.bull.com [141.112.29.62]) by mailsrvr.az05.bull.com (8.6.8.1/8.6.6) with SMTP id PAA14313; Tue, 21 Jan 1997 15:32:44 -0700 Received: from ccMail by smtplink.az05.bull.com (IMA Internet Exchange 2.02 Enterprise) id 2E543D00; Tue, 21 Jan 97 15:31:44 -0700 Mime-Version: 1.0 Date: Tue, 21 Jan 1997 15:29:45 -0700 Message-ID: <2E543D00.@smtplink.az05.bull.com> From: H.Kesterson@az05.bull.com (KESTERSON.H) Subject: Re[2]: Questions about character sets and their encodings To: Mark Bartel , "'H.Kesterson@az05.bull.com'" Cc: "ietf-pkix@tandem.com" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part salString is somewhat of an irritation to me (a long story that i prefer to tell in person). we added bmpstring via technical corrigendum 1 to x.520. there should also be a change to the conformance statement in 591 here is unformatted text. ;look in v9 of implementor's guide Page 3 Clause 5 Replace the ASN.1 specification with: DirectoryString { INTEGER : maxSize } ::= CHOICE { teletexString TeletexString (SIZE (1..maxSize)), printableString PrintableString (SIZE (1..maxSize)), bmpString BMPString (SIZE (1..maxSize)), universalString UniversalString (SIZE (1..maxSize)) } Replace the final paragraph with: Some implementations of the Directory do not support BMPString or UniversalString, and will not be able to generate, match, or display attributes having such a syntax. Page 15 Clause 6.1.1 In the first paragraph, replace the text "attribute value of type DirectoryString" with: attribute value of type PrintableString, NumericString, TeletexString, BMPString, UniversalString, or DirectoryString Page 15 - 17 Clause 6.1.2 - 6.1.6 In the first paragraph, replace the text "attribute value of type DirectoryString" with: attribute value whose type is one of the ones listed in 6.1.1 _______________________________________________________________________________ Subject: Re: Questions about character sets and their encodings From: Mark Bartel at az05-smtp Date: 1/21/97 11:17 Hoyt, In the version of X.520 that I have, it says (at the start of section 2, just before 5.1) DirectoryString { INTEGER : maxSize } ::= CHOICE { teletexString TeletexString (SIZE (1..maxSize)), printableString PrintableString (SIZE (1..maxSize)), universalString UniversalString (SIZE (1..maxSize)) } This is 1993 version however, has it been revised to include BMPString? I'd be quite happy to use BMPString if I could. As far as I've heard, BMP and Unicode are identical, and my products use Unicode internally. And I'm aware of the ITU site, and have gotten several recommendations from there. However, X.680 and X.681 are not among the recommendations that are available electronically. I really hate the idea of ordering a paper copy, and of having to use snail mail, although I suspect I may break down soon. I don't think I really need ISO/IEC 10646-1, because all I need to know is what "4-octet canonical form" is (or if I use BMPString, what "2-octet BMP form" is). I can't imagine that those forms are anything other than the obvious (four octets, big endian format, or in the case of BMPString, two octets, big endian) but nobody seems to be able to confirm this. - Mark Bartel >-----Original Message----- >From: KESTERSON.H [SMTP:H.Kesterson@az05.bull.com] >Sent: Monday, January 20, 1997 5:18 PM >To: Borka Jerman-Blazic; chandras@loc201.tandem.com >Cc: ietf-pkix@tandem.com; wg-i18n@terena.nl >Subject: Re: Questions about character sets and their encodings > >asn1. also defines the type BMPString which is the Basic Multilingual Plane >character set. This is the set of 16 bit character encodings that is >"supposedly" equivalent to the unicode set (the intent was to make unicode and >BMP identical - i believe they succeeded but i never verified it by checking the >final version of the standard). the advantage of this asn.1 type is that it uses >the asn.1 tage to indicate the selection from the rather large UniversalString >set of character encodings. x.500 permits the use of BMPString in a >distinguished name. therefore, the standard permits this characterset in a >certificate, subject to profiles of course >although 646 provides greater interoperability, one should consider national language >and localization requirements for your product. the BMP set (Unicode) from 10646 >is the best character set to address such requirements. >the tag value for UniversalString is 28; BMPString is 30. The asn.1 standard does >not recommend the use of UniversalString without constraints. >you can order and retrieve itu recommendations electronically. see http:// www.itu.ch/POD/itut-123.html. >this can help you get the asn.1 documents. iso does not offer such a service; however, >i suspect that you would want a paper copy of 10646 since display of the glyphs >from an electronic text would be a challenge for the font capability of most systems. >hoyt >_______________________________________________________________________________ >Subject: Questions about character sets and their encodings >From: Borka Jerman-Blazic at az05-smtp >Date: 1/20/97 11:32 > > > >>I've been searching for resources on the web on character sets for >>ASN.1 types, but haven't been able to find what I need. Does anybody >>know of such resources? > >>More specifically, my questions are: > >> IA5String: I've heard this is just 7-bit ASCII, but is that >>true? > > >Yes, IA5String is the same as 7-bit ASCII or ISO IRV 646 with one exception (the >old one) instead of dollar sign it could be currency sign. >> TeletexString: I understand that one can select different >>character sets with escape codes; does anybody have the set of escape >>codes and character sets they select? > > >TeleString is mainly T.61 or T.50 (one of them is currently used in Teletex) or >its international ISO version ISO 6937. This is 8-bit coding with changable use >of a code lenght per character e.g. the accented letter of Latin alphabet are coded >with 2 bytes, one for the so called "non-spacing" character (the acent or diacritic >sign) and the other for the basic letter. >> UniversalString: X.690 says that this is encoded in 4-octet >>canonical form, which I would imagine is 4 bytes, big-endian. Also, I >>believe that the subset of the 32-bit space with the high 16 bits set >>to 0 is equivalent to Unicode. Am I correct in these assumptions? >>X.690 says a bunch of things that I don't really understand (probably >>because I don't have X.680) about character string types and their >>encodings. Also, what is the tag for UniversalString? Does anybody >>have examples of certificates with UniversalString values in the >>Issuer or Subject? I've heard that Microsoft certificates do, but >>when I queried Verisign for Microsoft certificates they didn't. I >>couldn't get ahold of any Microsoft products that actually issue >>certificates to check that possibility. > >UniversalString allows all methods of coding e.g. with the ISO 2022 standard which >is basic standard for code extension techniques in 7-bit and 8-bit environment you >can use any of the registred code tables in the International Register of Coded >Character sets. The invocation is done with shift functions and there are 4 of them: >Single shift and locked single shift for one characater from the code table and >2 others for invocation of the whole coded charcater set table. Every code table >has his registered escape sequence for invocation, thus ISO 10 646 which first Multilingual >plane is equal to Unicode has its one escape sequence and thus can be invoced in >the UniversalString. >The other way of use of different coded character sets in UniversalString is with >an announcement mechanisms which are specified in ASN.1 or ISO 8825 and ISO 8824 >standard. Every used coded charcater set has his OID. > >>I know I could probably get the answers by ordering ISO/IEC 10646-1 >>and X.680, but from what I can see I'd have to do it snail mail. I'd >>rather not. > >My recommendation is to use ISO 10 646 as this is the only remedy for the mess in >the charcater set world. > >I am very interested in the solutions used by Microsoft. The new version of the >X.500 standard allows used of "context" for different attributes which means specification >of the used coded charcater set. Without proper spelling of people names and addresses >there will be no value of the certificates as the names will differ from the names >on the documents e.g. on the credit cards. > >Regards, > > >Borka Jerman-blazic >Chair, WG-I18N@TERENA.NL > >TERENA is European Association of the Research and Academic Networks > > > > > From chandras@loc201.tandem.com Tue Jan 21 20:09:42 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id UAA23153; Tue, 21 Jan 1997 20:09:42 -0800 Received: from mag1.magmacom.com by suntan.tandem.com (8.6.12/suntan5.961027) for id UAA23142; Tue, 21 Jan 1997 20:09:40 -0800 Received: from dyn180.magmacom.com (dyn180.magmacom.com [205.250.113.180]) by mag1.magmacom.com (8.8.4/8.7.3) with SMTP id XAA28266 for ; Tue, 21 Jan 1997 23:07:15 -0500 (EST) Received: by dyn180.magmacom.com with Microsoft Mail id <01BC07F0.29B9D000@dyn180.magmacom.com>; Tue, 21 Jan 1997 23:09:33 -0500 Message-ID: <01BC07F0.29B9D000@dyn180.magmacom.com> From: Mark Bartel To: "'ietf-pkix@tandem.com'" Subject: Re: Sample certificate sites Date: Tue, 21 Jan 1997 23:07:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here's a short list of places to get certificates. When I have more = time, I'll go through my bookmarks and make a fuller list and also make = available some sample certificates I've created (including ones = containing BMPString and UniversalString values, for which I still = haven't found a source). Verisign: http://www.verisign.com/ (both for creating certificates and = querying for certificates; you can find some old Netscape certificates = here that contain different extensions marked critical) Entrust: http://www.entrust.com/ Xcert: http://www.xcert.com/ Some useful tools are SSLeay (http://psych.psy.uq.oz.au/~ftp/Crypto/), = Certificate Viewer (beta - http://www.iol.ie/~formal), Secude (beta - = http://www.darmstadt.gmd.de/secude), and the Cryptoapi 2.0 beta, all of = which contain certificate viewers. Certificate Viewer also contains = about a dozen sample certificates from all kinds of different places. = The Cryptoapi viewer is the only one that will actually parse BMPString = and UniversalString values. - Mark Bartel=20 From chandras@loc201.tandem.com Tue Jan 21 20:08:16 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id UAA23064; Tue, 21 Jan 1997 20:08:16 -0800 Received: from mag1.magmacom.com by suntan.tandem.com (8.6.12/suntan5.961027) for id UAA23055; Tue, 21 Jan 1997 20:08:09 -0800 Received: from dyn180.magmacom.com (dyn180.magmacom.com [205.250.113.180]) by mag1.magmacom.com (8.8.4/8.7.3) with SMTP id XAA28274 for ; Tue, 21 Jan 1997 23:07:17 -0500 (EST) Received: by dyn180.magmacom.com with Microsoft Mail id <01BC07F0.2B396B20@dyn180.magmacom.com>; Tue, 21 Jan 1997 23:09:35 -0500 Message-ID: <01BC07F0.2B396B20@dyn180.magmacom.com> From: Mark Bartel To: "'ietf-pkix@tandem.com'" Subject: Re: Questions about character sets and their encodings Date: Tue, 21 Jan 1997 23:09:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I finally managed to confirm my implementation of both UniversalString = and BMPString against somebody else, namely the certificate dump program = in the Cryptoapi 2.0 beta. I feel better now. Hoyt, just after I responded to your last message, I found the version = of DirectoryString that you list in the SET specification (it occurred = to me that it would have reasonably up-to-date versions of this stuff). = Furthermore, it states that compliant implementations should only = generate PrintableStrings and BMPStrings; TeletexStrings and = UniversalStrings are forbidden (not just depreciated). So in light of this preference for avoiding TeletexStrings and = UniversalStrings that SET dictates and other people have expressed, my = certificate creator now generates PrintableStrings if possible, = TeletexStrings if the characters are in 7-bit ASCII (no need for SET = compliance in this application), and BMPStrings otherwise. I'll accept = anything, although I won't interpret escape codes in TeletexStrings. (An aside for the general amusement of this list: I finally got a = response out the SCC [Standards Council of Canada] about my request for = ISO/IEC 10646-1; it's only about US$350, and US$12 for each of the four = amendments [translating from Canadian dollars here]. I thought the ITU = was bad.) - Mark Bartel -----Original Message----- From: KESTERSON.H [SMTP:H.Kesterson@az05.bull.com] Sent: Tuesday, January 21, 1997 5:30 PM To: Mark Bartel; 'H.Kesterson@az05.bull.com' Cc: ietf-pkix@tandem.com Subject: Re[2]: Questions about character sets and their encodings salString is somewhat of an irritation to me (a long story that i prefer = to tell in person). we added bmpstring via technical corrigendum 1 to x.520. = there should also be a change to the conformance statement in 591 here is unformatted text. ;look in v9 of implementor's guide Page 3 Clause 5 Replace the ASN.1 specification with: DirectoryString { INTEGER : maxSize } ::=3D CHOICE { teletexString TeletexString (SIZE (1..maxSize)), printableString PrintableString (SIZE (1..maxSize)), bmpString BMPString (SIZE (1..maxSize)), universalString UniversalString (SIZE (1..maxSize)) } Replace the final paragraph with: Some implementations of the Directory do not support BMPString or UniversalString, and will not be able to generate, match, or display = attributes having such a syntax. Page 15 Clause 6.1.1 In the first paragraph, replace the text "attribute value of type DirectoryString" with: attribute value of type PrintableString, NumericString, TeletexString, BMPString, UniversalString, or DirectoryString Page 15 - 17 Clause 6.1.2 - 6.1.6 In the first paragraph, replace the text "attribute value of type DirectoryString" with: attribute value whose type is one of the ones listed in 6.1.1 _________________________________________________________________________= ______ Subject: Re: Questions about character sets and their encodings From: Mark Bartel at az05-smtp Date: 1/21/97 11:17 Hoyt, In the version of X.520 that I have, it says (at the start of section 2, = just before 5.1) DirectoryString { INTEGER : maxSize } ::=3D CHOICE { teletexString TeletexString (SIZE (1..maxSize)), printableString PrintableString (SIZE (1..maxSize)), universalString UniversalString (SIZE (1..maxSize)) } This is 1993 version however, has it been revised to include BMPString? = I'd be quite happy to use BMPString if I could. As far as I've heard, BMP and = Unicode are identical, and my products use Unicode internally. And I'm aware of the ITU site, and have gotten several recommendations = from there. However, X.680 and X.681 are not among the recommendations that = are available electronically. I really hate the idea of ordering a paper = copy, and of having to use snail mail, although I suspect I may break down soon. =20 I don't think I really need ISO/IEC 10646-1, because all I need to know = is what "4-octet canonical form" is (or if I use BMPString, what "2-octet BMP = form" is). I can't imagine that those forms are anything other than the obvious = (four octets, big endian format, or in the case of BMPString, two octets, big = endian) but nobody seems to be able to confirm this. - Mark Bartel >-----Original Message----- >From: KESTERSON.H [SMTP:H.Kesterson@az05.bull.com] >Sent: Monday, January 20, 1997 5:18 PM >To: Borka Jerman-Blazic; chandras@loc201.tandem.com >Cc: ietf-pkix@tandem.com; wg-i18n@terena.nl >Subject: Re: Questions about character sets and their encodings > >asn1. also defines the type BMPString which is the Basic Multilingual = Plane >character set. This is the set of 16 bit character encodings that is >"supposedly" equivalent to the unicode set (the intent was to make = unicode and >BMP identical - i believe they succeeded but i never verified it by = checking the >final version of the standard). the advantage of this asn.1 type is = that it uses >the asn.1 tage to indicate the selection from the rather large = UniversalString >set of character encodings. x.500 permits the use of BMPString in a >distinguished name. therefore, the standard permits this characterset = in a >certificate, subject to profiles of course >although 646 provides greater interoperability, one should consider = national language=20 >and localization requirements for your product. the BMP set (Unicode) = from 10646=20 >is the best character set to address such requirements. >the tag value for UniversalString is 28; BMPString is 30. The asn.1 = standard does=20 >not recommend the use of UniversalString without constraints. >you can order and retrieve itu recommendations electronically. see = http:// www.itu.ch/POD/itut-123.html.=20 >this can help you get the asn.1 documents. iso does not offer such a = service; however,=20 >i suspect that you would want a paper copy of 10646 since display of = the glyphs >from an electronic text would be a challenge for the font capability of = most systems. >hoyt >________________________________________________________________________= _______ >Subject: Questions about character sets and their encodings >From: Borka Jerman-Blazic at az05-smtp >Date: 1/20/97 11:32 > > > >>I've been searching for resources on the web on character sets for >>ASN.1 types, but haven't been able to find what I need. Does anybody >>know of such resources? > >>More specifically, my questions are: > >> IA5String: I've heard this is just 7-bit ASCII, but is that >>true? > > >Yes, IA5String is the same as 7-bit ASCII or ISO IRV 646 with one = exception (the=20 >old one) instead of dollar sign it could be currency sign. >> TeletexString: I understand that one can select different >>character sets with escape codes; does anybody have the set of escape >>codes and character sets they select? > > >TeleString is mainly T.61 or T.50 (one of them is currently used in = Teletex) or >its international ISO version ISO 6937. This is 8-bit coding with = changable use=20 >of a code lenght per character e.g. the accented letter of Latin = alphabet are coded=20 >with 2 bytes, one for the so called "non-spacing" character (the acent = or diacritic=20 >sign) and the other for the basic letter. >> UniversalString: X.690 says that this is encoded in 4-octet >>canonical form, which I would imagine is 4 bytes, big-endian. Also, I >>believe that the subset of the 32-bit space with the high 16 bits set >>to 0 is equivalent to Unicode. Am I correct in these assumptions? >>X.690 says a bunch of things that I don't really understand (probably >>because I don't have X.680) about character string types and their >>encodings. Also, what is the tag for UniversalString? Does anybody >>have examples of certificates with UniversalString values in the >>Issuer or Subject? I've heard that Microsoft certificates do, but >>when I queried Verisign for Microsoft certificates they didn't. I >>couldn't get ahold of any Microsoft products that actually issue >>certificates to check that possibility. > >UniversalString allows all methods of coding e.g. with the ISO 2022 = standard which=20 >is basic standard for code extension techniques in 7-bit and 8-bit = environment you=20 >can use any of the registred code tables in the International Register = of Coded >Character sets. The invocation is done with shift functions and there = are 4 of them:=20 >Single shift and locked single shift for one characater from the code = table and >2 others for invocation of the whole coded charcater set table. Every = code table=20 >has his registered escape sequence for invocation, thus ISO 10 646 = which first Multilingual=20 >plane is equal to Unicode has its one escape sequence and thus can be = invoced in=20 >the UniversalString. >The other way of use of different coded character sets in = UniversalString is with=20 >an announcement mechanisms which are specified in ASN.1 or ISO 8825 = and ISO 8824=20 >standard. Every used coded charcater set has his OID.=20 > >>I know I could probably get the answers by ordering ISO/IEC 10646-1 >>and X.680, but from what I can see I'd have to do it snail mail. I'd >>rather not. > >My recommendation is to use ISO 10 646 as this is the only remedy for = the mess in=20 >the charcater set world. > >I am very interested in the solutions used by Microsoft. The new = version of the >X.500 standard allows used of "context" for different attributes which = means specification=20 >of the used coded charcater set. Without proper spelling of people = names and addresses=20 >there will be no value of the certificates as the names will differ = from the names=20 >on the documents e.g. on the credit cards. > >Regards, > > >Borka Jerman-blazic >Chair, WG-I18N@TERENA.NL > >TERENA is European Association of the Research and Academic Networks > > > > > =00 From chandras@loc201.tandem.com Wed Jan 22 01:07:23 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id BAA11614; Wed, 22 Jan 1997 01:07:23 -0800 Received: from procert.cert.dfn.de by suntan.tandem.com (8.6.12/suntan5.961027) for id BAA11607; Wed, 22 Jan 1997 01:07:18 -0800 Received: from crack.pca.dfn.de (kelm@crack.pca.dfn.de [134.100.14.32]) by procert.cert.dfn.de (8.8.4/8.8.4) with ESMTP id KAA15086; Wed, 22 Jan 1997 10:00:30 +0100 (MET) From: Stefan Kelm Received: (from kelm@localhost) by crack.pca.dfn.de (8.8.4/8.8.4) id KAA16190; Wed, 22 Jan 1997 10:00:28 +0100 (MET) Date: Wed, 22 Jan 1997 10:00:28 +0100 (MET) Message-Id: <199701220900.KAA16190@crack.pca.dfn.de> To: ietf-pkix@tandem.com, mbartel@magmacom.com Subject: Re: Sample certificate sites Reply-To: ietf-pkix@tandem.com X-Sun-Charset: US-ASCII > > Entrust: http://www.entrust.com/ > > Xcert: http://www.xcert.com/ > You might also want to take a look at: http://www.pca.dfn.de/eng/team/ske/pem-dok.html#CA where I collected links to several certification authorities some of which offer sample certificates or testing of certificates, too. Regards, Stefan. ______________________________________________________________________________ Stefan Kelm WWW: http://www.pca.dfn.de/~kelm/ DFN-PCA, University of Hamburg, Vogt-Koelln-Str. 30, 22527 Hamburg (Germany) Phone: +49-40-54942262 / Fax: +49-40-54942241 ["finger kelm@www.pca.dfn.de" to get my PGP key] From chandras@loc201.tandem.com Wed Jan 22 04:03:25 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id EAA21152; Wed, 22 Jan 1997 04:03:25 -0800 Received: from argus.Posten.SE by suntan.tandem.com (8.6.12/suntan5.961027) for id EAA21149; Wed, 22 Jan 1997 04:03:23 -0800 Received: (from smap@localhost) by argus.Posten.SE (8.7.3/8.7.3) id MAA03274; Wed, 22 Jan 1997 12:58:49 +0100 (MET) Received: from unknown(192.36.235.11) by argus.Posten.SE via smap (V1.3) id sma003268; Wed Jan 22 12:58:27 1997 Received: from shogun.psab.posten.se by psab.posten.se (4.1/SMI-4.1) id AA07989; Wed, 22 Jan 97 12:59:23 +0100 Received: from bird.psab.posten.se by shogun.psab.posten.se with SMTP (5.65/25-1.0-eef) id AA18429; Wed, 22 Jan 97 13:10:47 +0100 Message-Id: <32E60008.4585@psab.posten.se> Date: Wed, 22 Jan 1997 12:54:48 +0100 From: Lars Johansson Organization: PSab X-Mailer: Mozilla 3.0 (Win95; I) Mime-Version: 1.0 To: "David P. Kemp" Cc: ietf-pkix@tandem.com Subject: Re: Interpretation of KeyUsage? References: <199701211444.JAA17416@argon.ncsc.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David P. Kemp wrote: > > Amendment 1 to ISO 9594-8:1995(E) includes the following text under > 12.2.2.3 Key Usage field: > > "Bits in the KeyUsage type are as follows: > > a) digitalSignature: for verifying digital signatures that have purposes > other than those identified in b), f), or g) below; > > b) nonRepudiation: for verifying digital signatures used in providing > a nonrepudiation service which protects against the signing entity > falsely denying some action (excluding certificate or CRL signing, > as in f) or g) below); > > ... > > f) keyCertSign: ... > g) cRLSign: ..." > > My interpretation of this text is that a key which may be used only for > authentication would have 'digitalSignature' set and 'nonRepudiation' > not set (as everyone agrees, above). But a key which is to be used > only for signing contracts (and not for authentication) would have > 'nonRepudiation' set and 'digitalSignature' *not* set. > > A single key which may used for both purposes would, of course, > have both bits set. Lars' definition would disallow the issuance of > a single key that could be used for both purposes, so I prefer the > current DAM definition as it stands. David, "My definition" stemmed from the suggestion by Russ Housley. It wasn't my intention to propose a change to the X.509v3 DAM. However, just the fact that we're having this discussion indicates that the text in the DAM under subclause 12.2.2.3 might be too vague. Your interpratation of KeyUsage is the same as what is today stated in the SEIS certificate specification. I think that both yours and Russ' interpretation are ok as long as we agree on one or the other. Not both at the same time. So, what I originally wanted was a key that may _only_ be used for non- repudiation services and should by no means _never_ be used in authentication protocols. If it would, then somebody may ask me to authenticate myself by signing some random data that could be a hash of a text that give that other person permission to withdraw $1000 from my bank account. Since I would only see the "random" hash value, I couldn't have any chance to check what I was actually signing. That's why I wouldn't want to mix my authentication key with my key for non-repudiation. The question is how that should be done according to the X.509v3 DAM. Nevertheless, I understand the point you're making in your comment that it should be _possible_ to indicate that a key may be used for both authentication and non-repudiation. It could be useful for keys issued under a less restrictive security policy, e.g. software keys for www- browsers. So should we then stick to the original definition as you propose? Have we reached a common understanding of this issue? Kind regards, /Lars Johansson From chandras@loc201.tandem.com Wed Jan 22 06:08:40 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id GAA28185; Wed, 22 Jan 1997 06:08:40 -0800 Received: from gateway by suntan.tandem.com (8.6.12/suntan5.961027) for id GAA28180; Wed, 22 Jan 1997 06:08:38 -0800 Received: from ops.soft.gtech.com ([156.24.33.7]) by gateway.gtech.com with SMTP id <46181>; Wed, 22 Jan 1997 08:49:45 -0500 Received: from ccgate by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-X) via SMTP; id AA020616888; Wed, 22 Jan 1997 08:49:29 -0500 Received: from ccMail by ccgate.gtech.com (SMTPLINK V2.11 PreRelease 4) id AA853952435; Wed, 22 Jan 97 08:26:23 EST Date: Wed, 22 Jan 97 08:26:23 EST From: "Administrator" Encoding: 22 Text, 23 Text Message-Id: <9700228539.AA853952435@ccgate.gtech.com> To: ietf-pkix@tandem.com Subject: Message not deliverable > > Entrust: http://www.entrust.com/ > > Xcert: http://www.xcert.com/ > You might also want to take a look at: http://www.pca.dfn.de/eng/team/ske/pem-dok.html#CA where I collected links to several certification authorities some of which offer sample certificates or testing of certificates, too. Regards, Stefan. ______________________________________________________________________________ Stefan Kelm WWW: http://www.pca.dfn.de/~kelm/ DFN-PCA, University of Hamburg, Vogt-Koelln-Str. 30, 22527 Hamburg (Germany) Phone: +49-40-54942262 / Fax: +49-40-54942241 ["finger kelm@www.pca.dfn.de" to get my PGP key] Received: from ops.soft.gtech.com by ccgate.gtech.com (SMTPLINK V2.11 PreRelease 4) ; Wed, 22 Jan 97 07:43:07 EST Return-Path: Received: from gateway by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-X) via SMTP; id AA0029362581; Wed, 22 Jan 1997 06:05:25 -0500 Received: from suntan.tandem.com ([192.216.221.8]) by gateway.gtech.com with SMTP id <46104>; Wed, 22 Jan 1997 05:53:39 -0500 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id BAA11614; Wed, 22 Jan 1997 01:07:23 -0800 Received: from procert.cert.dfn.de by suntan.tandem.com (8.6.12/suntan5.961027) for id BAA11607; Wed, 22 Jan 1997 01:07:18 -0800 Received: from crack.pca.dfn.de (kelm@crack.pca.dfn.de [134.100.14.32]) by procert.cert.dfn.de (8.8.4/8.8.4) with ESMTP id KAA15086; Wed, 22 Jan 1997 10:00:30 +0100 (MET) From: Stefan Kelm Received: (from kelm@localhost) by crack.pca.dfn.de (8.8.4/8.8.4) id KAA16190; Wed, 22 Jan 1997 10:00:28 +0100 (MET) Date: Wed, 22 Jan 1997 10:00:28 +0100 (MET) Message-Id: <199701220900.KAA16190@crack.pca.dfn.de> To: ietf-pkix@tandem.com, mbartel@magmacom.com Subject: Re: Sample certificate sites Reply-To: ietf-pkix@tandem.com X-Sun-Charset: US-ASCII From chandras@loc201.tandem.com Wed Jan 22 06:46:29 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id GAA01516; Wed, 22 Jan 1997 06:46:29 -0800 Received: from guardian.guard.ncsc.mil by suntan.tandem.com (8.6.12/suntan5.961027) for id GAA01509; Wed, 22 Jan 1997 06:46:28 -0800 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id JAA00795 for ; Wed, 22 Jan 1997 09:46:02 -0500 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma000792; Wed Jan 22 09:45:46 1997 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id JAA11647 for ; Wed, 22 Jan 1997 09:41:00 -0500 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id JAA18069; Wed, 22 Jan 1997 09:43:27 -0500 Date: Wed, 22 Jan 1997 09:43:27 -0500 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199701221443.JAA18069@argon.ncsc.mil> To: ietf-pkix@tandem.com Subject: Re: Interpretation of KeyUsage? X-Sun-Charset: US-ASCII > > "My definition" stemmed from the suggestion by Russ Housley. It wasn't > my intention to propose a change to the X.509v3 DAM. However, just the > fact that we're having this discussion indicates that the text in the > DAM under subclause 12.2.2.3 might be too vague. > > [...] > > Have we reached a common understanding of this issue? Yes, I believe so :-). I agree that there could be a little more explanation/clarification (in the form of a "Note --"?) in DAM 1 to X.509, and a lot more in pkix part 1. I understand that Hoyt will consider redline changes to the DAM (ftp://nc-17.ma02.bull.com/pub/OSIdirectory/Certificates/Certificates1Dec...) in March, despite the document being labeled "Final Final draft (1 December)", so perhaps a small clarification is possible. I also agree that it is necessary to be able to issue a non-repudiation key that should not be used for authentication (although it's up to the signer, not the verifier as in most other cases, to enforce that restriction). It's also a good idea for signers never to sign a bare "random" challenge, for the reason you suggest. The signer should always mix in his own random component before signing, and the bank should never honor an e-check of the form "pay $1000 " or " pay $1000", it should verify that the transaction is in the exact form required. From chandras@loc201.tandem.com Thu Jan 23 12:25:49 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id MAA21382; Thu, 23 Jan 1997 12:25:49 -0800 Received: from delhi.nic.in by suntan.tandem.com (8.6.12/suntan5.961027) for id MAA21352; Thu, 23 Jan 1997 12:25:36 -0800 From: To: ietf-pkix@tandem.com Message-ID: <9701240155.AA21763@delhi.nic.in> Report-Version: 2 >To: tandem.com!ietf-pkix Date: Fri Jan 24 01:55:05 1997 Not-Delivered-To: edi!anu due to Message Transfer Agent Congestion (Cannot reach host. Delivery attempts will continue.) X-SMTP-Diagnosis: UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed Content-Type: message Content-Length: 1728 >From smtp Wed Jan 22 18:15 GMT 1997 remote from delhi Received: from tandem.com by delhi.nic.in; Wed, 22 Jan 97 18:15 GMT Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id BAA11614; Wed, 22 Jan 1997 01:07:23 -0800 Received: from procert.cert.dfn.de by suntan.tandem.com (8.6.12/suntan5.961027) for id BAA11607; Wed, 22 Jan 1997 01:07:18 -0800 Received: from crack.pca.dfn.de (kelm@crack.pca.dfn.de [134.100.14.32]) by procert.cert.dfn.de (8.8.4/8.8.4) with ESMTP id KAA15086; Wed, 22 Jan 1997 10:00:30 +0100 (MET) Received: (from kelm@localhost) by crack.pca.dfn.de (8.8.4/8.8.4) id KAA16190; Wed, 22 Jan 1997 10:00:28 +0100 (MET) From: pca.dfn.de!kelm (Stefan Kelm) Date: Wed, 22 Jan 1997 10:00:28 +0100 (MET) Content-Length: 702 Content-Type: text Message-Id: <199701220900.KAA16190@crack.pca.dfn.de> To: tandem.com!ietf-pkix, magmacom.com!mbartel Subject: Re: Sample certificate sites Reply-To: ietf-pkix@tandem.com X-Sun-Charset: US-ASCII > > Entrust: http://www.entrust.com/ > > Xcert: http://www.xcert.com/ > You might also want to take a look at: http://www.pca.dfn.de/eng/team/ske/pem-dok.html#CA where I collected links to several certification authorities some of which offer sample certificates or testing of certificates, too. Regards, Stefan. ______________________________________________________________________________ Stefan Kelm WWW: http://www.pca.dfn.de/~kelm/ DFN-PCA, University of Hamburg, Vogt-Koelln-Str. 30, 22527 Hamburg (Germany) Phone: +49-40-54942262 / Fax: +49-40-54942241 ["finger kelm@www.pca.dfn.de" to get my PGP key] From chandras@loc201.tandem.com Thu Jan 23 18:23:39 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id SAA09862; Thu, 23 Jan 1997 18:23:39 -0800 Received: from mag1.magmacom.com by suntan.tandem.com (8.6.12/suntan5.961027) for id SAA09857; Thu, 23 Jan 1997 18:23:36 -0800 Received: from dyn75.magmacom.com (dyn75.magmacom.com [205.250.113.75]) by mag1.magmacom.com (8.8.5/8.7.3) with SMTP id VAA02374 for ; Thu, 23 Jan 1997 21:20:42 -0500 (EST) Received: by dyn75.magmacom.com with Microsoft Mail id <01BC0973.573F3360@dyn75.magmacom.com>; Thu, 23 Jan 1997 21:21:04 -0500 Message-ID: <01BC0973.573F3360@dyn75.magmacom.com> From: Mark Bartel To: "'ietf-pkix@tandem.com'" Subject: RE: Sample certificate sites Date: Thu, 23 Jan 1997 21:14:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since some people expressed interest, I've posted a couple of sample = certificates at = http://www.magmacom.com/~mbartel/iso/certificates/samples/sample_certific= ates.html, with the intention to put up a few more weird ones later, as = well as "normal" ones with different algorithms. These are all = certificates that I've generated using the default configuration (well, = MD2 is not the default hash algorithm). The notable characteristics of = the certificates are that they contain subject and issuer unique = identifiers, use the basic constraints extension (marked critical), and = one of them has a BMPString value in the subject name. Peter, feel free = to use these as examples in your style guide. I've found that MSIE chokes on the unique identifiers, and won't read = the BMPString value either. But I'm going on faith that since the = Cryptoapi 2.0 beta certificate viewer can read and display the = BMPString, it's ok. It's the only program I've found (other than my = own, of course) that can. - Mark Bartel From chandras@loc201.tandem.com Fri Jan 24 12:42:14 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id MAA11215; Fri, 24 Jan 1997 12:42:14 -0800 Received: from swift.com by suntan.tandem.com (8.6.12/suntan5.961027) for id MAA11192; Fri, 24 Jan 1997 12:42:05 -0800 Received: from ussr23 ([149.134.97.231]) by swift.com (4.1/3.1.090690-S.W.I.F.T) id AA12990; Fri, 24 Jan 97 21:17:54 +0100 Message-Id: <9701242017.AA12990@swift.com> From: "Suri Vangala" To: "PKI WG" Cc: Subject: LDAP over X25 Date: Fri, 24 Jan 1997 15:43:47 -0500 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I am interested in LDAP implementation over X25. If you know of such an offering please advise. From chandras@loc201.tandem.com Fri Jan 24 14:15:01 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id OAA23293; Fri, 24 Jan 1997 14:15:01 -0800 Received: from wiau.wi.mt.np.els-gms.att.net by suntan.tandem.com (8.6.12/suntan5.961027) for id OAA23284; Fri, 24 Jan 1997 14:14:59 -0800 Date: Fri, 24 Jan 1997 15:43:47 +0000 From: mshirey@attmail.com (Suri Vangala) Received: from mshirey by attmail; Fri Jan 24 22:14:08 GMT 1997 Subject: LDAP over X25 To: ietf-pkix@tandem.com (PKI WG) Cc: devigiri@mnsinc.com Message-Id: <9701242017.AA12990@swift.com> X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Encoding-Type: ISO8859.1 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I am interested in LDAP implementation over X25. If you know of such an offering please advise. From chandras@loc201.tandem.com Fri Jan 24 15:19:05 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id PAA01466; Fri, 24 Jan 1997 15:19:05 -0800 Received: from mercury.Sun.COM by suntan.tandem.com (8.6.12/suntan5.961027) for id PAA01458; Fri, 24 Jan 1997 15:19:03 -0800 Received: from Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA12063; Fri, 24 Jan 1997 15:17:53 -0800 Received: from jurassic.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA16095; Fri, 24 Jan 1997 15:17:50 -0800 Received: from petra1.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA09036; Fri, 24 Jan 1997 15:17:49 -0800 Received: by petra1.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA16191; Fri, 24 Jan 1997 15:17:45 -0800 From: yahya.abual-salqan@eng.sun.com (Yahya Al-Salqan) Message-Id: <199701242317.PAA16191@petra1.eng.sun.com> Subject: Enterprise Security Workshop CFP To: ietf-pkix@tandem.com Date: Fri, 24 Jan 1997 15:17:45 -0800 (PST) Cc: ietf-otp@bellcore.com X-Mailer: ELM [version 2.4 PL21] Content-Type: text Call For Papers Second International Workshop on Enterprise Security June 18-20, 1997 Massachusetts Institute of Technology (MIT), Cambridge, Massachusetts, USA Co-sponsored by the IEEE Computer Society and the Concurrent Engineering Research Center (CERC) at West Virginia University ============================================================================== Enterprises are increasingly dependent on their information systems to support their business and workflow activities. There is a need for universal electronic connectivity to support interaction and cooperation between multiple organizations. This makes enterprise security and confidentiality more important, but more difficult to achieve, as the multiple organizations may have differences in their security policies and may have to interact via an insecure Internet. These inter-organizational enterprise systems may be very large and so tools and techniques are needed to support the specification, analysis and implementation of security. This workshop will focus on the problems and challenges relating to enterprise security in inter-organizational systems. We aim to bring together principal players from both the internetwork and enterprise security community and will provide plenty of time for discussion. Topics to be addressed include: - Internet/Intranet security - Security infrastructure and protocols - Java Security - Specifying and Analyzing Enterprise Security Policy - Role-Based Access Control - Supporting enterprise security over the Internet - Conflicts and harmonization of inter- and intra-organizational Security - Distributed Database Security - Secure Transactions - Security in Workflow Process - Object-Oriented and CORBA Security - Secure Applications and Environments - Integrating Heterogeneous Security Environments - Managing inter-organizational Enterprise Security - Internet Security protocols - Security Algorithms This workshop will be part of the IEEE Sixth Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET-ICE 96) organized by the Concurrent Engineering Research Center (CERC)/ West Virginia University. Important Dates: ================ Papers Due March 25, 1997 Panel Proposals March 18, 1997 Authors notified of acceptance April 21, 1997 Workshop June 18-20, 1997 Camera Ready June 28, 1997 INFORMATION FOR AUTHORS OF PAPERS TO BE INCLUDED IN THE PROCEEDINGS =================================================================== Mail six copies of an original (not submitted or published elsewhere) paper (double-spaced) of 3000-5000 words to one of the PC co-chairs. Include the title of the paper, the name and affiliation of each author, a 150-word abstract and no more than 8 keywords. The name, position, address, telephone number, and if possible, fax number and e-mail address of the author responsible for correspondence of the paper must be included. An e-mail submission in postscript format will be accepted. INFORMATION FOR PANEL ORGANIZERS ================================ Send six copies of panel proposals to one of the PC co-chairs. Include the title, a 150-word scope statement, proposed session chair and panelists and their affiliations, the organizer's affiliation, address, telephone and fax number, and e-mail address. INFORMATION FOR AUTHORS OF POSITION PAPERS ========================================== Send six copies of position paper of 2-3 pages to one of the PC co-chairs. Include the title of the paper, the name and affiliation of each author, a 150-word abstract and no more than 8 keywords. The name, position, address, telephone number, and if possible, fax number and e-mail address of the author responsible for correspondence of the paper must be included. An accepted position paper will get less presentation time than full paper. Workshop General Chair and Organizer ==================================== Yahya Al-Salqan, Ph.D. Sun Microsystems alsalqan@eng.sun.com Program Committee ================= Program Committee Co-Chairs ========================== Barbara C. Davis Director of Technology The Applied Knowledge Group 231 Market Place, #315 San Ramon, CA 94583-2785 USA Tel. (888) 442-2785 FAX (510) 275-9695 bcdavis@appliedknowledge.com Douglas Moughan National Security Agency, R23 9800 Savage Rd. Ft. Meade, Maryland 20755-6000 USA wdm@tycho.ncsc.mil Workshop Program Committee (Partial List): ========================================== Abdallah Abdallah, Birzeit University, Jerusalem Takasi Arano, NTT Corp, Japan Germano Caronni, ETH-Zurich, Switzerland Taher ElGamal, Netscape Corp., USA Stephen Farrell, Software and Systems Engineering, Ireland Takeo Hamada, Fujitsu, Japan Matthias Hirsch, BSI (Federal Department of Security in the Information Technology-Germany Cynthia L Musselman, Sandia Lab, USA Lisa Pretty, Certicom Corp., Canada Jeffrey Parrett, LLNL, USA Sumitra Reddy, West Virginia University, USA Nahid Shahmehri, Linkoping University, Sweden Morris Sloman, Department of Computing: Imperial College, UK Badie Taha, Al-Quds University, Jerusalem Robert Thomys, BSI (Federal Department of Security in the Information Technology-Germany Tatu Ylonen, SSH Communication Security, Finlad Nick Zhang, EIT, USA Internet Hot-line ================= Information on Enterprise Security Workshop may be obtained through the WWW using the URL http://www.cerc.wvu.edu/SECWK/ For more information on WET-ICE'97, visit the URL: http://www.cerc.wvu.edu/WETICE/WETICE97.html One does not need to have a paper to attend the workshop. From chandras@loc201.tandem.com Mon Jan 27 12:49:56 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id MAA19368; Mon, 27 Jan 1997 12:49:56 -0800 Received: from manitou.cse.dnd.ca by suntan.tandem.com (8.6.12/suntan5.961027) for id MAA19363; Mon, 27 Jan 1997 12:49:53 -0800 Received: from manitou1.cse.dnd.ca (kabibonokka.cse.dnd.ca [131.136.196.4]) by manitou.cse.dnd.ca (8.7.5/8.7.3) with ESMTP id PAA14953 for ; Mon, 27 Jan 1997 15:40:22 -0500 (EST) Received: from rsp02-2 (ppp05.cse.dnd.ca [131.136.196.134]) by manitou1.cse.dnd.ca (8.7.3/8.7.3) with SMTP id PAA24267 for ; Mon, 27 Jan 1997 15:48:09 -0500 (EST) Date: Mon, 27 Jan 1997 15:48:09 -0500 (EST) Message-Id: <199701272048.PAA24267@manitou1.cse.dnd.ca> X-Sender: evanhees@cse.dnd.ca (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-pkix@tandem.com From: sfd Subject: Info on PKIX standards status Would appreciate information on the status PKIX standards Where exactly are the WWW site or ftp sites Edmond Van Hees 613-991-7413 From chandras@loc201.tandem.com Mon Jan 27 13:00:25 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id NAA21040; Mon, 27 Jan 1997 13:00:25 -0800 Received: from relay3.UU.NET by suntan.tandem.com (8.6.12/suntan5.961027) for id NAA21030; Mon, 27 Jan 1997 13:00:22 -0800 Received: from ub-gate.UB.com by relay3.UU.NET with SMTP (peer crosschecked as: ub-gate.UB.com [192.216.34.11]) id QQcaiu03485; Mon, 27 Jan 1997 16:00:15 -0500 (EST) Received: from netcomsv.netcom.com (uucp3.netcom.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.9.1]) id AA01677; Mon, 27 Jan 97 12:58:58 PST Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id MAA17470; Mon, 27 Jan 1997 12:23:21 -0800 Received: from cc:Mail by spysouth.spyrus.com id AA854395721 Mon, 27 Jan 97 12:08:41 Date: Mon, 27 Jan 97 12:08:41 From: "Housley, Russ" Encoding: 1321 Text Message-Id: <9700278543.AA854395721@spysouth.spyrus.com> To: ietf-pkix@tandem.com, Peter Williams Subject: Re: PKCS#7 in PKIX-3 Peter: > My observation that an *unbundled* protection envelope (which encapulates > std information objects, rather than protects inner types) be the basis > of the design is founded on such observation of the success of the above > approach in which componentware from multiple sources were bunded by the > customers without third-party invention, yet all parties in a staticaly > configured certification system could agree the actual basis for technical > interworking and system msg flow with minimal effort, complete control > over local security policy maintained in the hands of the procurer, and > selection from muliple sources of equivalent product/toolkit/protction > technology based on price, availability, and other value-adds etc. I think that we are near concensus on this point. A single encapsulation mechanism would be ideal. PKIX Part 3 contains one suggestion, and PKCS #7 contains another. Carlise provided an analysis for the PKIX Part 3 approach. PKCS #7 has a market share that should not be ignored, and the specification is open for reivew and update. Further, RSA has agreed to work with the IETF on the PKCS "standards" and give configuration control to the IETF where standards track RFCs result. So, how does the group want to proceed? Russ From chandras@loc201.tandem.com Tue Jan 28 09:06:23 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id JAA08277; Tue, 28 Jan 1997 09:06:23 -0800 Received: from eurogate.nortel.co.uk by suntan.tandem.com (8.6.12/suntan5.961027) for id JAA08272; Tue, 28 Jan 1997 09:06:21 -0800 Received: from hedera.bnr.co.uk (actually innergate.nortel.co.uk) by eurogate.nortel.co.uk with SMTP (PP); Tue, 28 Jan 1997 17:05:09 +0000 Received: from bwdldb.ott.bnr.ca by hedera.bnr.co.uk with SMTP (PP); Tue, 28 Jan 1997 17:04:35 +0000 Received: by bwdldb.ott.bnr.ca with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC0D12.D1849230@bwdldb.ott.bnr.ca>; Tue, 28 Jan 1997 12:00:13 -0500 Message-ID: From: Carlisle Adams To: "'housley@spyrus.com'" Cc: "'ietf-pkix@tandem.com'" Subject: RE: PKCS#7 in PKIX-3 Date: Tue, 28 Jan 1997 11:59:45 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 73 TEXT Hi Russ, >---------- >From: housley@spyrus.com[SMTP:housley@spyrus.com] >Sent: Monday, January 27, 1997 7:08 AM >To: ietf-pkix@tandem.com; peter@verisign.com >Subject: Re: PKCS#7 in PKIX-3 > > >I think that we are near concensus on this point. A single >encapsulation mechanism would be ideal. PKIX Part 3 contains one >suggestion, and PKCS #7 contains another. Carlise provided an >analysis for the PKIX Part 3 approach. PKCS #7 has a market >share that should not be ignored, and the specification is open >for reivew and update. Further, RSA has agreed to work with the >IETF on the PKCS "standards" and give configuration control to >the IETF where standards track RFCs result. > >So, how does the group want to proceed? > >Russ At the risk of sounding repetitious, let me try to state a couple of things as clearly and succinctly as I possibly can. 1) The PKIX-3 protocol, as currently specified, is able to handle protection for PKIX-3 messages in all situations (i.e., when end-entities already have public-key certificates (for various algorithms), and when they don't (but they do have some shared secret information with the other end)). Furthermore, it allows the option of "no protection", so that if two parties want to take "bare" PKIX-3 messages and wrap these using PKCS#7 (or any other mechanism) in circumstances for which this is appropriate, they are free to do so. 2) The PKCS#7 enveloping protocol, as currently specified, is *not* able to handle protection for PKIX-3 messages in all situations (for reasons discussed in my previous posts). It is perfectly adequate for *some* situations, but not all. I cannot imagine that it makes sense to make *mandatory* a mechanism which will not work in all situations. It makes much more sense to make such a mechanism *optional*, so that it can be used wherever appropriate. This is exactly what the current PKIX-3 protocol does. What is mandatory is the lowest common denominator which will work in every situation providing perfectly good protection; PKCS#7 is optionally allowed for any situation for which it is appropriate. The two statements, "PKCS#7 has a market share that should not be ignored" and "the specification is open for update" are contradictory. Changing PKCS#7 in any way (even if change control is given to the IETF) *does* ignore the market share, since it requires every implementation in the installed base to be modified. If the market share should really not be ignored, then the current PKIX-3 makes the most sense since this allows the installed base to be used, as is, whenever this is appropriate. "How does the group want to proceed?" Good question. As I see it, there are two options. We can keep what we have since it works in all situations, since it is easy to understand and implement, and since it respects the installed base by allowing code re-use wherever this can be done. Or we can hold up progression of the PKIX management protocols for some indeterminate time (at least months; possibly longer) until PKCS#7 is "updated" to everyone's satisfaction. [In my opinion, we are likely to find that the update, when finally complete, looks very much like the protection scheme we already have.] > -------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com --------------------------------------- From chandras@loc201.tandem.com Wed Jan 29 04:49:55 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id EAA07189; Wed, 29 Jan 1997 04:49:55 -0800 Received: from atanda.com by suntan.tandem.com (8.6.12/suntan5.961027) for id EAA07180; Wed, 29 Jan 1997 04:49:53 -0800 Received: from [139.167.130.246] by atanda.com with ESMTP (Apple Internet Mail Server 1.1.1); Wed, 29 Jan 1997 04:47:11 -0800 X-Sender: rah@atanda.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Jan 1997 07:41:52 -0500 To: FC97 Distribution From: Robert Hettinga Subject: Call for Participants: The Financial Cryptography 1997 Workshop for Senior Managers and IS Professionals CALL FOR PARTICIPANTS The Financial Cryptography 1997 (FC97) Workshop for Senior Managers and IS Professionals February 17-21, 1997 The InterIsland Hotel Anguilla, BWI Workshop Update: January 29, 1997 FC97 is sponsored by: The Journal for Internet Banking and Commerce Offshore Information Services e$ C2NET See Your Name Here! FC97 Workshop for Senior Managers and IS Professionals February 17-21, 1997 FC97 Conference and Exhibition, February 24-28, 1997 The Inter-Island Hotel Anguilla, BWI Workshop and Conference Reservations: The world's first intensive financial cryptography workshop for senior managers and IS professionals will be held Monday through Friday, February 17-21 1997, from 9:00am to 6:00pm, at the Inter-Island Hotel on the Carribbean island of Anguilla. This workshop will be the prelude to the world's first peer-reviewed financial cryptography conference and commercial exhibition, Financial Cryptography 1997 (FC97), which will be held the following week, February 24-28, 1997. The goals of the combined workshop, conference and exhibition are: -- to give senior managers and IS professionals a solid understanding of the fundamentals of strong cryptgraphy as applied to financial operations on public networks, -- to provide a peer-reviewed forum for important research in financial cryptography and the effects it will have on society, and, -- to showcase the newest products in financial cryptography. Workshop and Conference participants are encouraged to bring their families, though Workshop participants should expect to be busy the first week. :-). The Workshop Ian Goldberg, the Workshop chair, has picked an outstanding team of instructors in financial cryptography and internet financial system security to teach the courses in this workshop. The Workshop will consist of 40 hours of intensive instruction and lab time over 5 days. Each student will have their own internet workstation, and the lab will be open 24 hours. The SSL internet commerce server used in the workshop will be Stronghold, developed by C2NET, of Berkeley, California. For information on Stronghold, please see . Thanks to C2NET for their gracious donation of this outstanding software to the FC97 Workshop. Who Should Attend The Workshop is intended for senior IS managers and technical professionals who want to get completely up to speed on the design, development, and implementation of financial cryptography systems, the core technology of internet commerce. After the workshop, senior managers will have a hands-on understanding the strengths and liabilities of currently available financial cryptography and internet transaction security software and hardware, and thus be able to make better asset allocation decisions in this area of explosive technology growth. Senior technical professionals with strong IS experience will be able to implement those technologies and to pass on what they've learned to their clients and colleagues when they return home. The Workshop will be held in a casual but intensive atmosphere at the very cutting edge of financial technology on the internet. Someone has likened the experience to a financial cryptography bootcamp. At the end, Workshop attendees will be utterly conversant in cryptography as it applies to finance, and will be quite prepared for the technical papers in the FC97 conference the following week. Workshop participants will not only know what everyone else is doing now in internet commerce, but, more important, because they understand the implications of strong financial cryptography on ubiquitous public networks, they will be able to know what to do *next*. The Workshop Leader Ian Goldberg is a Ph.D. student in security and cryptography at the University of California, Berkeley. Just last night, he cracked RSA Data Security Inc.'s 40-bit challenge cipher in just under 3.5 hours. In late 1995, he discovered what became a much-publicized flaw in Netscape's implementation of SSL. He is a recognized expert in electronic payment systems, and in DigiCash's ecash digital bearer certificate protocol in particular. He has produced several ecash clients for Unix and Windows, as well as an ecash module for the Stronghold web server, which has extended the existing ecash system for better security, privacy, and ease-of-use. The Principal Instructors Gary Howland worked on digital cash systems for DigiCash, and then moved to Systemics, where he developed the SOX protocol, a flexible payments system currently in use in a bond trading environment, soon to be available to the public. He also developed the Cryptix and PGP libraries in Perl, and assisted on the Cryptix and PGP library implementations in Java. Adam Shostack is a security consultant based in the Boston area. He has extensive background in designing, implementing and testing secure systems for clients in the medical, computer, and financial industries. His recent public work includes 'Apparent Weaknesses in the Security Dynamics Client Server Protocol,' 'Source Code Review Guidelines,' and comparisons of freely available cryptographic libraries. His clients include Fidelity Investments and the Brigham and Women's Hospital, in Boston. Additional Instructors The Workshop will have student-to-instructor ratio of 5 to 1, not including the Workshop leader. The Workshop will have an initial enrollment of 10 students, and an additional instructor will be added for each 5 students up to a 25 student maximum enrollment. Workshop Topics The following is the complete list of topics that the workshop will cover: Security on the Internet Internet Protocols: IP, TCP, UDP Higher-level Protocols: Telnet, FTP, HTTP, SSL Solid Foundations for Cryptographic Systems A History of Internet Attacks Building Internet Firewalls Building a Bastion Host Turning your Bastion Host into a Web Server Non-internet Internet Security Cryptography The Need for Cryptography History of Cryptography Classical Methods Modern Methods Private and Public Key Cryptography Authentication vs. Security Certification and Public Key Infrastructures Cryptographic Protocols Engineering a Cryptographically Secure System Why Cryptography is Harder than it Looks Security Through Obscurity and How to Recognize Snake Oil Internet Payment Systems Payment models: coin-based, cheque-based, account-based Security Issues Privacy and Anonymity Issues Smartcards vs. Software Existing Payment Schemes Credit Cards First Virtual CyberCash DigiCash Forthcoming Payment Schemes SET Mondex Millicent micropayments Setting Up an ecash-Enabled Web Server Setting up the Web Server Signing up for ecash Installing the ecash Module Setting Prices Logging Advanced Methods ecashiers moneychangers The workshop has been covered by Wired Magazine, and FC97 was the featured conference in the January 1997 "Deductible Junkets" section. So, if you have already decided to come to the FC97 Workshop and Conference, please register and make your plane and hotel reservations as soon as possible. Workshop space is extremely limited. The price of the workshop is $5,000 U.S. You can pay for your FC97 workshop ticket with Visa or MasterCard, with ecash, or with any of a number of other internet commerce payment protocols, at the regstriation site: . The workshop price includes meals (but not lodging) at the InterIsland Hotel and lab space, plus the delivery and installation of hardware, network access, internet commerce software, all to a location like Anguilla. And, of course, 40 hours of instruction and structured lab activity. We have priced the workshop to be competitive with other comprehensive business and professional technology workshops of similar total session length. In addition, the first 10 FC97 workshop participants will receive a 50% reduction in their FC97 Conference and Exhibition fee, for a savings of $500 off the $1,000 conference admission. You can register, and pay for, your workshop ticket at: Air Transportation and Hotels Air travel to Anguilla is typically done through San Juan, St. Thomas or St. Maarten/Martin. There are several non-stop flights a day from various US and European locations. Connection through to Anguilla can be made through American Eagle, or through LIAT, or in the case of St. Maarten, with a short ferry ride to Anguilla. See your travel agent for details. Anguilla's runway is 3600 feet, with a displaced threshold of 600 feet, and can accomodate business jets. Obviously, you should talk to your aviation staff for details about your own aircraft's capabilities in this regard. Anguilla import duties are not imposed on hardware or software which will leave the island again, so, as long as you take it with you when you leave, you won't pay import duties. PLEASE NOTE: Your FC97 Workshop fee only covers *meals* at the InterIsland Hotel. The InterIsland is actually a small guesthouse attached to a large conference facility, and so rooms there are in short supply. Fortunately, there are lots of small hotels and guesthouses nearby. For more information on these hotels, please see for more information. Other hotels on Anguilla range from spartan to luxurious, all within easy walking or driving distance of the Workshop at the InterIsland. More information about Anguillan hotels can be obtained from your travel agent, or at . Registration and Information for Other FC97 Events To register and pay for your ticket to the FC97 conference itself, see: For information the selection of papers for the FC97 conference see: If you're interested in Exhibition space, please contact Julie Rackliffe: If you're interested in sponsoring FC97, also contact Julie Rackliffe: Financial Cryptography '97 is held in cooperation with the International Association for Cryptologic Research. The conference proceedings will be published on the web by the Journal for Internet Banking and Commerce. . The FC97 Organizing Committee: Vince Cate and Bob Hettinga, General Chairs Ray Hirschfeld, Conference Chair Ian Goldberg, Workshop Chair Julie Rackliffe, Conference, Exhibit, and Sponsorship Manager And our sponsors... The Journal for Internet Banking and Commerce Offshore Information Services e$ C2NET See Your Name Here ----------------- Robert Hettinga (rah@shipwright.com), Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "The cost of anything is the foregone alternative" -- Walter Johnson The e$ Home Page: http://www.shipwright.com/rah/ FC97: Anguilla, anyone? http://www.ai/fc97/ "If *you* don't go to FC97, *I* don't go to FC97" From chandras@loc201.tandem.com Wed Jan 29 05:10:14 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id FAA08457; Wed, 29 Jan 1997 05:10:14 -0800 Received: from atanda.com by suntan.tandem.com (8.6.12/suntan5.961027) for id FAA08451; Wed, 29 Jan 1997 05:10:11 -0800 Received: from [139.167.130.246] by atanda.com with ESMTP (Apple Internet Mail Server 1.1.1); Wed, 29 Jan 1997 05:11:46 -0800 X-Sender: rah@atanda.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Jan 1997 08:06:24 -0500 To: FC97 Conference Distribution From: Robert Hettinga Subject: FC97: PRELIMINARY CONFERENCE PROGRAM Financial Cryptography '97 February 24-28 1997, Anguilla, BWI PRELIMINARY PROGRAM General Information: Financial Cryptography '97 (FC97) is a new conference on the security of digital financial transactions. The first meeting will be held on the island of Anguilla in the British West Indies on February 24-28, 1997. FC97 aims to bring together persons involved in both the financial and data security fields to foster cooperation and exchange of ideas. Original papers were solicited on all aspects of financial data security and digital commerce in general. Program Committee: Matthew Franklin, AT&T Laboratories--Research, Murray Hill, NJ, USA Michael Froomkin, U. Miami School of Law, Coral Gables, FL, USA Rafael Hirschfeld (Program Chair), CWI, Amsterdam, The Netherlands Arjen Lenstra, Citibank, New York, NY, USA Mark Manasse, Digital Equipment Corporation, Palo Alto, CA, USA Kevin McCurley, Sandia Laboratories, Albuquerque, NM, USA Charles Merrill, McCarter & English, Newark, NJ, USA Clifford Neuman, Information Sciences Institute, Marina del Rey, CA, USA Sholom Rosen, Citibank, New York, NY, USA Israel Sendrovic, Federal Reserve Bank of New York, New York, NY, USA Preliminary Conference Program for FC97: Monday 24 February 1997 830 -- 905 Anonymity Control in E-Cash Systems George Davida (University of Wisconsin, Milwaukee, WI, USA), Yair Frankel (Sandia National Laboratories, Albuquerque, NM, USA), Yiannis Tsiounis (Northeastern University, Boston, MA, USA), Moti Yung (CertCo, New York, NY, USA) 905 -- 940 How to Make Personalized Web Browsing Simple, Secure, and Anonymous Eran Gabber, Phil Gibbons, Yossi Matias, Alain Mayer (Bell Laboratories, Lucent Technologies) 940 -- 1015 An Anonymous Networking Infrastructure and Virtual Intranets Jim McCoy (Electric Communities, Cupertino, CA, USA) 1015 -- 1045 Coffee Break 1045 -- 1120 Unlinkable Serial Transactions Paul F. Syverson (Naval Research Laboratory, Washington, DC, USA), Stuart G. Stubblebine (AT&T Labs--Research, Murray Hill, NJ, USA), David M. Goldschlag (Naval Research Laboratory, Washington, DC, USA) 1120 -- 1155 Efficient Electronic Cash with Restricted Privacy Cristian Radu, Rene Govaerts, Joos Vandewalle (Katholieke Universiteit Leuven, Leuven, Belgium) 1155 -- 1230 The SPEED Cipher Yuliang Zheng (Monash University, Melbourne, Australia) Tuesday 25 February 1997 830 -- 930 Invited Speaker To Be Announced 930 -- 1005 Smart Cards and Superhighways The technology-driven denationalisation of money David G.W. Birch, Neil A. McEvoy (Hyperion, Surrey, England) 1005 -- 1045 Coffee Break 1045 -- 1120 Fault Induction Attacks, Tamper Resistance, and Hostile Reverse Engineering in Perspective David P. Maher (AT&T Labs--Research, Murray Hill, NJ, USA) 1120 -- 1155 Some Critical Remarks on "Dynamic Data Authentication" as specified in EMV '96 Louis C. Guillou (CCETT, Cesson-Sevigne, France) 1155 -- 1230 Single-chip implementation of a cryptosystem for financial applications Nikolaus Lange (SICAN Braunschweig GmbH, Braunschweig, Germany) Wednesday 26 February 1997 830 -- 930 Invited Speaker Ronald Rivest (MIT Lab for Computer Science, Cambridge, MA, USA) 930 -- 1005 Cyberbanking and Privacy: The Contracts Model Peter P. Swire (Ohio State University, Columbus, OH, USA) 1005 -- 1045 Coffee Break 1045 -- 1120 SVP: a Flexible Micropayment Scheme Jacques Stern, Serge Vaudenay (Ecole Normale Superieure, Paris, France) 1120 -- 1155 An efficient micropayment system based on probabilistic polling Stanislaw Jarecki (MIT Lab for Computer Science, Cambridge, MA, USA), Andrew Odlyzko (AT&T Labs--Research, Murray Hill, NJ, USA) 1155 -- 1230 On the continuum between on-line and off-line e-cash systems - I Yacov Yacobi (Microsoft, Redmond, WA, USA) Thursday 27 February 1997 830 -- 905 Auditable Metering with Lightweight Security Matthew K. Franklin, Dahlia Malkhi (AT&T Labs--Research, Murray Hill, NJ, USA) 905 -- 940 Applying Anti-Trust Policies to Increase Trust in a Versatile E-Money System Markus Jakobsson (UCSD, La Jolla, CA, USA), Moti Yung (BTEC/CertCo, New York, NY, USA) 940 -- 1015 Towards Multiple-payment Schemes for Digital Money H. Pagnia, R. Jansen (University of Darmstadt, Darmstadt, Germany) 1015 -- 1045 Coffee Break 1045 -- 1120 Legal Issues in Cryptography Edward J. Radlo (Fenwick & West LLP, Palo Alto, CA, USA) 1120 -- 1230 Panel Discussion Legal Issues of Digital Signatures Michael Froomkin (University of Miami School of Law, Miami, FL, USA), Charles Merrill (McCarter & English, Newark, NJ, USA), Benjamin Wright (Dallas, TX, USA) Friday 28 February 1997 830 -- 930 Invited Speaker To Be Announced 930 -- 1005 The Gateway Security Model in the Java Electronic Commerce Framework Theodore Goldstein (Sun Microsystems Laboratories/Javasoft) 1005 -- 1045 Coffee Break 1045 -- 1120 Highly Scalable On-line Payments Via Task Decoupling David William Kravitz (CertCo LLC, Albuquerque, NM, USA) 1120 -- 1155 GUMP; Grand Unified Meta-Protocols Recipes for Simple, Standards-based Financial Cryptography Barbara Fox, Brian Beckman (Microsoft, Redmond, WA, USA) 1155 -- 1230 Secure Network Communications and Secure Store & Forward Mechanisms with SAP R/3 Bernhard Esslinger (SAP AG, Walldorf, Germany) The conference will run from 8:30 AM to 12:30 PM, for five days, February 24-28 1997. Breakfast provided at the conference. The conference organizers have left the afternoon and evenings open for corporate sponsored events, for networking, and for recreational activities on the resort island of Anguilla. Participants are encouraged to bring their families. Workshop: A 40-hour workshop, intended for anyone with commercial software development experience who wants hands-on familiarity with the issues and technology of financial cryptography, is planned in conjunction with FC97, to be held during the week preceding the conference. For more information on the workshop, please see the URL http://www.cs.berkeley.edu/~iang/fc97/workshop.html . For workshop registration, see the URL http://www.offshore.com.ai/fc97/ . Venue: The InterIsland Hotel is a small 14-room guesthouse and a large, comfortable 150 seat conference facility with additional space for a small 10-booth exhibition. The Inter-Island is on Road Bay, near Sandy Ground Village, in the South Hill section of Anguilla. The conference, workshop, and exhibition will have TCP/IP internet access. The rooms at the InterIsland itself have sold out, but there are many other hotels and guesthouses on Anguilla, and shuttle service to the conference will be available. Air Transportation and Hotels: Air travel to Anguilla is typically done through either San Juan or St. Thomas for US flights, or St. Maarten/Martin for flights from Europe and the US. Anguillan import duties are not imposed on hardware or software which will leave the island again. There are no other taxes -- or cryptography import/export restrictions -- on Anguilla. Hotels range from spartan to luxurious, and more information about hotels on Anquilla can be obtained from your travel agent, or at the URL http://www.offshore.com.ai/fc97/ . General Chairs: Robert Hettinga, Shipwright/e$, Boston, MA, USA; rah@shipwright.com Vincent Cate, Offshore Information Services, Anguilla, BWI; vince@offshore.com.ai Conference, Exhibits, and Sponsorship Manager: Julie Rackliffe, Boston, MA, USA; rackliffe@tcm.org Workshop Leader: Ian Goldberg, Berkeley, CA, USA; iang@cs.berkeley.edu Registration: You can register and pay for conference admission on the World Wide Web at the URL http://www.offshore.com.ai/fc97/ . The cost of the FC97 Conference is US$1,000. Booths for the exhibition start at US$5,000 and include two conference tickets. For more information about exhibit space, contact Julie Rackliffe, rackliffe@tcm.org . Sponsorship opportunities for FC97 are still available. The cost of the workshop is US$5000, and includes meals but not lodging. You can register for the workshop, which runs the week prior to the conference, at the URL Financial Cryptography '97 is held in cooperation with the International Association for Cryptologic Research. It is sponsored by: The Journal for Internet Banking and Commerce Offshore Information Services e$ C2NET See Your Name Here ----------------- Robert Hettinga (rah@shipwright.com), Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "The cost of anything is the foregone alternative" -- Walter Johnson The e$ Home Page: http://www.shipwright.com/rah/ FC97: Anguilla, anyone? http://www.ai/fc97/ "If *you* don't go to FC97, *I* don't go to FC97" From chandras@loc201.tandem.com Fri Jan 31 05:03:26 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id FAA14453; Fri, 31 Jan 1997 05:03:26 -0800 Received: from cryptomathic.aau.dk by suntan.tandem.com (8.6.12/suntan5.961027) for id FAA14447; Fri, 31 Jan 1997 05:03:22 -0800 Received: from turing ([194.239.238.194]) by cryptomathic.aau.dk (8.8.3/8.8.3) with SMTP id OAA05392 for ; Fri, 31 Jan 1997 14:02:41 -0100 Message-ID: <32F1ED4F.3191@cryptomathic.aau.dk> Date: Fri, 31 Jan 1997 14:02:07 +0100 From: Anette Byskov Reply-To: abyskov@cryptomathic.aau.dk X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: ietf-pkix@tandem.com Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit subscribe From chandras@loc201.tandem.com Fri Jan 31 06:37:11 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id GAA22443; Fri, 31 Jan 1997 06:37:11 -0800 Received: from hqrtmta1.doe.gov by suntan.tandem.com (8.6.12/suntan5.961027) for id GAA22434; Fri, 31 Jan 1997 06:37:09 -0800 Received: by hqrtmta1.doe.gov (1.37.109.16/16.2) id AA079981201; Fri, 31 Jan 1997 09:33:21 -0500 Date: Fri, 31 Jan 1997 9:38:00 -0500 From: "CHUCK.PHILIPP" Message-Id: Subject: unsubscribe To: "KEVIN.SHAVER" To: ietf-pkix@tandem.com X400-Mts-Identifier: [ /P=USDOE/A=ATTMAIL/C=US/ ; c\hq\970131093314a ] X-Mailer: Worldtalk (4.0.2-p8)/MIME unsubscribe chuck.philipp@hq.doe.gov From chandras@loc201.tandem.com Fri Jan 31 11:17:41 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id LAA02465; Fri, 31 Jan 1997 11:17:41 -0800 Received: from verisign.com by suntan.tandem.com (8.6.12/suntan5.961027) for id LAA02448; Fri, 31 Jan 1997 11:17:38 -0800 Message-Id: <3.0.32.19970131111522.0073f72c@mail> X-Sender: peter@mail (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 31 Jan 1997 11:15:37 -0800 To: Carlisle Adams , "'housley@spyrus.com'" From: Peter Williams Subject: RE: PKCS#7 in PKIX-3 Cc: "'ietf-pkix@tandem.com'" MIME-Version: 1.0 Content-Type: multipart/signed; boundary= "---=_=_ 673551678-6741220-12299792 _=_=---"; micalg=rsa-sha1; protocol="application/x-pkcs7-signature" -----=_=_ 673551678-6741220-12299792 _=_=--- Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Carlise: I believe there is a better way than saying always "no, no and no", to _actually_ open systems component technology and a world of third-party, multi-vendor "highly re-bundlable" key management technology. I want PKIX to be a useful componentware standard, not merely a pretend std for marketing closed or proprietary technology. Surely the days of the monolithic CA management systems are over; even their tiny appreciative market is going away. We now need a plug-and play CA technology world, where its the "proprietary" business rules of the using and issuing organizations which govern how functional units of a PKIX system are combined to make a specific CA certificate issuing and mgt solutions for bank A, brokerage B, institution C. This is well represented by the PKCS7 (aka layered protection and PKIX-protocol-independent mgt control framework) proposal to this WG. The notion I ventured (reflecting merely what the last meeting asserted and concensually assented to, apparently - as with the strangely missing WWW and S/MIME PKCS#10 feature whose assent was consensually indiciated on at the previous meeting, but which also failed to become realised in the PKIX-3 spec) does not require huge change to documents, nor does it require hold up of the current publication schedules. It merely requires assent of *both* authors to now go with the flow of the group and the interested parties. >From my mailbox, and having consulted the primary players, I think Carlise you are the only party not in consort with the proposal. As an author whose document we are commenting, however, I respect your judgement; so we should only do this is you too agree to move along this path. I think the commercial relevance of PKIX-3 hinges on this issue, however. Without PKIX-3, PKIX-1's profile judgements may not be really that important either. Id urge folk to respect the (expressed) will of the group to move down this layering path. Precisely which wire format specs are agreed upon, I for one dont really mind; this is not the issue for me. Id like PKCS7 as defined now _at least_ to be indicated, and for the next generation being developed in the IETF process with specifically these CA and other environment's requirements in mind to be urged, and architected into the PKIX-3 system and protocol requirements. So, Just as the Oakley key agreement spec for IPSEC asserts that use of DNS security/certs is mandatory (despite the fact that DNS security is neither agreed, fully finished/documented, nor ratified within its respective WG and the IESG security area directorate) so then, with the appropriate language, we mandate an architectural realationship to a PKCS7-like messaging service, but not required that all implementations have to realise it. just as SKIP specifies 4 cert types, not all of which need to be implemented... just as IPSEC std allows a multitude of non-interoperable security service and algoirithm profiles.... just as SSL/TLS allows an RSA client to fail to work with a DH-only SSL server... These std are real, and not pure. So PKIX-3 should be. At 11:59 AM 1/28/97 -0500, Carlisle Adams wrote: >Hi Russ, > >>---------- >>From: housley@spyrus.com[SMTP:housley@spyrus.com] >>Sent: Monday, January 27, 1997 7:08 AM >>To: ietf-pkix@tandem.com; peter@verisign.com >>Subject: Re: PKCS#7 in PKIX-3 >> >> >>I think that we are near concensus on this point. A single >>encapsulation mechanism would be ideal. PKIX Part 3 contains one >>suggestion, and PKCS #7 contains another. Carlise provided an >>analysis for the PKIX Part 3 approach. PKCS #7 has a market >>share that should not be ignored, and the specification is open >>for reivew and update. Further, RSA has agreed to work with the >>IETF on the PKCS "standards" and give configuration control to >>the IETF where standards track RFCs result. >> >>So, how does the group want to proceed? >> >>Russ > > >At the risk of sounding repetitious, let me try to state a couple of >things as clearly and succinctly as I possibly can. > >1) The PKIX-3 protocol, as currently specified, is able to handle >protection for PKIX-3 messages in all situations (i.e., when >end-entities already have public-key certificates (for various >algorithms), and when they don't (but they do have some shared secret >information with the other end)). Furthermore, it allows the option of >"no protection", so that if two parties want to take "bare" PKIX-3 >messages and wrap these using PKCS#7 (or any other mechanism) in >circumstances for which this is appropriate, they are free to do so. > >2) The PKCS#7 enveloping protocol, as currently specified, is *not* able >to handle protection for PKIX-3 messages in all situations (for reasons >discussed in my previous posts). It is perfectly adequate for *some* >situations, but not all. > > >I cannot imagine that it makes sense to make *mandatory* a mechanism >which will not work in all situations. It makes much more sense to make >such a mechanism *optional*, so that it can be used wherever >appropriate. This is exactly what the current PKIX-3 protocol does. >What is mandatory is the lowest common denominator which will work in >every situation providing perfectly good protection; PKCS#7 is >optionally allowed for any situation for which it is appropriate. > >The two statements, "PKCS#7 has a market share that should not be >ignored" and "the specification is open for update" are contradictory. >Changing PKCS#7 in any way (even if change control is given to the IETF) >*does* ignore the market share, since it requires every implementation >in the installed base to be modified. If the market share should really >not be ignored, then the current PKIX-3 makes the most sense since this >allows the installed base to be used, as is, whenever this is >appropriate. > >"How does the group want to proceed?" Good question. As I see it, >there are two options. We can keep what we have since it works in all >situations, since it is easy to understand and implement, and since it >respects the installed base by allowing code re-use wherever this can be >done. Or we can hold up progression of the PKIX management protocols >for some indeterminate time (at least months; possibly longer) until >PKCS#7 is "updated" to everyone's satisfaction. [In my opinion, we are >likely to find that the update, when finally complete, looks very much >like the protection scheme we already have.] >> >-------------------------------------- >Carlisle Adams >Entrust Technologies >cadams@entrust.com >--------------------------------------- > > -----=_=_ 673551678-6741220-12299792 _=_=--- Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIAwggFI MIHzAgRXh90yMA0GCSqGSIb3DQEBBAUAMC4xLDAqBgNVBAMUI1BldGVyIFdpbGxpYW1zIDxw ZXRlckB2ZXJpc2lnbi5jb20+MB4XDTk3MDExNjAxNDE0M1oXDTk5MDExNjAxNDE0MlowLjEs MCoGA1UEAxQjUGV0ZXIgV2lsbGlhbXMgPHBldGVyQHZlcmlzaWduLmNvbT4wXDANBgkqhkiG 9w0BAQEFAANLADBIAkEAqdB5O+ukPCpf6r7BeHbR6pCc1n5XyxkfJtQ5UmqKZRAivlabdf8V 5hoD/HspVZiLJE5aKBGwX1mzUpRSmzRfwQIDAQABMA0GCSqGSIb3DQEBBAUAA0EAiNwkmpNi cyyF2/dy+/cN9GApTiGzEJsv7C4r/YKEWxdA7pA+ZDTG1Jawra1bnlL4JACjjYcnSFOHJNiH MsJucQAAMYAwgfYCAQEwNjAuMSwwKgYDVQQDFCNQZXRlciBXaWxsaWFtcyA8cGV0ZXJAdmVy aXNpZ24uY29tPgIEV4fdMjAJBgUrDgMCGgUAoF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNOTcwMTMxMTkxNTM3WjAjBgkqhkiG9w0BCQQxFgQU5E+Q4HwX hD+phcokjALBHnW9sa0wDQYJKoZIhvcNAQEBBQAEQDBgvCD6wxGczU0H1hbu2090shelV0Vy sKNjVHPXrI2Do3en7uuGN042REzMIvKZl6ellgEW0v+9iVfgTuqiQUIAAAAAAAAAAA== -----=_=_ 673551678-6741220-12299792 _=_=----- From chandras@loc201.tandem.com Fri Jan 31 13:57:25 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id NAA25675; Fri, 31 Jan 1997 13:57:25 -0800 Received: from mailgate31 by suntan.tandem.com (8.6.12/suntan5.961027) for id NAA25663; Fri, 31 Jan 1997 13:57:23 -0800 Received: by mailgate31 (SMI-8.6/SMI-SVR4) id NAA10378; Fri, 31 Jan 1997 13:56:39 -0800 Received: from sdn-ts-001casfrap12.dialsprint.net(206.133.192.31) by mailfep2-hme1 via smap (KC5.24) id Q_10.1.1.6/Q_23636_1_32f26a37; Fri Jan 31 13:55:03 1997 Message-Id: <2.2.32.19970201005757.006d8094@pop.a001.sprintmail.com> X-Sender: wford@pop.a001.sprintmail.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 31 Jan 1997 16:57:57 -0800 To: ietf-pkix@tandem.com From: Warwick Ford Subject: Re: PKCS#7 in PKIX-3 >From observation of many prior standardization activities, I suggest that solutions built by incrementally advancing existing, accepted, well-understood solutions have been far more successful than attempts to define something totally new, even if the latter was technically superior. I believe this same feeling was supported by strong concensus in the San Jose PKIX meeting. If PKCS#7 satisfies requirements for many people, and some incremental extensions to PKCS#7 would satisfy requirements for everyone, then this is clearly far more likely to be accepted as a standard than a totally new invention such as the proposal in the December I-D. I would hate to see us use up scarce resources on a new protocol which lacks broad buy-in from day one. I would appreciate hearing opinions from other members of the list. Warwick At 12:08 PM 1/27/97, you wrote: > >Peter: > >> My observation that an *unbundled* protection envelope (which encapulates >> std information objects, rather than protects inner types) be the basis >> of the design is founded on such observation of the success of the above >> approach in which componentware from multiple sources were bunded by the >> customers without third-party invention, yet all parties in a staticaly >> configured certification system could agree the actual basis for technical >> interworking and system msg flow with minimal effort, complete control >> over local security policy maintained in the hands of the procurer, and >> selection from muliple sources of equivalent product/toolkit/protction >> technology based on price, availability, and other value-adds etc. > >I think that we are near concensus on this point. A single >encapsulation mechanism would be ideal. PKIX Part 3 contains one >suggestion, and PKCS #7 contains another. Carlise provided an >analysis for the PKIX Part 3 approach. PKCS #7 has a market >share that should not be ignored, and the specification is open >for reivew and update. Further, RSA has agreed to work with the >IETF on the PKCS "standards" and give configuration control to >the IETF where standards track RFCs result. > >So, how does the group want to proceed? > >Russ > > --------------------------------------------------------------------- Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 --------------------------------------------------------------------- From chandras@loc201.tandem.com Sat Feb 1 08:34:29 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id IAA28857; Sat, 1 Feb 1997 08:34:29 -0800 Received: by suntan.tandem.com (8.6.12/suntan5.961027) id IAA28852; Sat, 1 Feb 1997 08:34:28 -0800 Date: Sat, 1 Feb 1997 08:34:28 -0800 From: sanders_jeff Message-Id: <199702011634.IAA28852@suntan.tandem.com> To: ietf-pkix@tandem.com, postmaster@tandem.com Subject: Monthly reminder Welcome to the ietf-pkix mailing list! If you ever want to remove yourself from this mailing list, send the following command in email to "listserv@tandem.com" (NOT ietf-pkix@tandem.com): unsubscribe ietf-pkix Here's the general information for the list you've subscribed to, in case you don't already have it: Welcome to the ietf-pkix list. This list is intended to discuss matters directly related to develop Internet standards needed to support an X.509-based public key infrastructure (PKI). The resulting PKI is intended to provide a framework which will support a range of trust/hierarchy environments and a range of usage environments. If you have any questions about this interest group, you can contact Warwick Ford at wford@bnr.ca or Jean Pawluk at pawluk_jean@tandem.com. If you have any questions about this list service in general, you can contact postmaster@tandem.com. From chandras@loc201.tandem.com Sat Feb 1 08:29:20 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id IAA28613; Sat, 1 Feb 1997 08:29:20 -0800 Received: by suntan.tandem.com (8.6.12/suntan5.961027) id IAA28609; Sat, 1 Feb 1997 08:29:19 -0800 Date: Sat, 1 Feb 1997 08:29:19 -0800 From: sanders_jeff Message-Id: <199702011629.IAA28609@suntan.tandem.com> Apparently-To: postmaster@tandem.com Apparently-To: ietf-pkix@tandem.com Apparently-To: Monthly@tandem.com Apparently-To: reminder@tandem.com Welcome to the ietf-pkix mailing list! If you ever want to remove yourself from this mailing list, send the following command in email to "listserv@tandem.com" (NOT ietf-pkix@tandem.com): unsubscribe ietf-pkix Here's the general information for the list you've subscribed to, in case you don't already have it: Welcome to the ietf-pkix list. This list is intended to discuss matters directly related to develop Internet standards needed to support an X.509-based public key infrastructure (PKI). The resulting PKI is intended to provide a framework which will support a range of trust/hierarchy environments and a range of usage environments. If you have any questions about this interest group, you can contact Warwick Ford at wford@bnr.ca or Jean Pawluk at pawluk_jean@tandem.com. If you have any questions about this list service in general, you can contact postmaster@tandem.com. From chandras@loc201.tandem.com Mon Feb 3 06:35:05 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id GAA01359; Mon, 3 Feb 1997 06:35:05 -0800 Received: from ns1.mpd.tandem.com by suntan.tandem.com (8.6.12/suntan5.961027) for id GAA01346; Mon, 3 Feb 1997 06:35:03 -0800 Received: from keymaster.cig.mot.com ([160.12.2.1]) by ns1.mpd.tandem.com (8.8.5/8.8.0) with ESMTP id IAA12000 for ; Mon, 3 Feb 1997 08:30:37 -0600 (CST) Received: (from mailman@localhost) by keymaster.cig.mot.com (8.7.3/8.7.3-FW) id OAA03387 for ; Mon, 3 Feb 1997 14:35:00 GMT X-Authentication-Warning: keymaster.cig.mot.com: mailman set sender to using -f Received: from po_box.cig.mot.com(136.182.15.5) by keymaster.cig.mot.com via smap (V1.3) id sma003382; Mon Feb 3 08:34:34 1997 Message-Id: <199702031434.JAA27887@po_box.cig.mot.com> Received: from phx.sectel.mot.com (rambo.phx.sectel.mot.com [192.94.147.2]) by mothost.mot.com (8.7.6/8.6.10/MOT-3.8) with SMTP id IAA04507 for ; Mon, 3 Feb 1997 08:34:31 -0600 (CST) Received: from peano.sectel (peano.phx.sectel.mot.com) by phx.sectel.mot.com (4.1/SMI-4.1) id AA13476; Mon, 3 Feb 97 07:33:44 MST Date: Mon, 3 Feb 97 07:33:44 MST From: scott%phx.sectel.mot.com@[160.12.2.1]@austx.tandem.com (Will Scott x7610) To: ietf-pkix@tandem.com help list From chandras@loc201.tandem.com Mon Feb 3 08:01:09 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id IAA09417; Mon, 3 Feb 1997 08:01:09 -0800 Received: from zionsbank.com by suntan.tandem.com (8.6.12/suntan5.961027) for id IAA09414; Mon, 3 Feb 1997 08:01:08 -0800 Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Mon, 03 Feb 1997 08:58:11 -0700 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 03 Feb 1997 08:58:00 -0700 From: Mike Smith To: ietf-pkix@tandem.com, wford@verisign.com Subject: Re: PKCS#7 in PKIX-3 -Reply Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline I concur, Warwick. Michael From chandras@loc201.tandem.com Mon Feb 3 09:56:33 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id JAA25401; Mon, 3 Feb 1997 09:56:33 -0800 Received: from guardian.guard.ncsc.mil by suntan.tandem.com (8.6.12/suntan5.961027) for id JAA25388; Mon, 3 Feb 1997 09:56:31 -0800 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id MAA02519 for ; Mon, 3 Feb 1997 12:56:10 -0500 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma002517; Mon Feb 3 12:56:01 1997 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id MAA22316 for ; Mon, 3 Feb 1997 12:53:09 -0500 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id MAA05680; Mon, 3 Feb 1997 12:55:42 -0500 Date: Mon, 3 Feb 1997 12:55:42 -0500 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199702031755.MAA05680@argon.ncsc.mil> To: ietf-pkix@tandem.com Subject: Re: PKCS#7 in PKIX-3 X-Sun-Charset: US-ASCII > From: Warwick Ford > > >From observation of many prior standardization activities, I suggest that > solutions built by incrementally advancing existing, accepted, > well-understood solutions have been far more successful than attempts to > define something totally new, even if the latter was technically superior. > > I believe this same feeling was supported by strong concensus in the San > Jose PKIX meeting. If PKCS#7 satisfies requirements for many people, and > some incremental extensions to PKCS#7 would satisfy requirements for > everyone, then this is clearly far more likely to be accepted as a standard > than a totally new invention such as the proposal in the December I-D. > > I would hate to see us use up scarce resources on a new protocol which lacks > broad buy-in from day one. > > I would appreciate hearing opinions from other members of the list. > > Warwick > > >I think that we are near concensus on this point. A single > >encapsulation mechanism would be ideal. PKIX Part 3 contains one > >suggestion, and PKCS #7 contains another. Carlise provided an > >analysis for the PKIX Part 3 approach. PKCS #7 has a market > >share that should not be ignored, and the specification is open > >for reivew and update. Further, RSA has agreed to work with the > >IETF on the PKCS "standards" and give configuration control to > >the IETF where standards track RFCs result. > > > >So, how does the group want to proceed? > > > >Russ I concur that: 1) a single encapsulation mechanism would be ideal, and 2) incremental improvement of an existing mechanism is better than "something totally new". However, I don't see how PKCS #7 can be incrementally extended to "satisfy requirements for everyone" except by being incrementally extended until it includes a subset that looks remarkably like PKIX 3. Therefore I think the group should proceed as follows: 1) migrate PKIX 3 towards status as an IETF Technical Standard. 2) accept PKCS-7 as an IETF draft, and migrate it towards status as an IETF Technical Standard. 3) write an Applicability Statement (such as Tim's Minimum Interoperability Specification) that requires servers to support both PKIX 3 and PKCS 7 message formats, and requires clients to support at least one of the two. 4) if during the IETF standardization process PKCS-7 becomes incrementally extended to encompass the functionality of PKIX 3, then amend the Applicability Statement to require conformance with just the single improved message format. dpk (who's former boss now works for the same company as Peter and Warwick) From chandras@loc201.tandem.com Tue Feb 4 00:47:30 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id AAA02286; Tue, 4 Feb 1997 00:47:30 -0800 Received: from cs20.cs.auckland.ac.nz by suntan.tandem.com (8.6.12/suntan5.961027) for id AAA02283; Tue, 4 Feb 1997 00:47:26 -0800 Received: from cs26.cs.auckland.ac.nz by cs20.cs.auckland.ac.nz (8.8.3/4.7) id VAA15038; Tue, 4 Feb 1997 21:47:20 +1300 (NZDT) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <85504604023533>; Tue, 4 Feb 1997 21:47:20 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@tandem.com Subject: Re: PKCS#7 in PKIX-3 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: Tue, 4 Feb 1997 21:47:20 (NZDT) Message-ID: <85504604023533@cs26.cs.auckland.ac.nz> Death Rays from Mars made Housley, Russ write: >I think that we are near concensus on this point. A single encapsulation >mechanism would be ideal. PKIX Part 3 contains one suggestion, and PKCS #7 >contains another. Carlise provided an analysis for the PKIX Part 3 approach. >PKCS #7 has a market share that should not be ignored, and the specification >is open for reivew and update. Just to further muddy the water, I've been using a format which is (IMHO) an improvement on PKCS #7 (it fixes a few problems in the PKCS format and is easier to use). In case anyone's interested, I've included the ASN.1 specification for the encapsulation below. Peter. -/ The basic content type. PKCS #7 defines content as a sequence of { OID, ANY DEFINED BY } and then nests one of a number of different grand unified data types (signed, enveloped, signedAndEnveloped, etc) inside this. This doesn't allow for useful extensions such as compressed data or (currently) signed then encrypted data, and has the nasty problem of a combinatorial explosion of data types (which is also endemic among other RSADSI products which use grand unified types) such as SignedAndEncryptedButNotCompressed, SignedAndEncryptedAndCompressed, SignedAndEncrypted, EncryptedAndSigned, etc etc. A neater solution is to provide at the start of the content a SEQUENCE OF ContentInfo records which define the transformations to be applied to the content. The contentInfo field encodes in one step a transformation which would normally be encoded using nested ASN.1 objects, so that for example the transformation: Sign( Compress( data )) would be encoded as: Sign, Compress( data ) The reason for trying to reduce the level of nesting as much as possible is that nested, indefinite-length ASN.1 data types are messy to encode and lead to unnecessary message expansion. This form of encapsulation is known as "logical wrapping", in which a single physical level of wrapping is used to provide the equivalent of multiple logical levels of wrapping. The sequence of ContentInfo fields encodes the progression of levels in which the data is encased. For example a contentInfo field of { Signed, Compressed } would specify that the content should be signature checked and then decompressed to recover the original data (ie the compressed data has been signed). In contrast a contentInfo field of { Compressed, Signed } would specify that the content should be decompressed and then signature checked (ie the decompressed data has been signed). This system can be used to encode arbitrary transformations on the content, with arbitrary logical nesting and an arbitrary processing order. One disadvantage of the one-size-fits-all basic content type is that two fields which are specific to two of the content types must be added. The signatures field is used for the Signed data type to contain the signatures on the data (which may be empty if the signatures are stored separately), and the padding field is used for the Encrypted data type to contain optional message padding /- Content ::= SEQUENCE { contentInfo SEQUENCE OF ContentInfo, -- Transformation to apply to the content content OCTET STRING, -- Data payload signatures [0] SET OF Signature OPTIONAL, -- Signature(s) on the data padding [1] OCTET STRING OPTIONAL -- Data padding } ContentInfo ::= CHOICE { nestedData [0] IMPLICIT NestedDataInfo, encryptedData [1] IMPLICIT EncryptedDataInfo, signedData [2] IMPLICIT SignedDataInfo, compressedData [3] IMPLICIT CompressedDataInfo, ... } -/ Nested data. This specifies that the data payload contains nested content which should be further processed. This is usually used after the encryptedData type to specify that the decrypted data should be further processed. The use of a BOOLEAN is somewhat unnecessary since the mere presence of the nestedData field is enough to convey the necessary information, however providing the field and setting the value to FALSE can also convey the information "I want to bloat up the header unnecessarily" /- NestedDataInfo ::= BOOLEAN -/ Encrypted data. The encryptionKeyInfo contains the session key and bulk data encryption algorithm details, encrypted with zero or more public or conventional key encryption keys. If the set is empty, the session key must be supplied by some other means. If the set is nonempty, the session key may be reconstructed by decrypting one of the EncryptionKeyInfo records with the appropriate private key or conventional KEK. Public and conventional KEK's may be mixed, so that a single message could be decrypted with one or more conventional and/or private keys. The IV is always present as a fixed-length string to obscure the details of the algorithm and mode being used. If necessary it is extended to more than CRYPT_MAX_IVSIZE bytes by padding to the right with 0 bits /- EncryptedDataInfo ::= SEQUENCE { encryptionKeyInfo SET OF EncryptionKeyInfo, -- Encrypted seesion key, may be empty set keyCookie [0] IMPLICIT KeyCookie OPTIONAL, -- Key cookie iv OCTET STRING (SIZE(CRYPT_MAX_IVSIZE)) -- IV } -/ Signed data. The digestAlgorithms field contains information on which types of message digest to compute for the data in order to allow the signature check to be performed once the end of the data has been reached. This is stored before the data itself to allow for one-pass processing. The signatureCookie field is used to tie the signed data to the signature or signatures associated with it if they are stored separately /- SignedDataInfo ::= SEQUENCE { digestAlgorithms DigestAlgorithmIdentifiers, -- Information on digests for sig.check signatureCookie [0] IMPLICIT SignatureCookie OPTIONAL -- Signature cookie } -/ Compressed data. This provides information on the compression algorithm used and any necessary parameters. Unfortunately the only ISO-approved algorithms are peculiar, usually patented or otherwise restricted ones (check if Zip has an OID) /- CompressedDataInfo ::= SEQUENCE { compressionAlgorithm CompressionAlgorithmIdentifier -- Compression algorithm } From chandras@loc201.tandem.com Tue Feb 4 07:44:12 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id HAA02885; Tue, 4 Feb 1997 07:44:12 -0800 Received: from eurogate.nortel.co.uk by suntan.tandem.com (8.6.12/suntan5.961027) for id HAA02881; Tue, 4 Feb 1997 07:44:09 -0800 Received: from hedera.bnr.co.uk (actually eharg1e1.nortel.co.uk) by eurogate.nortel.co.uk with SMTP (PP); Tue, 4 Feb 1997 13:08:57 +0000 Received: from bhars592.bnr.co.uk by hedera.bnr.co.uk with SMTP (PP); Mon, 3 Feb 1997 18:39:19 +0000 Received: from bwdldb.ott.bnr.ca by bhars592.bnr.co.uk with SMTP (PP); Mon, 3 Feb 1997 18:38:56 +0000 Received: by bwdldb.ott.bnr.ca with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC11D6.E00FB2D0@bwdldb.ott.bnr.ca>; Mon, 3 Feb 1997 13:33:43 -0500 Message-ID: From: Carlisle Adams To: "'wford@verisign.com'" Cc: "'ietf-pkix@tandem.com'" Subject: RE: PKCS#7 in PKIX-3 Date: Mon, 3 Feb 1997 13:32:55 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 82 TEXT Hi Warwick, >---------- >From: wford@verisign.com[SMTP:wford@verisign.com] >Sent: Friday, January 31, 1997 7:57 PM >To: ietf-pkix@tandem.com >Subject: Re: PKCS#7 in PKIX-3 > >From observation of many prior standardization activities, I suggest that >solutions built by incrementally advancing existing, accepted, >well-understood solutions have been far more successful than attempts to >define something totally new, even if the latter was technically superior. > >I believe this same feeling was supported by strong concensus in the San >Jose PKIX meeting. If PKCS#7 satisfies requirements for many people, and >some incremental extensions to PKCS#7 would satisfy requirements for >everyone, then this is clearly far more likely to be accepted as a standard >than a totally new invention such as the proposal in the December I-D. I agree with this reasoning. However, I would argue that PKCS#7 does *not* "satisfy requirements for many people", within the PKIX-3 environment, because initialization (for example) cannot be done using PKCS#7 in its current form. It does not make sense to *mandate* a protection mechanism which does not even allow you to get *started* in this protocol. What you need to do is to mandate something which *will* work, and optionally allow anything else to be used wherever it can be used. This is what PKIX-3, as currently defined, already does. Why do I think that PKCS#7 will not work for initialization? Let me dredge up an old posting: 2. (con): PKCS7 isn't well suited for cases in which one protects a message before getting allocated a name/certificate. This is important for initialization and for key recovery, where the end-entity may not know anything about itself or its environment prior to the exchange with the CA/RA. Thus, the mandatory field IssuerAndSerialNumber in SignerInfo (which is used to identify the signer's certificate) will require a new (and very liberal) interpretation in this context, meaning that existing implementations would have to be modified to deal with this situation. 3. (con): It is not at all clear how to use the PKCS7 spec. to do a MAC on a message. "Digesting" seems to apply to hashing only, and MACing does not appear to fit very well in the SignedData construct. Given that MACing is important for some operations (again, initialization and key recovery come to mind, in which the messages may be protected by a MAC based on secret out-of-band information), further specification or profiling of PKCS7 would be necessary before it could be used within PKIX-3. 4. (con): Using D-H to calculate the signature bits for a PKCS7 signedData is quite different from using RSA to sign (i.e., although it is quite possible to force the results into the same syntax, the semantics of the "encryptedDigest" field of the SignerInfo construct is entirely changed, resulting in a significant modification to existing PKCS7 implementations). Thus, for example, an existing S/MIME user agent will be very unlikely to produce the desired result. As I have said to Peter (just posted), I'm certainly willing to migrate to PKCS#7 as "the" PKIX-3 protection mechanism once it has evolved to the point where these issues are solved. But since we don't know how long a process that might be it seems pointless to hold up progression of PKIX-3 indefinitely (especially since it already does what we want, including allowing PKCS#7, as is, wherever this can be used!). > > >I would appreciate hearing opinions from other members of the list. So would I. > -------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com --------------------------------------- > From chandras@loc201.tandem.com Tue Feb 4 07:44:20 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id HAA02916; Tue, 4 Feb 1997 07:44:20 -0800 Received: from eurogate.nortel.co.uk by suntan.tandem.com (8.6.12/suntan5.961027) for id HAA02899; Tue, 4 Feb 1997 07:44:16 -0800 Received: from hedera.bnr.co.uk (actually eharg1e1.nortel.co.uk) by eurogate.nortel.co.uk with SMTP (PP); Tue, 4 Feb 1997 13:08:32 +0000 Received: from bwdldb.ott.bnr.ca by hedera.bnr.co.uk with SMTP (PP); Mon, 3 Feb 1997 18:13:59 +0000 Received: by bwdldb.ott.bnr.ca with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC11D3.7E4C6A00@bwdldb.ott.bnr.ca>; Mon, 3 Feb 1997 13:09:31 -0500 Message-ID: From: Carlisle Adams To: "'peter@verisign.com'" Cc: "'ietf-pkix%tandem.com'" Subject: RE: PKCS#7 in PKIX-3 Date: Mon, 3 Feb 1997 13:08:33 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 108 TEXT Hi, >---------- >From: peter@verisign.com[SMTP:peter@verisign.com] >Sent: Friday, January 31, 1997 2:15 PM >To: Carlisle Adams; 'housley%spyrus.com' >Cc: 'ietf-pkix%tandem.com' >Subject: RE: PKCS#7 in PKIX-3 > >Carlise: "Carlisle". > >I believe there is a better way than saying always "no, no >and no", to _actually_ open systems component technology and a world >of third-party, multi-vendor "highly re-bundlable" >key management technology. No one has accused me, anywhere, at any time, of always saying "no, no, and no" to anything without considered thought and reasoning, so I can only conclude that either you're not reading my postings or you're not understanding them. > >I want PKIX to be a useful componentware standard, not merely a >pretend std for marketing closed or proprietary technology. Every person I know in any way connected with PKIX is absolutely agreed on this point, so your implication here shows again that you may not have been following this discussion in sufficient detail... > > > >From my mailbox, and having consulted the primary players, I think >Carlise you are the only party not in consort with the proposal. Sounds like your mailbox has a selective memory because my mailbox (and the PKIX archive) suggest otherwise, but let's move on: >Id urge folk to respect the (expressed) will of the group to move >down this layering path. Precisely which wire format specs are agreed upon, >I for one dont really mind; this is not the issue for me. Id like PKCS7 as >defined now _at least_ to be indicated, and for the next generation >being developed in the IETF process with specifically these CA and other >environment's requirements in mind to be urged, and architected into >the PKIX-3 system and protocol requirements. I have no problem whatsoever with saying that when PKCS#7 is able to accommodate the requirements of the PKIX-3 environment (i.e., when it has evolved in the ways in which it needs to evolve), then it will be the preferred (perhaps the *mandated*) protection mechanism. In its current form it cannot accommodate all the requirements of the PKIX-3 environment, but it can accommodate some, so I have no problem also stating in the document that PKCS#7 may be used now wherever it is appropriate. I think that Stephen Farrell will agree with such wording (Stephen?). Note that this requires no changes at all to the current PKIX-3 protocol (i.e., PKIX-3 already supports all this, as I have been saying repeatedly); it simply requires a bit more explanatory text to make the intentions clearer. Is this something we can all live with? >So, > >Just as the Oakley key agreement spec for IPSEC asserts that use of >DNS security/certs is mandatory (despite the fact that DNS security is >neither agreed, fully finished/documented, nor ratified within its >respective WG and the IESG security area directorate) so then, >with the appropriate language, we mandate an architectural >realationship to a PKCS7-like messaging service, but not required >that all implementations have to realise it. > >just as SKIP specifies 4 cert types, not all of which need >to be implemented... > >just as IPSEC std allows a multitude of non-interoperable >security service and algoirithm profiles.... > >just as SSL/TLS allows an RSA client to fail to work with a DH-only >SSL server... Interesting. I guess I must be an "old-timer" at IETF now, because I still remember the days when interoperability was of some value to protocol designers and working groups... > >These std are real, and not pure. So PKIX-3 should be. So PKIX-3 *is*. If your point with the examples above is that other protocols allow non-interoperable options, then it is abundantly clear that PKIX-3 already has this. What Stephen and I have tried to do is to profile this activity (i.e., specify the mandatory subset of the myriad options) so that a working, interoperable protocol can be achieved. I'm guessing that if the PKIX working group does not have a set of working, interoperable protocols for certificate management then it hasn't really achieved anything. -------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com --------------------------------------- > > From chandras@loc201.tandem.com Wed Feb 5 13:25:09 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id NAA13347; Wed, 5 Feb 1997 13:25:09 -0800 Received: from verisign.com by suntan.tandem.com (8.6.12/suntan5.961027) for id NAA13342; Wed, 5 Feb 1997 13:25:08 -0800 Message-Id: <3.0.32.19970205132257.0073910c@mail> X-Sender: peter@mail X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 05 Feb 1997 13:23:02 -0800 To: pgut001@cs.auckland.ac.nz, ietf-pkix@tandem.com From: Peter Williams Subject: Re: PKCS#7 in PKIX-3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary= "---=_=_ 1113268275-6741220-12276944 _=_=---"; micalg=rsa-sha1; protocol="application/x-pkcs7-signature" -----=_=_ 1113268275-6741220-12276944 _=_=--- Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Ok, I amend my basic proposal - Im tired of debating the irrelvant PKCS7-nature issue here; the PKCS7 forums are a better place. The precise nature of PKCS7, or some alternative, is not relevant, yet (though few of the passing comments are objectively true; bias and key recovery agenda are strange subjective beasts) The whole point here is to separate protection from information. There is emerging also the need to ensure group concensus on the provision of optional or even mandatory presence of key recovey capability during PKIX key certification activities. So, I move we re-consider PKIX-3 design to ensure the necessary object protection is provided by relying upon the services of the mime multipart security types, and that any certification system specific protection requirements are abstracted out of the current spec and put into either a specification for a new "PKIX" security multiparts protocol or a PKIX-specified profile suitably combining existing available multipart services (multipart/signed, multipart/enveloped, etc) Once this separation of object and protection has occured (like for DOD's MSP and MMP equivalent problem, or Netscape use of SSL to protect their CSR messages, or MS demo of PKCS7 to protect PKCS#10 during initial subscriber enrollment), we can argue the nature of the std multipart protocol from an identified requirements standpoint. Nortel and other members of the Open Group (see APKI I-D) has indeed identified a specific claim of a requirement - to ensure mandatory and uniquitous presence of key recovery registation capabilities during public key certification activities, which neither 1424 nor MOSS were designed to guarantee. SO I can see perhaps MOSS, S/.MIME, PGP - as multpart providers- could well need to be tweaked in nesxt versions to satisfy PKIX-3 needs, if they are to be used in that context by certification systems. But lets identify and agree the needs first, and only then choose the technology. Putting mime multiparts into the architecture forces this important issue, by ensuring functional separation. It also makes practical system integration/building from std components even easier than just mandating PKCS7, say. The entire point of my argument is to obtain separation, not merely swap one specified technique for another. Reuse of what is deployed or available is obviously a major benefit, also, when weighing up the psosible approaches. Finally, if it is truely the groups intention to satisfy the PKIX APKI I-Ds requirements to mandate key recovery capability on any and all key certification implementations conforming to PKIX, for all deployments across the Internet, then we can make a positive affimration of this design requirement and analyse adequacy of either a single method (e.g. the Entrust approach already built into PKIX-3), or a framework for enabling multiple providers and technology approaches to perform mandatory key recovery/escrow functions. I dont want this mandatory key recovery thing pushed in by default; its too sensitive a political issue. A nice sideeffect of my argument, is that during the separation process, the need for this as a mandatory requirements is questioned, and can be agreed upon explicitely. If its mandatory, then we can ensure the multipart protection environment really enforces the escrow requirement. Given the feedback to my iniative (which fell out of reading the minutes of montreal and san jose IETF WG sessions), hopefully I've updated and moved the issue forward. A few issues have fallen out additionally upon reflection and comment (particularly the escrow topic), and we might really try to reuse the multiparts stuff as a middle-ground approach. It certainly hurts noone, and gets the job done nicely without lots of room for future flexiblity. That PKCS7 can be one multiparts provider brings us round to the original suggestion and motive, but now the topic is more refined and flexible, embracing more players and technology approaches. At 09:47 PM 2/4/97, Peter Gutmann wrote: >Death Rays from Mars made Housley, Russ write: > >>I think that we are near concensus on this point. A single encapsulation >>mechanism would be ideal. PKIX Part 3 contains one suggestion, and PKCS #7 >>contains another. Carlise provided an analysis for the PKIX Part 3 approach. >>PKCS #7 has a market share that should not be ignored, and the specification >>is open for reivew and update. > >Just to further muddy the water, I've been using a format which is (IMHO) an >improvement on PKCS #7 (it fixes a few problems in the PKCS format and is >easier to use). In case anyone's interested, I've included the ASN.1 >specification for the encapsulation below. > >Peter. > >-/ The basic content type. PKCS #7 defines content as a sequence of { OID, > ANY DEFINED BY } and then nests one of a number of different grand unified > data types (signed, enveloped, signedAndEnveloped, etc) inside this. This > doesn't allow for useful extensions such as compressed data or (currently) > signed then encrypted data, and has the nasty problem of a combinatorial > explosion of data types (which is also endemic among other RSADSI products > which use grand unified types) such as SignedAndEncryptedButNotCompressed, > SignedAndEncryptedAndCompressed, SignedAndEncrypted, EncryptedAndSigned, > etc etc. A neater solution is to provide at the start of the content a > SEQUENCE OF ContentInfo records which define the transformations to be > applied to the content. The contentInfo field encodes in one step a > transformation which would normally be encoded using nested ASN.1 objects, > so that for example the transformation: > > Sign( Compress( data )) > > would be encoded as: > > Sign, Compress( data ) > > The reason for trying to reduce the level of nesting as much as possible > is that nested, indefinite-length ASN.1 data types are messy to encode and > lead to unnecessary message expansion. This form of encapsulation is > known as "logical wrapping", in which a single physical level of wrapping > is used to provide the equivalent of multiple logical levels of wrapping. > > The sequence of ContentInfo fields encodes the progression of levels in > which the data is encased. For example a contentInfo field of { Signed, > Compressed } would specify that the content should be signature checked > and then decompressed to recover the original data (ie the compressed data > has been signed). In contrast a contentInfo field of { Compressed, Signed > } would specify that the content should be decompressed and then signature > checked (ie the decompressed data has been signed). > > This system can be used to encode arbitrary transformations on the > content, with arbitrary logical nesting and an arbitrary processing order. > > One disadvantage of the one-size-fits-all basic content type is that two > fields which are specific to two of the content types must be added. The > signatures field is used for the Signed data type to contain the > signatures on the data (which may be empty if the signatures are stored > separately), and the padding field is used for the Encrypted data type to > contain optional message padding /- > >Content ::= SEQUENCE { > contentInfo SEQUENCE OF ContentInfo, > -- Transformation to apply to the content > content OCTET STRING, -- Data payload > signatures [0] SET OF Signature OPTIONAL, -- Signature(s) on the data > padding [1] OCTET STRING OPTIONAL -- Data padding > } > >ContentInfo ::= CHOICE { > nestedData [0] IMPLICIT NestedDataInfo, > encryptedData > [1] IMPLICIT EncryptedDataInfo, > signedData [2] IMPLICIT SignedDataInfo, > compressedData > [3] IMPLICIT CompressedDataInfo, > ... > } > >-/ Nested data. This specifies that the data payload contains nested content > which should be further processed. This is usually used after the > encryptedData type to specify that the decrypted data should be further > processed. The use of a BOOLEAN is somewhat unnecessary since the mere > presence of the nestedData field is enough to convey the necessary > information, however providing the field and setting the value to FALSE > can also convey the information "I want to bloat up the header > unnecessarily" /- > >NestedDataInfo ::= BOOLEAN > >-/ Encrypted data. The encryptionKeyInfo contains the session key and bulk > data encryption algorithm details, encrypted with zero or more public or > conventional key encryption keys. If the set is empty, the session key > must be supplied by some other means. If the set is nonempty, the session > key may be reconstructed by decrypting one of the EncryptionKeyInfo > records with the appropriate private key or conventional KEK. Public and > conventional KEK's may be mixed, so that a single message could be > decrypted with one or more conventional and/or private keys. > > The IV is always present as a fixed-length string to obscure the details > of the algorithm and mode being used. If necessary it is extended to more > than CRYPT_MAX_IVSIZE bytes by padding to the right with 0 bits /- > >EncryptedDataInfo ::= SEQUENCE { > encryptionKeyInfo > SET OF EncryptionKeyInfo, > -- Encrypted seesion key, may be empty set > keyCookie [0] IMPLICIT KeyCookie OPTIONAL, -- Key cookie > iv OCTET STRING (SIZE(CRYPT_MAX_IVSIZE)) -- IV > } > >-/ Signed data. The digestAlgorithms field contains information on which > types of message digest to compute for the data in order to allow the > signature check to be performed once the end of the data has been reached. > This is stored before the data itself to allow for one-pass processing. > The signatureCookie field is used to tie the signed data to the signature > or signatures associated with it if they are stored separately /- > >SignedDataInfo ::= SEQUENCE { > digestAlgorithms > DigestAlgorithmIdentifiers, > -- Information on digests for sig.check > signatureCookie > [0] IMPLICIT SignatureCookie OPTIONAL -- Signature cookie > } > >-/ Compressed data. This provides information on the compression algorithm > used and any necessary parameters. Unfortunately the only ISO-approved > algorithms are peculiar, usually patented or otherwise restricted ones > (check if Zip has an OID) /- > >CompressedDataInfo ::= SEQUENCE { > compressionAlgorithm > CompressionAlgorithmIdentifier -- Compression algorithm > } > > > -----=_=_ 1113268275-6741220-12276944 _=_=--- Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIAwggFI MIHzAgRXh90yMA0GCSqGSIb3DQEBBAUAMC4xLDAqBgNVBAMUI1BldGVyIFdpbGxpYW1zIDxw ZXRlckB2ZXJpc2lnbi5jb20+MB4XDTk3MDExNjAxNDE0M1oXDTk5MDExNjAxNDE0MlowLjEs MCoGA1UEAxQjUGV0ZXIgV2lsbGlhbXMgPHBldGVyQHZlcmlzaWduLmNvbT4wXDANBgkqhkiG 9w0BAQEFAANLADBIAkEAqdB5O+ukPCpf6r7BeHbR6pCc1n5XyxkfJtQ5UmqKZRAivlabdf8V 5hoD/HspVZiLJE5aKBGwX1mzUpRSmzRfwQIDAQABMA0GCSqGSIb3DQEBBAUAA0EAiNwkmpNi cyyF2/dy+/cN9GApTiGzEJsv7C4r/YKEWxdA7pA+ZDTG1Jawra1bnlL4JACjjYcnSFOHJNiH MsJucQAAMYAwgfYCAQEwNjAuMSwwKgYDVQQDFCNQZXRlciBXaWxsaWFtcyA8cGV0ZXJAdmVy aXNpZ24uY29tPgIEV4fdMjAJBgUrDgMCGgUAoF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNOTcwMjA1MjEyMzAyWjAjBgkqhkiG9w0BCQQxFgQUgEESuBc1 uYqUjTb0joJVIPjZxtcwDQYJKoZIhvcNAQEBBQAEQJk1RZZdCPxsY+r4OVRc/0UdR0q+ppRw qn6l2Gb6vjhTxVYY3PfOqljgH2t2nXud7BcACIRvj2YanFMSMVq52pAAAAAAAAAAAA== -----=_=_ 1113268275-6741220-12276944 _=_=----- From chandras@loc201.tandem.com Thu Feb 6 11:02:40 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id LAA14569; Thu, 6 Feb 1997 11:02:40 -0800 Received: from pop.sneaker.net by suntan.tandem.com (8.6.12/suntan5.961027) for id LAA14560; Thu, 6 Feb 1997 11:02:37 -0800 Received: from [139.167.130.247] (ext-async-2.leftbank.com [139.167.130.247]) by pop.sneaker.net (8.7.5/8.7.3) with ESMTP id NAA15443; Thu, 6 Feb 1997 13:32:42 -0500 (EST) X-Sender: rah@atanda.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 6 Feb 1997 13:32:28 -0500 To: FC97.Distribution@shipwright.com From: Robert Hettinga Subject: My apologies... I'm very sorry. I just committed a major breach of nettiquette. I just accidentally sent out the last FC97 Revised Program to this monsterous cc list, instead of using the bcc: field. Again, please my most sincere apologies. Cheers, Bob Hettinga ----------------- Robert Hettinga (rah@shipwright.com), Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "Never attribute to conspiracy what can be explained by stupidity." -- Jerry Pournelle The e$ Home Page: http://www.shipwright.com/rah/ FC97: Anguilla, anyone? http://www.ai/fc97/ From chandras@loc201.tandem.com Thu Feb 6 10:58:32 1997 Received: by suntan.tandem.com (8.6.12/suntan5.961027) for ietf-pkix-relay id KAA13885; Thu, 6 Feb 1997 10:58:32 -0800 Received: from pop.sneaker.net by suntan.tandem.com (8.6.12/suntan5.961027) for id KAA13847; Thu, 6 Feb 1997 10:58:23 -0800 Received: from [139.167.130.247] (ext-async-2.leftbank.com [139.167.130.247]) by pop.sneaker.net (8.7.5/8.7.3) with ESMTP id NAA15302; Thu, 6 Feb 1997 13:13:24 -0500 (EST) X-Sender: rah@atanda.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 6 Feb 1997 13:12:35 -0500 To: FC97 Distribution From: Robert Hettinga Subject: revised FC97 program Cc: cypherpunks@toad.com, coderpunks@toad.com, cryptography@c2.net, mac-crypto@thumper.vmeng.com, micropay@ai.mit.edu, dcsb@ai.mit.edu, "stewart alsop" , wordy@qualcomm.com (Steve Roberts), ace@tidbits.com (Adam C. Engst), "Nicholas Petreley" , Frank.March@vuw.ac.nz, cwiltgen@apple.com (Charles Wiltgen), Tony Rich , peggy@unicom.net (Peggy Enes), budil@uiuc.edu (Jonathan Budil), abrown@vnet.ibm.com, Gibo , "bob kayne" , chrish@tnf.com, maryniak@ocean.rutgers.edu, burt@binah.cc.brandeis.edu (John Burt), MFrese@aol.com, nevin@novation.com (Nevin Summers), Vincent Cate , "Mark A. McCarren" <102361.3331@compuserve.com>, Mark Tenney , "Stephen Humphrey" , "Paul M. Jones" , kkahre@artquest.com (Kathy Kahre), isig@bcs.org, Robert Seidman , ifca@thumper.vmeng.com, LMoorhouse@aol.com, AustrianECON@agoric.com, com-priv@lists.psi.com, "Richard Lonergan, VISA International" <74511.475@compuserve.com>, "John Matonis, Verisign" <74774.3663@compuserve.com>, "Colin Crook, Citicorp" , "David G.W. Birch, Hyperion, Inc." , "Frank Trotter, Mark Twain Bank" , "Art Hutchinson, Northeast Consulting Resources" , "John Curran, BBN Planet" , "Jeff Sutherland, Individual, Inc." , "Kathryn Szot, Bell Atlantic" , "Ken Rodrigues, Open Software Foundation" , "Keiji Kono, Bank of Japan" , "Ed Kozel, Cisco" , "Lee Stein, First Virtual" , "Marty Stein, Bank of America" , , "Philip Zimmermann, PGP, Inc." , "Daya Puls, Digital", "Steven Willis, Bay Networks" , "Tom Wills, CommerceNet" , " Andy Klein, Spring Street Brewing" , "Donald Eastlake, Cybercash" , "Dan Eldridge, Digicash" , "David Saul, State Street Bank" , "Frank Jaffe, FSTC Electronic Check Project" , "Jeff Bussgang, Open Market" , "Jim Philips, Security First Network Bank" , CYBERIA-L@LISTSERV.AOL.COM, e-payments@commerce.net, ecash-dev@digicash.com, dev-lucre@c2.net, dh-l@lists.io.com, emv@austin.asc.slb.com, ibc-forum@ARRAYdev.com, information-economics@acid.base.com, net-thinkers@thumper.vmeng.com, pgp-users@rivertown.net, set-dev@terisa.com, semper-talk@hoernli.zurich.ibm.ch, e-payment@bellcore.com, ietf-pkix@tandem.com, www-security@ns2.rutgers.edu, fc97@offshore.com.ai, fc97@thumper.vmeng.com, biz.daffaire@global-link.net (Business D'Affaire) --- begin forwarded text Sender: e$@thumper.vmeng.com Reply-To: R.Hirschfeld@cwi.nl Precedence: Bulk Date: Thu, 6 Feb 1997 18:33:11 +0100 From: R.Hirschfeld@cwi.nl To: Multiple recipients of Subject: revised FC97 program Financial Cryptography '97 February 24-28 1997, Anguilla, BWI PRELIMINARY PROGRAM (Revised 6 February 1997) General Information: Financial Cryptography '97 (FC97) is a new conference on the security of digital financial transactions. The first meeting will be held on the island of Anguilla in the British West Indies on February 24-28, 1997. FC97 aims to bring together persons involved in both the financial and data security fields to foster cooperation and exchange of ideas. Original papers were solicited on all aspects of financial data security and digital commerce in general. Program Committee: Matthew Franklin, AT&T Laboratories--Research, Murray Hill, NJ, USA Michael Froomkin, U. Miami School of Law, Coral Gables, FL, USA Rafael Hirschfeld (Program Chair), CWI, Amsterdam, The Netherlands Arjen Lenstra, Citibank, New York, NY, USA Mark Manasse, Digital Equipment Corporation, Palo Alto, CA, USA Kevin McCurley, Sandia Laboratories, Albuquerque, NM, USA Charles Merrill, McCarter & English, Newark, NJ, USA Clifford Neuman, Information Sciences Institute, Marina del Rey, CA, USA Sholom Rosen, Citibank, New York, NY, USA Israel Sendrovic, Federal Reserve Bank of New York, New York, NY, USA Preliminary Conference Program for FC97: Monday 24 February 1997 800 -- 820 Breakfast 820 -- 830 Welcome 830 -- 905 Anonymity Control in E-Cash Systems George Davida (University of Wisconsin, Milwaukee, WI, USA), Yair Frankel (Sandia National Laboratories, Albuquerque, NM, USA), Yiannis Tsiounis (Northeastern University, Boston, MA, USA), Moti Yung (CertCo, New York, NY, USA) 905 -- 940 How to Make Personalized Web Browsing Simple, Secure, and Anonymous Eran Gabber, Phil Gibbons, Yossi Matias, Alain Mayer (Bell Laboratories, Lucent Technologies) 940 -- 1015 Anonymous Networking and Virtual Intranets: Tools for Anonymous Corporations Jim McCoy (Electric Communities, Cupertino, CA, USA) 1015 -- 1045 Coffee Break 1045 -- 1120 Unlinkable Serial Transactions Paul F. Syverson (Naval Research Laboratory, Washington, DC, USA), Stuart G. Stubblebine (AT&T Labs--Research, Murray Hill, NJ, USA), David M. Goldschlag (Naval Research Laboratory, Washington, DC, USA) 1120 -- 1155 Efficient Electronic Cash with Restricted Privacy Cristian Radu, Rene Govaerts, Joos Vandewalle (Katholieke Universiteit Leuven, Leuven, Belgium) 1155 -- 1230 The SPEED Cipher Yuliang Zheng (Monash University, Melbourne, Australia) 1230 -- 1330 Lunch 1800 -- 1930 Cocktail Reception (at Mariners Hotel) Tuesday 25 February 1997 800 -- 830 Breakfast 830 -- 930 Invited Speaker Evaluating the security of electronic money; the view of a European central bank Simon L. Lelieveldt (De Nederlandsche Bank, Amsterdam, Netherlands) 930 -- 1005 Smart Cards and Superhighways The technology-driven denationalisation of money David G.W. Birch, Neil A. McEvoy (Hyperion, Surrey, England) 1005 -- 1045 Coffee Break 1045 -- 1120 Fault Induction Attacks, Tamper Resistance, and Hostile Reverse Engineering in Perspective David P. Maher (AT&T Labs--Research, Murray Hill, NJ, USA) 1120 -- 1155 Some Critical Remarks on "Dynamic Data Authentication" as specified in EMV '96 Louis C. Guillou (CCETT, Cesson-Sevigne, France) 1155 -- 1230 Single-chip implementation of a cryptosystem for financial applications Nikolaus Lange (SICAN Braunschweig GmbH, Braunschweig, Germany) 1230 -- 1330 Lunch Wednesday 26 February 1997 800 -- 830 Breakfast 830 -- 930 Invited Speaker Ronald Rivest (MIT Lab for Computer Science, Cambridge, MA, USA) 930 -- 1005 Auditable Metering with Lightweight Security Matthew K. Franklin, Dahlia Malkhi (AT&T Labs--Research, Murray Hill, NJ, USA) 1005 -- 1045 Coffee Break 1045 -- 1120 SVP: a Flexible Micropayment Scheme Jacques Stern, Serge Vaudenay (Ecole Normale Superieure, Paris, France) 1120 -- 1155 An efficient micropayment system based on probabilistic polling Stanislaw Jarecki (MIT Lab for Computer Science, Cambridge, MA, USA), Andrew Odlyzko (AT&T Labs--Research, Murray Hill, NJ, USA) 1155 -- 1230 On the continuum between on-line and off-line e-cash systems - I Yacov Yacobi (Microsoft, Redmond, WA, USA) 1230 -- 1330 Lunch Thursday 27 February 1997 800 -- 830 Breakfast 830 -- 905 Towards Multiple-payment Schemes for Digital Money H. Pagnia, R. Jansen (University of Darmstadt, Darmstadt, Germany) 905 -- 940 Applying Anti-Trust Policies to Increase Trust in a Versatile E-Money System Markus Jakobsson (UCSD, La Jolla, CA, USA), Moti Yung (BTEC/CertCo, New York, NY, USA) 940 -- 1015 Cyberbanking and Privacy: The Contracts Model Peter P. Swire (Ohio State University, Columbus, OH, USA) 1015 -- 1045 Coffee Break 1045 -- 1120 Legal Issues in Cryptography Edward J. Radlo (Fenwick & West LLP, Palo Alto, CA, USA) 1120 -- 1230 Panel Discussion Legal Issues of Digital Signatures Michael Froomkin (U. of Miami School of Law, Coral Gables, FL, USA), Charles Merrill (McCarter & English, Newark, NJ, USA), Benjamin Wright (Dallas, TX, USA) 1230 -- 1330 Lunch 1930 -- 2015 Invited Speaker Money Laundering: Yesterday, Today and Tomorrow Peter Wayner (Baltimore, MD, USA) 2015 -- 2200 Rump Session Friday 28 February 1997 800 -- 830 Breakfast 830 -- 905 The Strategic Role of Government in Electronic Commerce Paul Lampru (Verifone, Atlanta, GA, USA) 905 -- 940 Using Markets to Achieve Efficient Task Distribution Ian Grigg, Christopher C. Petro (Systemics, Amsterdam, Netherlands) 940 -- 1015 The Gateway Security Model in the Java Electronic Commerce Framework Theodore Goldstein (Sun Microsystems Laboratories/Javasoft) 1015 -- 1045 Coffee Break 1045 -- 1120 Highly Scalable On-line Payments Via Task Decoupling David William Kravitz (CertCo LLC, Albuquerque, NM, USA) 1120 -- 1155 GUMP; Grand Unified Meta-Protocols Recipes for Simple, Standards-based Financial Cryptography Barbara Fox, Brian Beckman (Microsoft, Redmond, WA, USA) 1155 -- 1230 Secure Network Communications and Secure Store&Forward Mechanisms with SAP R/3 Bernhard Esslinger (SAP AG, Walldorf, Germany) 1230 -- 1330 Lunch Updates of the conference schedule will be available at the URL http://www.cwi.nl/conferences/FC97/. The conference will run from 8:30 AM to 12:30 PM for five days, February 24-28 1997. Breakfast and lunch are provided at the conference. The conference organizers have left the afternoons and evenings open for corporate sponsored events, for networking, and for recreational activities on the resort island of Anguilla. Participants are encouraged to bring their families. Workshop: A 40-hour workshop, intended for anyone with commercial software development experience who wants hands-on familiarity with the issues and technology of financial cryptography, is planned in conjunction with FC97, to be held during the week preceding the conference. For more information on the workshop, please see the URL http://www.cs.berkeley.edu/~iang/fc97/workshop.html. For workshop registration, see the URL http://www.offshore.com.ai/fc97/. Venue: The InterIsland Hotel is a small 14-room guest house and a large, comfortable 150 seat conference facility with additional space for a small 10-booth exhibition. The Inter-Island is on Road Bay, near Sandy Ground Village, in the South Hill section of Anguilla. The conference, workshop, and exhibition will have TCP/IP internet access. The rooms at the InterIsland itself have sold out, but there are many other hotels and guest houses on Anguilla, and shuttle service to the conference will be available. Air Transportation and Hotels: Air travel to Anguilla is typically done through either San Juan or St. Thomas for US flights, or St. Maarten/Martin for flights from Europe and the US. Anguillan import duties are not imposed on hardware or software which will leave the island again. There are no other taxes--or cryptography import/export restrictions--on Anguilla. Hotels range from spartan to luxurious, and more information about hotels on Anguilla can be obtained from your travel agent, or at the URL http://www.offshore.com.ai/fc97/. General Chairs: Robert Hettinga, Shipwright/e$, Boston, MA, USA; rah@shipwright.com Vincent Cate, Offshore Information Services, Anguilla, BWI; vince@offshore.com.ai Conference, Exhibits, and Sponsorship Manager: Julie Rackliffe, Boston, MA, USA; rackliffe@tcm.org Workshop Leader: Ian Goldberg, Berkeley, CA, USA; iang@cs.berkeley.edu Registration: You can register and pay for conference admission via the World Wide Web at the URL http://www.offshore.com.ai/fc97/. The cost of the FC97 Conference is US$1,000. Booths for the exhibition start at US$5,000 and include two conference tickets. For more information about exhibit space, contact Julie Rackliffe, rackliffe@tcm.org. Sponsorship opportunities for FC97 are still available. The cost of the workshop is US$5000, and includes meals but not lodging. You can register for the workshop, which runs the week prior to the conference, at the URL http://www.offshore.com.ai/fc97. Financial Cryptography '97 is held in cooperation with the International Association for Cryptologic Research. It is sponsored by: The Journal for Internet Banking and Commerce Offshore Information Services e$ C2NET See Your Name Here --- end forwarded text ----------------- Robert Hettinga (rah@shipwright.com), Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "Never attribute to conspiracy what can be explained by stupidity." -- Jerry Pournelle The e$ Home Page: http://www.shipwright.com/rah/ FC97: Anguilla, anyone? http://www.ai/fc97/ From chandras@loc201.tandem.com Wed Feb 12 17:29:54 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id RAA00256; Wed, 12 Feb 1997 17:29:54 -0800 Received: from mailsrvr.az05.bull.com by suntan.tandem.com (8.6.12/suntan5.970212) for id RAA00247; Wed, 12 Feb 1997 17:29:51 -0800 Received: from smtplink.az05.bull.com (smtplink.az05.bull.com [141.112.29.62]) by mailsrvr.az05.bull.com (8.6.8.1/8.6.6) with SMTP id SAA28460; Wed, 12 Feb 1997 18:08:40 -0700 Received: from ccMail by smtplink.az05.bull.com (IMA Internet Exchange 2.02 Enterprise) id 30269470; Wed, 12 Feb 97 18:07:19 -0700 Mime-Version: 1.0 Date: Wed, 12 Feb 1997 18:07:27 -0700 Message-ID: <30269470.@smtplink.az05.bull.com> From: H.Kesterson@az05.bull.com (KESTERSON.H) Subject: new address for OSIdirectory server To: OSIdirectory@az05.bull.com, ietf-pkix@tandem.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part the services previously accessed on NC-17 have been split across two systems. unfortunately, i do not get to stay on the system with the neat name. the x.500 documents are now at a system with a descriptive, but somewhat mundane, name of ftp.bull.com ftp://ftp.bull.com/pub/OSIdirectory hoyt From chandras@loc201.tandem.com Thu Feb 13 11:59:13 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id LAA17251; Thu, 13 Feb 1997 11:59:13 -0800 Received: from mail.thecia.net by suntan.tandem.com (8.6.12/suntan5.970212) for id LAA17225; Thu, 13 Feb 1997 11:59:07 -0800 Received: from ire-boston (ire-ma.com.db.196.50.207.in-addr.arpa [207.50.196.253]) by mail.thecia.net (8.7.5/8.7.5) with SMTP id PAA16949 for ; Thu, 13 Feb 1997 15:29:15 -0500 (EST) Received: from [199.34.57.33] by ire-boston (NTMail 3.01.03) id ma001052; Thu, 13 Feb 1997 20:06:01 +0000 Received: by cwelles.ire-ma.com with MAPI via OpenSoft ExpressMail id MSG970213134104#11@cwelles.ire-ma.com; Thu, 13 Feb 1997 14:41:03 +0000 Date: Thu, 13 Feb 1997 14:41:03 +0000 Message-Id: MSG970213134104#11@cwelles.ire-ma.com X-Mailer: OpenSoft ExpressMail Version 1.0 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: cwelles@ire-ma.com (Christopher Welles) To: ietf-pkix@tandem.com ('ietf-pkix@tandem.com') Cc: malix@ire-ma.com (Margaret Alix) Subject: Bug in PKIX1-3 DSA OIDs? Content-Type: text/plain; charset="us-ascii" X-Info: Evaluation version at ire-boston In the course of testing the interoperability of some certificate generation software, we came across a peculiarity in PKIX1-3's definition of DSA algorithm object IDs. draft-ietf-pkix-ipki-part1-03.txt (12/96) has the following object ID (OID) definitions for DSA algorithms: id-dsa-with-sha1 ID ::= { iso(1) member-body(2) us(840) x9-57(10040) secsig(2) x9algorithm(4) 3} -- DSA signature algorithm and id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040) secsig(2) x9algorithm(4) 1} -- DSA signature key On the other hand, Appendix C of X9.57 (June, 1996) has the following definitions: x9cm ID ::= { iso(1) member-body(2) us(840) x9-57(10040) } x9algorithm ::= {x9cm 4} id-dsa-with-sha1 ::= { x9algorithm 3} id-dsa ::= { x9algorithm 1} It seems odd that PKIX1-3 would give different values for the same OID names from X9.57. Is the interpolation of the "secsig (2)" node in PKIX1-3 a bug, or is there a method to this madness? - Chris Welles From chandras@loc201.tandem.com Wed Feb 19 04:32:24 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id EAA12077; Wed, 19 Feb 1997 04:32:24 -0800 Received: from relay3.UU.NET by suntan.tandem.com (8.6.12/suntan5.970212) for id EAA12061; Wed, 19 Feb 1997 04:32:01 -0800 Received: from clbull.frcl.bull.fr by relay3.UU.NET with ESMTP (peer crosschecked as: [129.182.1.17]) id QQcdok09743; Wed, 19 Feb 1997 07:31:56 -0500 (EST) Received: from dore (dore.frcl.bull.fr [129.182.42.156]) by clbull.frcl.bull.fr (8.7.5/8.7.3) with SMTP id NAA46648 for ; Wed, 19 Feb 1997 13:22:31 +0100 Received: from dese22 by dore (AIX 4.1/UCB 5.64/4.03) id AA30902; Wed, 19 Feb 1997 13:29:07 +0100 Message-Id: <330B7113.2B59@frcl.bull.fr> Date: Wed, 19 Feb 1997 13:30:59 -0800 From: Denis Pinkas Reply-To: D.Pinkas@frcl.bull.fr Organization: Bull X-Mailer: Mozilla 3.0 (Win16; I) Mime-Version: 1.0 To: ietf-pkix@tandem.com Subject: Private key possession Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Topic: Private key possession. At the last PKIX meeting we had some discussion to say that each CA SHALL verify the possession of the private key by the user before issuing a certificate containing the corresponding public key. I would like to show that, while this is desirable, it does not solve all problems, in particular the problem of steeling a signature from some one else. Let us take the following example: Alice wishes to apply for a patent today and for doing so signs the text of the patent using its private key, attach to it its certificate and send the two pieces to a patent office. When receiving the two pieces, the patent office would place a counter-signature from a Trusted Time Stamping Authority on the whole package so that one can make sure that the registration date is correct. Since Bob intercepted the message from Alice, the patent office did not received Alice's message at this time. Bob promptly asks to a CA located in Barracuda (in the Republic of Banana) to issue a certificate containing the same public key as Alice but with his name in it. For a reasonable fee the CA omits to verify the possession of the private key by the user before issuing the certificate. Thereafter Bob sends the intercepted signed text of the patent and replaces Alice's certificate by his new own certificate. When receiving the two pieces, the patent office places a counter-signature from a Trusted Time Stamping Authority on the whole package so that one can make sure that the registration date is correct. In such a scenario Bob would now the patent holder. If for some reason Alice re-sends her message it will be time-stamped after the message from Bob and she will not be recognized as the patent holder. Of course there are several ways to counter that threat, one of them being to use a confidentiality service between the patent requester and the patent office, but relying on the existence of a confidentiality service is not a good practice, since the fraud could even occur by an employee of the patent office after the decryption of the message. The general way to solve the problem is to include enough information within the signed text to identify unambiguously the signer. In the case of Alice and Bob, including Alice's name would work nicely but what happens for a name like Mike Walker ? How can we differentiate two people with the same name ? Using the address would be one response, using the company name would be another one. But this would mandate to look at the semantic of the message and thus this would prevent the automation of the verification procedure. A more general solution is to reserve some place within the signed text to insert at least the identifier of the certificate. The best being to insert a certification path. Let us now reconsider a variation of the same scenario : Alice wishes to apply for a patent today and for doing so signs both the text of the patent and a certification path using its private key, and sends that single signed piece of information to a patent office. When receiving that piece, the patent office places a counter-signature from a Trusted Time Stamping Authority on it so that one can make sure that the registration date is correct. Since the certification path is signed, Bob cannot do anything this time. This rather long story is there to illustrate the fact that asking each CA to verify the possession of the private by the user implies a model where every CA over the world would be trusted to do this correctly. I do not believe that such a model is practical. So we have to recognize that we have to live with cases where that trust cannot be placed and thus to adopt the appropriate measures to deal without it. The conclusion is that each CA SHOULD verify the possession of the private by the user before issuing a certificate containing the corresponding public key. As a consequence, this means that having a protocol to verify the possession of a private signature key shall not be mandatory and if we defined one, it should only be optionally supported. Denis Note: I have analyzed the problem for a signature key, but not for an encryption key. -- Denis Pinkas Bull S.A. E-mail : D.Pinkas@frcl.bull.fr Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 From chandras@loc201.tandem.com Wed Feb 19 06:37:06 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id GAA27216; Wed, 19 Feb 1997 06:37:06 -0800 Received: from mailgate32 by suntan.tandem.com (8.6.12/suntan5.970212) for id GAA27211; Wed, 19 Feb 1997 06:37:05 -0800 Received: by mailgate32 (SMI-8.6/SMI-SVR4) id GAA29788; Wed, 19 Feb 1997 06:37:43 -0800 Received: from sdn-ts-001mabostp10.dialsprint.net(206.133.32.29) by mailfep3-hme1 via smap (KC5.24) id Q_10.1.1.8/Q_10607_1_330b0fe5; Wed Feb 19 06:36:21 1997 Message-Id: <2.2.32.19970219173826.006e1aa4@pop.a001.sprintmail.com> X-Sender: wford@pop.a001.sprintmail.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Feb 1997 09:38:26 -0800 To: ietf-pkix@tandem.com From: Warwick Ford Subject: Memphis PKIX Meeting The PKIX meeting has been scheduled as follows: Monday, April 7 at 0930 (opposite ngtrans, disman, mobileip) Tuesday, April 8 at 0900 (opposite rmonmib, ion) The main agenda topics, so far, are review of progress on the PKIX Part 1, Part 2, Part 3, and Part 4 drafts. Please advise any other topics you believe should be included on the agenda. Warwick --------------------------------------------------------------------- Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 --------------------------------------------------------------------- From chandras@loc201.tandem.com Wed Feb 19 07:25:37 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id HAA04051; Wed, 19 Feb 1997 07:25:37 -0800 Received: from guardian.guard.ncsc.mil by suntan.tandem.com (8.6.12/suntan5.970212) for id HAA04048; Wed, 19 Feb 1997 07:25:36 -0800 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id KAA00612 for ; Wed, 19 Feb 1997 10:25:09 -0500 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma000608; Wed Feb 19 10:25:06 1997 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id KAA16682 for ; Wed, 19 Feb 1997 10:22:14 -0500 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id KAA16394; Wed, 19 Feb 1997 10:24:45 -0500 Date: Wed, 19 Feb 1997 10:24:45 -0500 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199702191524.KAA16394@argon.ncsc.mil> To: ietf-pkix@tandem.com Subject: Re: Private key possession X-Sun-Charset: US-ASCII > From: Denis Pinkas > > [patent timestamping scenario snipped] > > I do not believe that such a model is practical. So we have to > recognize that we have to live with cases where that trust cannot be > placed and thus to adopt the appropriate measures to deal without it. > > The conclusion is that each CA SHOULD verify the possession of the > private by the user before issuing a certificate containing the > corresponding public key. > > As a consequence, this means that having a protocol to verify the > possession of a private signature key shall not be mandatory and if we > defined one, it should only be optionally supported. Denis, Very nice story and analysis. However I don't agree that the conclusion follows from the analysis. In the U.S. state of Maryland, it is illegal to drive without a seat belt (you can be given a ticket for that offense even in the absense of some other offense, like speeding). However, if you are injured in an accident due to not wearing a seat belt, the insurance company cannot refuse to pay the medical bills just because you contributed to your injuries. In other words, the system recognizes and deals with the fact that not everyone will comply with the seat-belt requirement, yet that requirement is still mandatory. I believe that the protocol standard should REQUIRE CAs to verify possession of the private key, even given the existence of CAs who, for a reasonable fee, will ignore the standard. From chandras@loc201.tandem.com Wed Feb 19 07:36:12 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id HAA05409; Wed, 19 Feb 1997 07:36:12 -0800 Received: from dtol.com by suntan.tandem.com (8.6.12/suntan5.970212) for id HAA05363; Wed, 19 Feb 1997 07:35:58 -0800 Received: from bwdldb.ott.bnr.ca (dialup2 [206.51.1.102]) by dtol.com (8.6.12/8.6.9) with SMTP id LAA03076 for ; Wed, 19 Feb 1997 11:32:18 GMT Received: by bwdldb.ott.bnr.ca with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC1E4D.31D4B570@bwdldb.ott.bnr.ca>; Wed, 19 Feb 1997 10:10:55 -0500 Message-ID: From: Carlisle Adams To: "'D.Pinkas@frcl.bull.fr'" Cc: "'ietf-pkix@tandem.com'" Subject: RE: Private key possession Date: Wed, 19 Feb 1997 10:09:27 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 37 TEXT Hi Denis, >---------- >From: D.Pinkas@frcl.bull.fr[SMTP:D.Pinkas@frcl.bull.fr] >Sent: Wednesday, February 19, 1997 4:30 PM >To: ietf-pkix@tandem.com >Subject: Private key possession > >Topic: Private key possession. > (...stuff deleted...) > >The conclusion is that each CA SHOULD verify the possession of the >private by the user before issuing a certificate containing the >corresponding public key. > >As a consequence, this means that having a protocol to verify the >possession of a private signature key shall not be mandatory and if we >defined one, it should only be optionally supported. It is amazing to me that you could possibly reach this conclusion after the scenario you just described. Making the verification of the possession of the private key OPTIONAL (or not defining it at all) is *precisely* what allows such a problem to occur. Making it MANDATORY, so that every end entity and every CA must comply with the rules in order to complete the protocol, is what prevents such a problem (which is why we concluded that it must be mandatory in the first place!). By the way, if you're not going to trust a CA to do this part of certification correctly, why in the world would you trust it to do any other part of certification correctly? -------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com --------------------------------------- From chandras@loc201.tandem.com Wed Feb 19 09:03:47 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id JAA19485; Wed, 19 Feb 1997 09:03:47 -0800 Received: from relay7.UU.NET by suntan.tandem.com (8.6.12/suntan5.970212) for id JAA19435; Wed, 19 Feb 1997 09:03:24 -0800 Received: from clbull.frcl.bull.fr by relay7.UU.NET with ESMTP (peer crosschecked as: clbull.frcl.bull.fr [129.182.1.17]) id QQcdpc22646; Wed, 19 Feb 1997 12:03:20 -0500 (EST) Received: from dore (dore.frcl.bull.fr [129.182.42.156]) by clbull.frcl.bull.fr (8.7.5/8.7.3) with SMTP id RAA48450; Wed, 19 Feb 1997 17:52:47 +0100 Received: from dese22 by dore (AIX 4.1/UCB 5.64/4.03) id AA26202; Wed, 19 Feb 1997 17:59:18 +0100 Message-Id: <330BB065.161@frcl.bull.fr> Date: Wed, 19 Feb 1997 18:01:09 -0800 From: Denis Pinkas Reply-To: D.Pinkas@frcl.bull.fr Organization: Bull X-Mailer: Mozilla 3.0 (Win16; I) Mime-Version: 1.0 To: "David P. Kemp" Cc: ietf-pkix@tandem.com Subject: Re: Private key possession References: <199702191524.KAA16394@argon.ncsc.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David, When posting that original message, I was expecting such comments but let us look more closely: > I believe that the protocol standard should REQUIRE CAs to verify > possession of the private key, even given the existence of CAs who, > for a reasonable fee, will ignore the standard. What I what to say is that we will have to live in a world where CAs, when required to make that verification, will make it or not (and this will happen whether we like it or not) :-( There is an interresting solution proposed by SPKI (not to be confused with PKIX !). Their document introduces the notion of a certificate counter-signed by the user. In such an architecture a certificate holds two signatures: one from the CA and another one from the user. In this way the user endorses the fact that the CA has issued the certificate. This is a proof that the user not only knows the private key but also accepts the certificate. Should I change the scope of the problem by asking whether the group wishes to change the definition of an X.509 certificate by adding a counter-signature from the owner of the certificate ? I think this would introduce a major change ... but would also solve the problem, this is why I did not proposed it first :-) Between these two solutions I prefer the one described in my first paper since it will introduce less dramatic changes. I cannot think a solution where all CAs will effectively do this test, ... unless there is some permanent proof that the verification was really made. Note: All this is still a matter of trust. My favorite sentence is : give me your trust conditions and I will tell you what kind of solutions are appropriate. Denis -- Denis Pinkas Bull S.A. E-mail : D.Pinkas@frcl.bull.fr Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 From chandras@loc201.tandem.com Wed Feb 19 09:19:27 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id JAA22040; Wed, 19 Feb 1997 09:19:27 -0800 Received: from ns.newbridge.com by suntan.tandem.com (8.6.12/suntan5.970212) for id JAA22032; Wed, 19 Feb 1997 09:19:25 -0800 Received: (from smap@localhost) by ns.newbridge.com (8.6.12/8.6.12) id MAA21483 for ; Wed, 19 Feb 1997 12:19:24 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma021322; Wed Feb 19 12:19:03 1997 Received: (from smap@localhost) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) id MAA12786 for ; Wed, 19 Feb 1997 12:18:58 -0500 Received: from tsntsrv2.timestep.com(192.168.219.191) by kanmaster.ca.newbridge.com via smap (V1.3) id sma012608; Wed Feb 19 12:18:07 1997 Received: by tsntsrv2.timestep.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC1E5F.26A6E710@tsntsrv2.timestep.com>; Wed, 19 Feb 1997 12:19:27 -0500 Message-ID: From: Paul Kierstead To: "'ietf-pkix@tandem.com'" Subject: RE: Private key possession Date: Wed, 19 Feb 1997 12:19:25 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >>The conclusion is that each CA SHOULD verify the possession of the >>private by the user before issuing a certificate containing the >>corresponding public key. > >>As a consequence, this means that having a protocol to verify the >>possession of a private signature key shall not be mandatory and if we >>defined one, it should only be optionally supported. A very interesting case. However, I do not agree with your conclusion. The specified requirements of the protocol/CA do not imply that you must trust that it was done to spec. i.e. you can specify that something _must_ be done without a third party (the patent office in your example) making the assumption that it was done. So PKIX should specify that a CA verifies private key ownership without making the assumption that it was done correctly. I'm not being horribly clear here, but I hope you get my gist... ------------------------------ Paul Kierstead TimeStep Corporation mailto:pmkierst@timestep.com http:\\www.timestep.com > From chandras@loc201.tandem.com Wed Feb 19 09:16:36 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id JAA21482; Wed, 19 Feb 1997 09:16:36 -0800 Received: from relay7.UU.NET by suntan.tandem.com (8.6.12/suntan5.970212) for id JAA21360; Wed, 19 Feb 1997 09:16:14 -0800 Received: from clbull.frcl.bull.fr by relay7.UU.NET with ESMTP (peer crosschecked as: [129.182.1.17]) id QQcdpd26486; Wed, 19 Feb 1997 12:16:04 -0500 (EST) Received: from dore (dore.frcl.bull.fr [129.182.42.156]) by clbull.frcl.bull.fr (8.7.5/8.7.3) with SMTP id SAA48948; Wed, 19 Feb 1997 18:05:44 +0100 Received: from dese22 by dore (AIX 4.1/UCB 5.64/4.03) id AA22560; Wed, 19 Feb 1997 18:12:15 +0100 Message-Id: <330BB36F.3AA5@frcl.bull.fr> Date: Wed, 19 Feb 1997 18:14:07 -0800 From: Denis Pinkas Reply-To: D.Pinkas@frcl.bull.fr Organization: Bull X-Mailer: Mozilla 3.0 (Win16; I) Mime-Version: 1.0 To: Carlisle Adams Cc: "'ietf-pkix@tandem.com'" Subject: Re: Private key possession References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Carlisle, Sorry, I answered to the E-mail from David first. Have a look at it before reading that E-mail. > It is amazing to me that you could possibly reach this conclusion after > the scenario you just described. Making the verification of the > possession of the private key OPTIONAL (or not defining it at all) is > *precisely* what allows such a problem to occur. Making it MANDATORY, > so that every end entity and every CA must comply with the rules in > order to complete the protocol, is what prevents such a problem (which > is why we concluded that it must be mandatory in the first place!). If I could really be sure that each CA will effectively perform that test and if the CA would be ready to provide me with such an evidence, then I would say that I agree with you. As mentioned in my response to David, there is a way to do it (by asking the user to counter-sign his certificate), ... but I doubt that the PKIX group will follow it. > By the way, if you're not going to trust a CA to do this part of > certification correctly, why in the world would you trust it to do any > other part of certification correctly? This might be the start of another thread ! I would prefer to follow one thread at a time. Shortly speaking, it is not because a certificate exists that I should trust it. I can have general rules saying, e.g. that I believe a given CA in the UK allowed/able to certify the key of another given CA in Germany, but I cannot have such rules necessarilly for every end user (at the termination of a certification path). Rules beteween CAs are "relatively" easy to handle, rules between end-users and CAs are more difficult (e.g. whether name subordination is used or not). Once again let us focuss on the first thread at this time. Denis -- Denis Pinkas Bull S.A. E-mail : D.Pinkas@frcl.bull.fr Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 From chandras@loc201.tandem.com Wed Feb 19 10:27:51 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id KAA05677; Wed, 19 Feb 1997 10:27:51 -0800 Received: from poptart.home.net by suntan.tandem.com (8.6.12/suntan5.970212) for id KAA05673; Wed, 19 Feb 1997 10:27:50 -0800 Message-Id: <199702191827.KAA05673@suntan.tandem.com> Received: from stjohns.eos.home.net ([24.0.8.217]) by poptart.home.net (Netscape Mail Server v1.1) with ESMTP id AAA653; Wed, 19 Feb 1997 10:27:43 -0700 X-Mailer: exmh version 1.6.7 5/3/96 To: D.Pinkas@frcl.bull.fr cc: ietf-pkix@tandem.com Subject: Re: Private key possession In-reply-to: Your message of Wed, 19 Feb 1997 13:30:59 -0800. <330B7113.2B59@frcl.bull.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Feb 1997 10:27:42 -0800 From: "Mike StJohns" Strawmen... I love strawmen... > Topic: Private key possession. > > Alice wishes to apply for a patent today and for doing so signs the > text of the patent using its private key, attach to it its certificate > and send the two pieces to a patent office. When receiving the two > pieces, the patent office would place a counter-signature from a > Trusted Time Stamping Authority on the whole package so that one can > make sure that the registration date is correct. > > Since Bob intercepted the message from Alice, the patent office did not > received Alice's message at this time. Bob promptly asks to a CA > located in Barracuda (in the Republic of Banana) to issue a certificate > containing the same public key as Alice but with his name in it. For a > reasonable fee the CA omits to verify the possession of the private key > by the user before issuing the certificate. Thereafter Bob sends the > intercepted signed text of the patent and replaces Alice's certificate > by his new own certificate. When receiving the two pieces, the patent > office places a counter-signature from a Trusted Time Stamping > Authority on the whole package so that one can make sure that the > registration date is correct. > > In such a scenario Bob would now the patent holder. If for some reason > Alice re-sends her message it will be time-stamped after the message > from Bob and she will not be recognized as the patent holder. Clyde at the patent office scratches his head at the fact that both Alice and Bob have sent patent requests for the same item... mumbles and then sends back a request to both parties to resign the patent request this time, including the text of their certificate within the patent request. Alice promptly proves she posesses the private key corresponding to the public key by signing the request. Bob, unable to validly sign the request, feeling his days are numbered and looking over his shoulder for the FBI, packs and leaves for Barracuda. The possession of the private key of a public/private key pair is sufficient (and necessary) to unambiguously identify a signer. Bob's binding of Alice's public key into a certificate (without him having possession of the private key) only permits Alice to masquerade as Bob, not for Bob to masquerade as Alice - since Alice has the key. Mike From chandras@loc201.tandem.com Wed Feb 19 10:50:52 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id KAA10115; Wed, 19 Feb 1997 10:50:52 -0800 Received: from guardian.guard.ncsc.mil by suntan.tandem.com (8.6.12/suntan5.970212) for id KAA10105; Wed, 19 Feb 1997 10:50:49 -0800 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id NAA01892 for ; Wed, 19 Feb 1997 13:50:27 -0500 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma001889; Wed Feb 19 13:50:01 1997 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id NAA17857 for ; Wed, 19 Feb 1997 13:47:09 -0500 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id NAA16561; Wed, 19 Feb 1997 13:49:41 -0500 Date: Wed, 19 Feb 1997 13:49:41 -0500 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199702191849.NAA16561@argon.ncsc.mil> To: ietf-pkix@tandem.com Subject: Re: Private key possession X-Sun-Charset: US-ASCII > What I what to say is that we will have to live in a world where CAs, > when required to make that verification, will make it or not (and this > will happen whether we like it or not) :-( I agree completely with this, and also agree that adding the subject's countersignature to X.509 certificates is an interesting idea. It might require getting rid of the SIGNED and SIGNATURE macros (which might be a good idea anyway, since the SIGNATURE macro makes the short-sighted and incorrect assumption that all signature algorithms are of the form ENCRYPTED { HASHED { data-to-be-signed }} ). But accepting this premise still doesn't lead to the conclusion that the PKIX standard should make the CA signature verification step optional. > Note: All this is still a matter of trust. My favorite sentence is : > give me your trust conditions and I will tell you what kind of solutions > are appropriate. If your trust model says that you will validate certificates issued by the Republic of Banana, or by the VeriSign Class 1 CA (or any of the other unverified online certificate issuers), then perhaps that trust is misplaced. On the other hand, when you choose to trust a reasonable-assurance CA, you are choosing to rely not only on the authentication procedures documented in their Certification Practices Statement, but the fact that those procedures are actually followed when that CA issues a certificate. If the patent office has two applications with the same signature, one with Bob's certificate from the Republic of Banana timestamped on Monday, and the other with Alice's certificate from (for example) GTE timestamped on Wednesday, they won't just blindly accept Bob's claim because it was received first. They will (or should) investigate the reliability of the respective certification paths. As long as signature verification is REQUIRED, if two CAs certify the same public key for two different subjects, you know that one of the CAs is lying. It won't be difficult to determine which one - just bring Alice and Bob into court and ask them to sign something. But if signature verification by the CA is OPTIONAL, then two CAs could comply with the standard and still be absolved of all responsibility for issuing an invalid certificate. (Assume that both of their CPSs say "we rely on a birth certificate for proof of identity, and follow the required parts of the PKIX protocol for certificate issuance".) I don't understand the motivation for not requiring proof of possession in the standard. We know that it is necessary. We also admit that there may be CAs who will not verify possession regardless of whether it is required. The only question is should such CAs be able to accurately claim that they comply with the PKIX standard? Clearly, the answer is "no". From chandras@loc201.tandem.com Wed Feb 19 10:55:25 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id KAA10880; Wed, 19 Feb 1997 10:55:25 -0800 Received: from csc.com by suntan.tandem.com (8.6.12/suntan5.970212) for id KAA10862; Wed, 19 Feb 1997 10:55:22 -0800 From: Received: from csc.com by csc.com with smtp (Smail3.1.29.1 #1) id m0vxH8g-001B4SC; Wed, 19 Feb 97 13:53 EST Received: by csc.com(Lotus SMTP MTA v1.05 (274.9 11-27-1996)) id 85256443.0067CEF2 ; Wed, 19 Feb 1997 13:53:51 -0400 X-Lotus-FromDomain: CSC To: D.Pinkas@frcl.bull.fr cc: ietf-pkix@tandem.com Message-ID: <85256443.00666040.00@csc.com> Date: Wed, 19 Feb 1997 13:49:57 -0400 Subject: Re: Private key possession Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Gene Hilborn/SED/CSC 02/19/97 01:49 PM Strawmen... I love strawmen... > Topic: Private key possession. > > Alice wishes to apply for a patent today and for doing so signs the > text of the patent using its private key, attach to it its certificate > and send the two pieces to a patent office. When receiving the two > pieces, the patent office would place a counter-signature from a > Trusted Time Stamping Authority on the whole package so that one can > make sure that the registration date is correct. > > Since Bob intercepted the message from Alice, the patent office did not > received Alice's message at this time. Bob promptly asks to a CA > located in Barracuda (in the Republic of Banana) to issue a certificate > containing the same public key as Alice but with his name in it. For a > reasonable fee the CA omits to verify the possession of the private key > by the user before issuing the certificate. Thereafter Bob sends the > intercepted signed text of the patent and replaces Alice's certificate > by his new own certificate. When receiving the two pieces, the patent > office places a counter-signature from a Trusted Time Stamping > Authority on the whole package so that one can make sure that the > registration date is correct. > > In such a scenario Bob would now the patent holder. If for some reason > Alice re-sends her message it will be time-stamped after the message > from Bob and she will not be recognized as the patent holder. Clyde at the patent office scratches his head at the fact that both Alice and Bob have sent patent requests for the same item... mumbles and then sends back a request to both parties to resign the patent request this time, including the text of their certificate within the patent request. Alice promptly proves she posesses the private key corresponding to the public key by signing the request. Bob, unable to validly sign the request, feeling his days are numbered and looking over his shoulder for the FBI, packs and leaves for Barracuda. The possession of the private key of a public/private key pair is sufficient (and necessary) to unambiguously identify a signer. Bob's binding of Alice's public key into a certificate (without him having possession of the private key) only permits Alice to masquerade as Bob, not for Bob to masquerade as Alice - since Alice has the key. Mike From chandras@loc201.tandem.com Wed Feb 19 12:24:54 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id MAA27764; Wed, 19 Feb 1997 12:24:54 -0800 Received: from aardvark.zoo.net by suntan.tandem.com (8.6.12/suntan5.970212) for id MAA27759; Wed, 19 Feb 1997 12:24:51 -0800 Received: from localhost (marcnarc@localhost) by aardvark.zoo.net (8.6.12/8.6.9) with SMTP id PAA18113 for ; Wed, 19 Feb 1997 15:24:53 -0500 Date: Wed, 19 Feb 1997 15:24:51 -0500 (EST) From: Marc Branchaud To: ietf-pkix@tandem.com Subject: Re: Private key possession In-Reply-To: <199702191827.KAA05673@suntan.tandem.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII -----BEGIN PGP SIGNED MESSAGE----- Hi, all... I've lost Denis's original message, so I can't quote it exactly, but he mentioned a second scnario in which Alice signed both the patent text and the certification path. It seems to me that if this solved the problem, then the problem is solved. The basic lesson is: if you don't want any part of your message to be forged (including an attached certification path) then you should sign the whole darn thing. So Alice should have acted as she did in Denis's second scnario in the first place. Marc ============================== ------ I'M LOOKING FOR A JOB! ----- Marc Branchaud I'm looking for a full-time career, marcnarc@zoo.net and I'm willing to move almost any- www.zoo.net/~marcnarc/ where. You can see my CV online at ============================== www.zoo.net/~marcnarc/Marc-CV.htm -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQB1AwUBMwthlFrdFXNdDxPlAQHc/QMAmIF5rLlfNUFka5A8Jyub2agum0aYvoQh D1kwB1E1bbF+tSU0HmWDUDUJck5YHA9BAaeW38zYpBKct87yiqzqlYJJ1L4wb7Ju E6rDdz4KXOY7zNNOQ6dQjg2VY2uzg2J3 =Pd0K -----END PGP SIGNATURE----- From chandras@loc201.tandem.com Wed Feb 19 12:26:31 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id MAA27933; Wed, 19 Feb 1997 12:26:31 -0800 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id MAA27842; Wed, 19 Feb 1997 12:25:34 -0800 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id MAA18441; Wed, 19 Feb 1997 12:23:42 -0800 (PST) Received: from peter.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id MAA23921; Wed, 19 Feb 1997 12:24:15 -0800 (PST) Message-Id: <3.0.32.19970219122546.007002cc@mail> X-Sender: peter@mail X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 19 Feb 1997 12:25:50 -0800 To: D.Pinkas@frcl.bull.fr, "David P. Kemp" From: Peter Williams Subject: Re: Private key possession Cc: ietf-pkix@tandem.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" > >Their document introduces the notion of a certificate counter-signed by >the user. In such an architecture a certificate holds two signatures: >one from the CA and another one from the user. In this way the user >endorses the fact that the CA has issued the certificate. This is a >proof that the user not only knows the private key but also accepts the >certificate. Are you claiming this is a messaging proof/non-repudiation of acceptance, service? generalised it would say, if I send you a signed message, containing your public key bound to some datum, and you countersign that msg, this is a mechanism for proof of acceptance of datum, if a validator can find a public key value in the (next) inner-signed component which validates the outer signature. And, of course this is itself generalizable: five users get a CA to issue a cert containing 5 name/key bindings, each of which is then endorsed in some order relevant to say a groupware authority signoff process. A final counter-signature is then applied by the CA again, to protect against loss of endorsements. As a raw mechanism, I like it. Lots of possibilitees for transactional certs environments which often mix third-party and user signatures. From chandras@loc201.tandem.com Wed Feb 19 14:09:11 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id OAA16157; Wed, 19 Feb 1997 14:09:11 -0800 Received: from mail.telstra.com.au by suntan.tandem.com (8.6.12/suntan5.970212) for id OAA16144; Wed, 19 Feb 1997 14:09:07 -0800 Received: (from uucp@localhost) by mail.telstra.com.au (8.8.2/8.6.9) id JAA26718; Thu, 20 Feb 1997 09:07:50 +1100 (EST) Received: from mail_gw.fwall.telecom.com.au(192.148.147.10) by mail via smap (V1.3) id sma025388; Thu Feb 20 09:00:13 1997 Received: (from uucp@localhost) by mail_gw.fwall.telecom.com.au (8.8.2/8.6.9) id JAA02717; Thu, 20 Feb 1997 09:00:11 +1100 (EST) Received: from cdn_mail.dn.itg.telecom.com.au(144.135.109.134) by mail-gw.fwall.telstra.com.au via smap (V1.3) id sma002659; Thu Feb 20 08:59:45 1997 Received: from bifrost.trl.OZ.AU (heimdall.trl.oz.au [137.147.20.80]) by cdn-mail.telecom.com.au (8.8.2/8.6.9) with SMTP id IAA12707; Thu, 20 Feb 1997 08:59:45 +1100 (EST) Received: (from warner@localhost) by bifrost.trl.OZ.AU (8.6.9/8.6.12) id IAA06395; Thu, 20 Feb 1997 08:59:34 +1100 Date: Thu, 20 Feb 1997 08:59:34 +1100 From: Michael Warner Message-Id: <199702192159.IAA06395@bifrost.trl.OZ.AU> To: ietf-pkix@tandem.com, D.Pinkas@frcl.bull.fr Subject: Re: Private key possession X-Sun-Charset: US-ASCII > From: Denis Pinkas > > Topic: Private key possession. > > > > Let us take the following example: > > Alice wishes to apply for a patent today and for doing so signs the > text of the patent using its private key, attach to it its certificate > and send the two pieces to a patent office. When receiving the two > pieces, the patent office would place a counter-signature from a > Trusted Time Stamping Authority on the whole package so that one can > make sure that the registration date is correct. > > Since Bob intercepted the message from Alice, the patent office did not > received Alice's message at this time. Bob promptly asks to a CA > located in Barracuda (in the Republic of Banana) to issue a certificate > containing the same public key as Alice but with his name in it. For a > reasonable fee the CA omits to verify the possession of the private key > by the user before issuing the certificate. Thereafter Bob sends the > intercepted signed text of the patent and replaces Alice's certificate > by his new own certificate. When receiving the two pieces, the patent > office places a counter-signature from a Trusted Time Stamping > Authority on the whole package so that one can make sure that the > registration date is correct. > > In such a scenario Bob would now the patent holder. If for some reason > Alice re-sends her message it will be time-stamped after the message > from Bob and she will not be recognized as the patent holder. > As you later hint, the problem here lies not with the CA not checking the possession of the private key, but rather with the patent lodging protocol. Such a protocol must obviously explicitly associate the identity of the person lodging the patent with the text of the patent. I don't think extra effort should be tolerated in the certification stage in an attempt to protect from poor protocol design in applications ! Cheers, Michael Warner Telstra Research Labs From chandras@loc201.tandem.com Thu Feb 20 04:24:31 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id EAA29566; Thu, 20 Feb 1997 04:24:31 -0800 Received: from relay7.UU.NET by suntan.tandem.com (8.6.12/suntan5.970212) for id EAA29391; Thu, 20 Feb 1997 04:22:27 -0800 Received: from clbull.frcl.bull.fr by relay7.UU.NET with ESMTP (peer crosschecked as: [129.182.1.17]) id QQcdsb29623; Thu, 20 Feb 1997 07:22:24 -0500 (EST) Received: from dore (dore.frcl.bull.fr [129.182.42.156]) by clbull.frcl.bull.fr (8.7.5/8.7.3) with SMTP id NAA16950; Thu, 20 Feb 1997 13:12:48 +0100 Received: from dese22 by dore (AIX 4.1/UCB 5.64/4.03) id AA32078; Thu, 20 Feb 1997 13:19:35 +0100 Message-Id: <330CC055.649C@frcl.bull.fr> Date: Thu, 20 Feb 1997 13:21:25 -0800 From: Denis Pinkas Reply-To: D.Pinkas@frcl.bull.fr Organization: Bull X-Mailer: Mozilla 3.0 (Win16; I) Mime-Version: 1.0 To: ghilborn@csc.com Cc: ietf-pkix@tandem.com Subject: Re: Private key possession References: <85256443.00666040.00@csc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike wrote: > Clyde at the patent office scratches his head at the fact that both Alice > and Bob have sent patent requests for the same item... mumbles and then > sends back a request to both parties to resign the patent request this > time, including the text of their certificate within the patent request. > Alice promptly proves she posesses the private key corresponding to the > public key by signing the request. Bob, unable to validly sign the request, > feeling his days are numbered and looking over his shoulder for the FBI, > packs and leaves for Barracuda. Your proposal works nicely but signing the request involves an extra exchange that can be avoided. I wrote : "The general way to solve the problem is to include enough information within the signed text to identify unambiguously the signer. (...) A more general solution is to reserve some place within the signed text to insert at least the identifier of the certificate. The best being to insert a certification path." Basically, what I propose is to do it in the initial sending of the patent rather than doing it in an additional request coming from the patent office. Denis -- Denis Pinkas Bull S.A. E-mail : D.Pinkas@frcl.bull.fr Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 From chandras@loc201.tandem.com Thu Feb 20 05:26:04 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id FAA06370; Thu, 20 Feb 1997 05:26:04 -0800 Received: from relay7.UU.NET by suntan.tandem.com (8.6.12/suntan5.970212) for id FAA06247; Thu, 20 Feb 1997 05:24:00 -0800 Received: from clbull.frcl.bull.fr by relay7.UU.NET with ESMTP (peer crosschecked as: clbull.frcl.bull.fr [129.182.1.17]) id QQcdsf09605; Thu, 20 Feb 1997 08:23:57 -0500 (EST) Received: from dore (dore.frcl.bull.fr [129.182.42.156]) by clbull.frcl.bull.fr (8.7.5/8.7.3) with SMTP id OAA12893; Thu, 20 Feb 1997 14:14:17 +0100 Received: from dese22 by dore (AIX 4.1/UCB 5.64/4.03) id AA29744; Thu, 20 Feb 1997 14:21:04 +0100 Message-Id: <330CCEBF.7A46@frcl.bull.fr> Date: Thu, 20 Feb 1997 14:22:55 -0800 From: Denis Pinkas Reply-To: D.Pinkas@frcl.bull.fr Organization: Bull X-Mailer: Mozilla 3.0 (Win16; I) Mime-Version: 1.0 To: Peter Williams Cc: "David P. Kemp" , ietf-pkix@tandem.com Subject: Re: Private key possession References: <3.0.32.19970219122546.007002cc@mail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Peter Williams wrote: > >Their document introduces the notion of a certificate counter-signed by > >the user. In such an architecture a certificate holds two signatures: > >one from the CA and another one from the user. In this way the user > >endorses the fact that the CA has issued the certificate. This is a > >proof that the user not only knows the private key but also accepts the > >certificate. > > Are you claiming this is a messaging proof/non-repudiation of acceptance, > service? No. > generalised it would say, if I send you a signed message, containing > your public key bound to some datum, and you countersign that msg, this is > a mechanism for proof of acceptance of datum, if a validator can find > a public key value in the (next) inner-signed component which validates the > outer signature. "proof of acceptance of datum" which looks like non repudiation of acceptance of datum could not be provided by the mechanism you describe. You are on a different thread here which is far away from the origional topic that was discussed. Denis -- Denis Pinkas Bull S.A. E-mail : D.Pinkas@frcl.bull.fr Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 From chandras@loc201.tandem.com Thu Feb 20 05:22:21 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id FAA05999; Thu, 20 Feb 1997 05:22:21 -0800 Received: from relay7.UU.NET by suntan.tandem.com (8.6.12/suntan5.970212) for id FAA05695; Thu, 20 Feb 1997 05:20:18 -0800 Received: from clbull.frcl.bull.fr by relay7.UU.NET with ESMTP (peer crosschecked as: clbull.frcl.bull.fr [129.182.1.17]) id QQcdsf08885; Thu, 20 Feb 1997 08:20:13 -0500 (EST) Received: from dore (dore.frcl.bull.fr [129.182.42.156]) by clbull.frcl.bull.fr (8.7.5/8.7.3) with SMTP id OAA13116; Thu, 20 Feb 1997 14:10:38 +0100 Received: from dese22 by dore (AIX 4.1/UCB 5.64/4.03) id AA29706; Thu, 20 Feb 1997 14:17:25 +0100 Message-Id: <330CCDE4.1E2B@frcl.bull.fr> Date: Thu, 20 Feb 1997 14:19:16 -0800 From: Denis Pinkas Reply-To: D.Pinkas@frcl.bull.fr Organization: Bull X-Mailer: Mozilla 3.0 (Win16; I) Mime-Version: 1.0 To: "David P. Kemp" Cc: ietf-pkix@tandem.com Subject: Re: Private key possession References: <199702191849.NAA16561@argon.ncsc.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David P. Kemp wrote: > > What I what to say is that we will have to live in a world where CAs, > > when required to make that verification, will make it or not (and this > > will happen whether we like it or not) :-( > > I agree completely with this, and also agree that adding the subject's > countersignature to X.509 certificates is an interesting idea. > > (...) > > But accepting this premise still doesn't lead to the conclusion that > the PKIX standard should make the CA signature verification step > optional. Let me clarify the point. The question is whether we need a PROTOCOL for doing this and whether that PROTOCOL shall be mandatorilly supported. First, the example was there to show that when this protocol is supported, only the CA can rely on it (and no one else) since there will be no evidence that the CA will effectively perform the verification. Second, the example was also given to show that we do not need this protocol if, in the example, we use the private key to sign "some data" including an identifier of the certificate (CA name+ serial number), or even better of the certification chain (i.e. a certification path). That signed data may be either: 1 - the signed message which then includes the certificate identifier (as this was initially proposed in my first E-mail), 2 - the certificate itself which is then counter-signed by the user (as this was mentionned in my second E-mail). My position is thus that this protocol does *not* need to be mandatorilly supported but that CAs *should* verify the possession of the private key by any available means. Remember that in some cases the private key is given directly to the user by the CA and then to the user through the RA. This protocol would be useless in that case. (...) > If the patent office has two applications with the same signature, one > with Bob's certificate from the Republic of Banana timestamped on Monday, > and the other with Alice's certificate from (for example) GTE timestamped > on Wednesday, they won't just blindly accept Bob's claim because it was > received first. They will (or should) investigate the reliability of > the respective certification paths. Correct. > As long as signature verification is REQUIRED, if two CAs certify the > same public key for two different subjects, you know that one of the CAs > is lying. It won't be difficult to determine which one - just bring > Alice and Bob into court and ask them to sign something. Bringing people into court takes about two years in some countries :-( At that time, the private key has expired and thus the token holding it is no more usable. No one is, at that time, able to sign anything. However the judge must still solve the case ... Here is the reason why this signature is indeed provided before the case happens, and not after the event. > But if signature verification by the CA is OPTIONAL, then two CAs could > comply with the standard and still be absolved of all responsibility for > issuing an invalid certificate. The verification of the possession of a private key is important for regular CAs wishing to make sure that they guarantee the value of the public key and the affiliation to a domain. As said earlier there are many means to provide this, so that the *CA* can be confident about it, but not that anyone else can be confident about it. One of these means may be to use a protocol as proposed. > I don't understand the motivation for not requiring proof of possession > in the standard. The proposed protocol is one way of doing it, not the single mandatory way. In addition we should say that this protocol does not provide anyone else than the CA that the user is effectively in possession of the private key. > We know that it is necessary. We also admit that there > may be CAs who will not verify possession regardless of whether it > is required. Yes. > The only question is should such CAs be able to accurately claim that > they comply with the PKIX standard? Clearly, the answer is "no". Complying would mean that the CA should do the verification by any means, including this optional protocol, so that it can be convinced of the possession of the private key. Denis -- Denis Pinkas Bull S.A. E-mail : D.Pinkas@frcl.bull.fr Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 From chandras@loc201.tandem.com Thu Feb 20 05:30:30 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id FAA06948; Thu, 20 Feb 1997 05:30:30 -0800 Received: from relay7.UU.NET by suntan.tandem.com (8.6.12/suntan5.970212) for id FAA06636; Thu, 20 Feb 1997 05:28:24 -0800 Received: from clbull.frcl.bull.fr by relay7.UU.NET with ESMTP (peer crosschecked as: clbull.frcl.bull.fr [129.182.1.17]) id QQcdsf10636; Thu, 20 Feb 1997 08:28:19 -0500 (EST) Received: from dore (dore.frcl.bull.fr [129.182.42.156]) by clbull.frcl.bull.fr (8.7.5/8.7.3) with SMTP id OAA25094; Thu, 20 Feb 1997 14:18:43 +0100 Received: from dese22 by dore (AIX 4.1/UCB 5.64/4.03) id AA34604; Thu, 20 Feb 1997 14:25:30 +0100 Message-Id: <330CCFC9.4ECF@frcl.bull.fr> Date: Thu, 20 Feb 1997 14:27:21 -0800 From: Denis Pinkas Reply-To: D.Pinkas@frcl.bull.fr Organization: Bull X-Mailer: Mozilla 3.0 (Win16; I) Mime-Version: 1.0 To: Paul Kierstead Cc: "'ietf-pkix@tandem.com'" Subject: Re: Private key possession References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Paul Kierstead wrote: > > >>The conclusion is that each CA SHOULD verify the possession of the > >>private by the user before issuing a certificate containing the > >>corresponding public key. > > > >>As a consequence, this means that having a protocol to verify the > >>possession of a private signature key shall not be mandatory and if we > >>defined one, it should only be optionally supported. > > A very interesting case. However, I do not agree with your conclusion. > > (...) . So PKIX should specify that a CA > verifies private key ownership without making the assumption that it was > done correctly. I strongly agree with your conclusion and thus I am not sure that you fully disagree with my conclusion :-) Denis Note: see other responses made on the same topic as well. > ------------------------------ > Paul Kierstead TimeStep Corporation > mailto:pmkierst@timestep.com http:\\www.timestep.com > > > -- Denis Pinkas Bull S.A. E-mail : D.Pinkas@frcl.bull.fr Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 From chandras@loc201.tandem.com Thu Feb 20 10:22:06 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id KAA20043; Thu, 20 Feb 1997 10:22:06 -0800 Received: from poptart.home.net by suntan.tandem.com (8.6.12/suntan5.970212) for id KAA20038; Thu, 20 Feb 1997 10:22:05 -0800 Message-Id: <199702201822.KAA20038@suntan.tandem.com> Received: from stjohns.eos.home.net ([24.0.8.217]) by poptart.home.net (Netscape Mail Server v1.1) with ESMTP id AAA4065; Thu, 20 Feb 1997 10:21:58 -0700 X-Mailer: exmh version 1.6.7 5/3/96 To: D.Pinkas@frcl.bull.fr cc: ghilborn@csc.com, ietf-pkix@tandem.com Subject: Re: Private key possession In-reply-to: Your message of Thu, 20 Feb 1997 13:21:25 -0800. <330CC055.649C@frcl.bull.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Feb 1997 10:21:57 -0800 From: "Mike StJohns" > Mike wrote: > > > Clyde at the patent office scratches his head at the fact that both Alice > > and Bob have sent patent requests for the same item... mumbles and then > > sends back a request to both parties to resign the patent request this > > time, including the text of their certificate within the patent request. > > Alice promptly proves she posesses the private key corresponding to the > > public key by signing the request. Bob, unable to validly sign the request, > > feeling his days are numbered and looking over his shoulder for the FBI, > > packs and leaves for Barracuda. > > Your proposal works nicely but signing the request involves an extra > exchange that can be avoided. I wrote : > > "The general way to solve the problem is to include enough information > within the signed text to identify unambiguously the signer. (...) A > more general solution is to reserve some place within the signed text > to insert at least the identifier of the certificate. The best being to > insert a certification path." > > Basically, what I propose is to do it in the initial sending of the > patent rather than doing it in an additional request coming from the > patent office. > > Denis Denis - certificates do not stand on their own - basic to the concept is the fact you might have to prove any signature at a later time. If you want to prove you know the private key of the public key in the certificate, include the certificate in what you have to sign.... S[privatekey]{patentrequest, certificate} (as per your suggestion...) but you may still have to recourse to having them prove they know the private key at a later time (especially if Alice is masquerading as Ann at a consulting company and has a certificate to prove it...) Mike From chandras@loc201.tandem.com Thu Feb 20 11:30:39 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id LAA02153; Thu, 20 Feb 1997 11:30:39 -0800 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id LAA01949; Thu, 20 Feb 1997 11:29:42 -0800 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id LAA17377; Thu, 20 Feb 1997 11:27:48 -0800 (PST) Received: from peter.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id LAA20353; Thu, 20 Feb 1997 11:28:23 -0800 (PST) Message-Id: <3.0.32.19970220113004.006fd0f4@mail> X-Sender: peter@mail X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 20 Feb 1997 11:30:08 -0800 To: D.Pinkas@frcl.bull.fr From: Peter Williams Subject: Re: Private key possession Cc: ietf-pkix@tandem.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Denis, I like to know when my deductions from a claim assumption are false, and therefore thankyou for your definitive answer concerning the non-repudation semantics. Now, we can look at the claim more carefully and see if it has any real meaning, and then, determine what that meaning is, in detail. I quote (again) your text, which led me down the dubious reasoning path. "This is a proof that the user not only knows the private key but also accepts the certificate." Let's pull the claim apart, in more formal claims language. 1. The endorsement mechanism proves the user knows the private key. 2. The endorsement mechanism "demonstrates" [my insertion] that the subscriber accepts the certificate. How does the mechanism (of endorsement) "demonstrate" acceptance? If it does not "demonstrate" acceptance, what does it do? Does it "prove" some property of acceptance, if it does not prove the performance of the act of acceptance itself? (The original claims language makes some grammatical allusion to there being a useful "proof" event, presumably of sufficient merit to serve as input for some enforcement process, though not one relying upon ISO-defined non-repudiation security service semantics) I investigate this claim so carefully, for there would be many, many online applications of the mechanism and its derived acceptance service, if it really exists such that it satisifes the claim. As claimed, the service would be useful to the CA industry for its own purposes of assuring there to be sastified customers of certification services delivered in non face-to-face circumstances. If however the mechanism has no determinable meaning to a third party, it may not be very useful except in hand-waving security system designs! If the only benefactor of the endorsement is the CA, then perhaps the CA can encourage subscribers to merely use the cert in some protocol (SSL, S/MIME etc) with the CA as recipient to gain the fuzzy acceptance signal. There seems little reasoned need to change formats or semantics of certs/CA, or established standard issuing and reliance models, when mere use conveys the same (vague, but warm and fuzzy) acceptance signal. At 02:22 PM 2/20/97 -0800, Denis Pinkas wrote: >Peter Williams wrote: > >> >Their document introduces the notion of a certificate counter-signed by >> >the user. In such an architecture a certificate holds two signatures: >> >one from the CA and another one from the user. In this way the user >> >endorses the fact that the CA has issued the certificate. This is a >> >proof that the user not only knows the private key but also accepts the >> >certificate. >> >> Are you claiming this is a messaging proof/non-repudiation of acceptance, >> service? > >No. From chandras@loc201.tandem.com Thu Feb 20 11:58:48 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id LAA06518; Thu, 20 Feb 1997 11:58:48 -0800 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id LAA06395; Thu, 20 Feb 1997 11:57:39 -0800 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id LAA26175; Thu, 20 Feb 1997 11:55:45 -0800 (PST) Received: from peter.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id LAA28147; Thu, 20 Feb 1997 11:56:21 -0800 (PST) Message-Id: <3.0.32.19970220115801.0103f0b4@mail> X-Sender: peter@mail X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 20 Feb 1997 11:58:05 -0800 To: D.Pinkas@frcl.bull.fr, "David P. Kemp" From: Peter Williams Subject: Re: Private key possession Cc: ietf-pkix@tandem.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 02:19 PM 2/20/97 -0800, Denis Pinkas wrote: >First, the [SPKI endorsement] example was there to show that when this protocol is >supported, only the CA can rely on it (and no one else) This is now crystal clear. >At that time, the private key has expired and thus the token holding it >is no more usable. No one is, at that time, able to sign anything. >However the judge must still solve the case ... This indicates there are some needs to support third-party evaluation, some of the time. But, I would personally agree with the notion than an Internet-centric CA infrastructure which is NOT given over to ONLY supporting non-repudation grade services, should NOT need to make the estabishment of private key of a subscriber a mandatory, uniform requirement, or that all PKIX-using software should assume such a condition of a CA claiming conformance to PKIX I would argue, that based on the disclosed operating policy of the CA, and any reliability criteria, such a property can be relied upon by those subscribers/users with a need, based upon their "acceptance" and utility of the policy rules to their environment. All I agreeing technically here, is that technical mechanisms and operating policy are naturally separated in this protocol standard, as everywhere else in the open networking world. On this basis, I would agree with Denis' proposal to change the mandatory language, and do react to the apparent intent of those who wrote it to uniformly constrain the key management infrastructure in a policy-specific manner. From chandras@loc201.tandem.com Thu Feb 20 16:41:55 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id QAA24824; Thu, 20 Feb 1997 16:41:55 -0800 Received: from relay.ieunet.ie by suntan.tandem.com (8.6.12/suntan5.970212) for id QAA24805; Thu, 20 Feb 1997 16:41:52 -0800 Received: from db-62.dialup.eunet.ie by relay.ieunet.ie with SMTP id aa15269; 21 Feb 97 0:41 +0000 Received: from brd.ie (fod@localhost [127.0.0.1]) by brd.ie (8.7.5/8.7.3) with ESMTP id AAA11163; Fri, 21 Feb 1997 00:43:49 GMT Message-Id: <199702210043.AAA11163@brd.ie> X-Mailer: exmh version 1.6.7 5/3/96 To: D.Pinkas@frcl.bull.fr cc: "David P. Kemp" , ietf-pkix@tandem.com Subject: Re: Private key possession In-reply-to: Your message of "Thu, 20 Feb 1997 14:19:16 PST." <330CCDE4.1E2B@frcl.bull.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Feb 1997 00:43:48 +0000 From: "Frank O'Dwyer" There is another reason why demonstrating possession of a private key might not be a good thing to make mandatory, and I think it is more plausible than the patent example. For example, I might want to make a local intranet certificate which binds certain X.509 extensions to your key. This certificate permits you (say) to upload signed files via my firewall. That doesn't seem an unreasonable requirement, but I can't do it if I need to demonstrate ability to use your private key. Certainly you (or your agent) could request the same cert, but an intranet CA is likely to reject out of hand certification requests that originate from outside. There are clearly other examples, too, where you might not want to consent to an attribute (e.g. it says you are not a good risk for a loan). Or, it might be confidential (you can't decrypt it and therefore _can't_ consent to it). Still, I might wish to request it, the CA might be willing to grant it, and someone else might wish to trust it. But it's all impossible if I have to know your private key. Seems like a broad class of applications to be ruling out. Cheers, Frank O'Dwyer. From chandras@loc201.tandem.com Thu Feb 20 17:16:12 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id RAA00314; Thu, 20 Feb 1997 17:16:12 -0800 Received: from tahoma.mcom.com by suntan.tandem.com (8.6.12/suntan5.970212) for id RAA00305; Thu, 20 Feb 1997 17:16:10 -0800 Received: from tahoma (localhost [127.0.0.1]) by tahoma.mcom.com (940816.SGI.8.6.9/8.6.9) with SMTP id RAA24559 for ; Thu, 20 Feb 1997 17:11:47 -0800 Sender: gangolli@netscape.com Message-ID: <330CF652.3B54@netscape.com> Date: Thu, 20 Feb 1997 17:11:46 -0800 From: "Anil R. Gangolli" Organization: Netscape Server Product Development X-Mailer: Mozilla 3.01Gold (X11; U; IRIX 5.3 IP22) MIME-Version: 1.0 To: ietf-pkix@tandem.com Subject: Profiles, Profiles, Profiles Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am aware of the following certificate, crl, and/or verification profiles in development or existence today: 1. PEM (will be mostly obsolete, I expect, after PKIX) 2. PKIX (IETF) 3. MISSI 4. MISPC (NIST) 5. Federal PKI (Federal PKI-TWG) I worry that the proliferation of certificate profiles poses a serious threat to interoperability and will slow down the adoption and usability of PKI as a whole. Most of these profiles specify contents requirements for each field in the certificate, crl, etc.. Has anyone here done a comparative field-by-field analysis of these to see where they are in common and where they differ? (I suppose a comparitive analysis of the verification procedures may be harder to write down succinctly.) Any comparative analysis would be useful both to the IETF PKIX effort as well as these other profile efforts. Ideally there would be one uniform profile across the board, but barring that, at least one could hope for (and drive toward) the minimal differences in profiles that are needed to support any actual differences in requirements. Thanks in advance for any information in this area. --a. From chandras@loc201.tandem.com Thu Feb 20 18:42:11 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id SAA12581; Thu, 20 Feb 1997 18:42:11 -0800 Received: from consensus.com by suntan.tandem.com (8.6.12/suntan5.970212) for id SAA12568; Thu, 20 Feb 1997 18:42:06 -0800 Received: from dynamic-addr-192.consensus.com (157.22.240.192) by consensus.com with ESMTP (Apple Internet Mail Server 1.1); Thu, 20 Feb 1997 18:41:55 -0800 Message-Id: In-Reply-To: <330CF652.3B54@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Organization: Consensus Development Corporation Date: Thu, 20 Feb 1997 18:40:13 -0800 To: "Anil R. Gangolli" From: Christopher Allen Subject: Re: Profiles, Profiles, Profiles Cc: ietf-pkix@tandem.com At 5:11 PM -0800 2/20/97, Anil R. Gangolli wrote: >1. PEM (will be mostly obsolete, I expect, after PKIX) >2. PKIX (IETF) >3. MISSI >4. MISPC (NIST) >5. Federal PKI (Federal PKI-TWG) You should also consider S/MIME to be a profile. Another profile, though not yet documented as such, is the SSL Certificate Profile. Both are a little orthagonal to the above, but are more applicable in practice. ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. .. 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. ..Home of "SSL Plus: o510/559-1500 f510/559-1505.. .. SSL 3.0 Integration Suite(tm)" .. From chandras@loc201.tandem.com Fri Feb 21 00:47:43 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id AAA08806; Fri, 21 Feb 1997 00:47:43 -0800 Received: from relay6.UU.NET by suntan.tandem.com (8.6.12/suntan5.970212) for id AAA08706; Fri, 21 Feb 1997 00:45:39 -0800 Received: from clbull.frcl.bull.fr by relay6.UU.NET with ESMTP (peer crosschecked as: clbull.frcl.bull.fr [129.182.1.17]) id QQcdvf11347; Fri, 21 Feb 1997 03:45:36 -0500 (EST) Received: from dore (dore.frcl.bull.fr [129.182.42.156]) by clbull.frcl.bull.fr (8.7.5/8.7.3) with SMTP id JAA22256; Fri, 21 Feb 1997 09:36:02 +0100 Received: from dese22 by dore (AIX 4.1/UCB 5.64/4.03) id AA34772; Fri, 21 Feb 1997 09:42:49 +0100 Message-Id: <330DDF08.72CD@frcl.bull.fr> Date: Fri, 21 Feb 1997 09:44:40 -0800 From: Denis Pinkas Reply-To: D.Pinkas@frcl.bull.fr Organization: Bull X-Mailer: Mozilla 3.0 (Win16; I) Mime-Version: 1.0 To: Peter Williams Cc: ietf-pkix@tandem.com Subject: Re: Private key possession References: <3.0.32.19970220113004.006fd0f4@mail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Peter Williams wrote: > Denis, > > I like to know when my deductions from a claim assumption are false, > and therefore thankyou for your definitive answer concerning the > non-repudation semantics. Your original question was : Are you claiming this is a messaging proof/non-repudiation of acceptance service ? As I was no claiming anything, I answered no. The term you are using "non-repudiation of acceptance service" is new to me, although I recognize that there are illimitted forms of non-repudiation in addition to "non repudiation of origin" and "non repudiation of delivery" as defined in ISO 7498-2 and 10181-4. Looking more carefully to your mail let me now think that the dual signature mechanism does provide a way to prove the acceptance of the certificate and thus could be considered as an appropriate mechanism to provide such a service ... provided that some one defines with some English sentence what this really means in order to avoid multiple interpretations :-) Denis. -- Denis Pinkas Bull S.A. E-mail : D.Pinkas@frcl.bull.fr Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 From chandras@loc201.tandem.com Fri Feb 21 04:34:53 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id EAA21193; Fri, 21 Feb 1997 04:34:53 -0800 Received: from mbunix.mitre.org by suntan.tandem.com (8.6.12/suntan5.970212) for id EAA21188; Fri, 21 Feb 1997 04:34:48 -0800 Received: from TGATE3 (tgate3.mitre.org [129.83.20.27]) by mbunix.mitre.org (8.8.5/8.8.4/mitre.0) with SMTP id HAA15525; Fri, 21 Feb 1997 07:34:17 -0500 (EST) Received: from mail11 (129.83.20.44) by tgate3.mitre.org (EMWAC SMTPRS 0.60) with SMTP id ; Fri, 21 Feb 1997 07:30:59 -0500 Received: by mail11; (5.65v3.2/1.1.8.2/22Jun94-0628PM) id AA01585; Fri, 21 Feb 1997 07:34:16 -0500 Subject: RE: Profiles, Profiles, Profiles From: jfurlong@mail11.mitre.org (Judith A. Furlong) To: gangolli@netscape.com (Anil R. Gangolli) cc: ietf-pkix@tandem.com Message-Id: <970221073413.673@mail11.mitre.org.0> Date: Fri, 21 Feb 97 07:34:16 -0500 X-Mailer: MailWorks 2.0-2 SET also has its own Certificate & CRL profile. (See Part II of the Programmer's Guide) I have done some comparative analysis of the Certificate and CRL profiles defined by PKIX, MISSI & SET. This analysis has been focused more on field content versus processing rules. I would be glad to talk with you about the comparison. Judy Furlong jfurlong@mitre.org >I am aware of the following certificate, crl, and/or verification >profiles in development or existence today: > >1. PEM (will be mostly obsolete, I expect, after PKIX) >2. PKIX (IETF) >3. MISSI >4. MISPC (NIST) >5. Federal PKI (Federal PKI-TWG) > >I worry that the proliferation of certificate profiles >poses a serious threat to interoperability and will >slow down the adoption and usability of PKI as a whole. > >Most of these profiles specify contents requirements for >each field in the certificate, crl, etc.. Has anyone here >done a comparative field-by-field analysis of these to >see where they are in common and where they differ? >(I suppose a comparitive analysis of the verification >procedures may be harder to write down succinctly.) > >Any comparative analysis would be useful both to the IETF >PKIX effort as well as these other profile efforts. >Ideally there would be one uniform profile across >the board, but barring that, at least one could hope >for (and drive toward) the minimal differences in >profiles that are needed to support any actual >differences in requirements. > >Thanks in advance for any information in this area. >--a. > > From chandras@loc201.tandem.com Fri Feb 21 06:54:35 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id GAA29671; Fri, 21 Feb 1997 06:54:35 -0800 Received: from booz-mail.bah.com by suntan.tandem.com (8.6.12/suntan5.970212) for id GAA29668; Fri, 21 Feb 1997 06:54:34 -0800 Received: from bah.com (smtpnt-al1.bah.com [156.80.9.200]) by booz-mail.bah.com (8.8.5/8.7.3) with SMTP id JAA10409; Fri, 21 Feb 1997 09:53:46 -0500 (EST) Date: Fri, 21 Feb 1997 10:17 -0500 From: "Simonetti David" To: gangolli@netscape.com, ietf-pkix@tandem.com Subject: RE: Profiles, Profiles, Profiles Message-ID: <8711C1DA@asq8po2.bah.com> Anil, I am the author of several of these profiles (MISSI and Federal PKI) and let me say that interoperability is one of the primary objectives in this work. We have worked closely in the past with those contributing to the PKIX and MISPC work to ensure that there are no interoperability concerns. Due to the general nature of X.509, I feel it is necessary that these profiles be developed to, in fact, foster interoperability. The intent of the profile is to standardize implementations and reduce the complexity of certificate generation and certificate processing. That is why we feel it necessary in the MISSI and Federal PKI profiles to provide somewhat more detail that other profiles. We also feel that specific extensions undoubtedly increase the security of the infrastructure, and that is why they are explicitly "profiled in". Also note that the profiles are not meant to be all inclusive. The profiles for MISSI and Federal PKI (and an uncoming ISO profile) all permit communities the opportunity to tailor and control certificate and CRL usage. If you have any specific questions on the profiles, please feel free to contact me. David Simonetti Booz-Allen & Hamilton Inc. 900 Elkridge Landing Road Linthicum, MD 21090 ---------- From: Anil R. Gangolli To: ietf-pkix Subject: Profiles, Profiles, Profiles Date: Thursday, February 20, 1997 9:12PM I am aware of the following certificate, crl, and/or verification profiles in development or existence today: 1. PEM (will be mostly obsolete, I expect, after PKIX) 2. PKIX (IETF) 3. MISSI 4. MISPC (NIST) 5. Federal PKI (Federal PKI-TWG) I worry that the proliferation of certificate profiles poses a serious threat to interoperability and will slow down the adoption and usability of PKI as a whole. Most of these profiles specify contents requirements for each field in the certificate, crl, etc.. Has anyone here done a comparative field-by-field analysis of these to see where they are in common and where they differ? (I suppose a comparitive analysis of the verification procedures may be harder to write down succinctly.) Any comparative analysis would be useful both to the IETF PKIX effort as well as these other profile efforts. Ideally there would be one uniform profile across the board, but barring that, at least one could hope for (and drive toward) the minimal differences in profiles that are needed to support any actual differences in requirements. Thanks in advance for any information in this area. --a. From chandras@loc201.tandem.com Fri Feb 21 07:42:34 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id HAA04044; Fri, 21 Feb 1997 07:42:34 -0800 Received: from dave.bbn.com by suntan.tandem.com (8.6.12/suntan5.970212) for id HAA04036; Fri, 21 Feb 1997 07:42:32 -0800 Received: (jlowry@localhost) by dave.bbn.com (8.6.9/150.200.504) id KAA17799; Fri, 21 Feb 1997 10:41:37 -0500 Date: Fri, 21 Feb 1997 10:41:37 -0500 From: John Lowry Message-Id: <199702211541.KAA17799@dave.bbn.com> To: D.Pinkas@frcl.bull.fr, fod@brd.ie Subject: Re: Private key possession Cc: dpkemp@missi.ncsc.mil, ietf-pkix@tandem.com X-Sun-Charset: US-ASCII Of course attributes are assigned by a CA and not automatically grated because the end user asked for them. They have to prove possession of the attribute (for some value of prove) just as they have to prove possession of the secret key. Attributes can also be assigned administratively. It really doesn't matter whether you "concent" to an attribute. An authority may assign one for their own (or other's) purposes. It works like that today. Suppose you really are a bad risk for a loan. Obviously you would not want an attribute certificate generated that made that statement. Tough nuggies. If you are then you are. If you aren't a bad risk then use existing procedure to fix it or sue. John > From chandras%loc201.tandem.com@suntan.tandem.com Thu Feb 20 20:13:03 1997 > To: D.Pinkas@frcl.bull.fr > cc: "David P. Kemp" , ietf-pkix@tandem.com > Subject: Re: Private key possession > Mime-Version: 1.0 > Date: Fri, 21 Feb 1997 00:43:48 +0000 > From: "Frank O'Dwyer" > > > There is another reason why demonstrating possession of a private > key might not be a good thing to make mandatory, and I think it > is more plausible than the patent example. For example, I might > want to make a local intranet certificate which binds certain > X.509 extensions to your key. This certificate permits you (say) > to upload signed files via my firewall. That doesn't seem an > unreasonable requirement, but I can't do it if I need to demonstrate > ability to use your private key. Certainly you (or your agent) could > request the same cert, but an intranet CA is likely to reject > out of hand certification requests that originate from outside. > > There are clearly other examples, too, where you might not want > to consent to an attribute (e.g. it says you are not a > good risk for a loan). Or, it might be confidential (you can't > decrypt it and therefore _can't_ consent to it). Still, I might wish > to request it, the CA might be willing to grant it, and someone else > might wish to trust it. But it's all impossible if I have to know > your private key. > > Seems like a broad class of applications to be ruling out. > > Cheers, > Frank O'Dwyer. > From chandras@loc201.tandem.com Fri Feb 21 07:40:19 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id HAA03858; Fri, 21 Feb 1997 07:40:19 -0800 Received: from csc.com by suntan.tandem.com (8.6.12/suntan5.970212) for id HAA03847; Fri, 21 Feb 1997 07:40:16 -0800 Received: from cscmail.csc.com by csc.com with smtp (Smail3.1.29.1 #1) id m0vxx1f-001Ax9C; Fri, 21 Feb 97 10:36 EST Received: by cscmail.csc.com(Lotus SMTP MTA v1.05 (274.9 11-27-1996)) id 85256445.0055EB8F ; Fri, 21 Feb 1997 10:38:28 -0400 X-Lotus-FromDomain: CSC From: ghilborn@va-fch31.csc.com To: ietf-pkix@tandem.com cc: fod@brd.ie Message-ID: <85256445.004DF4CC.00@cscmail.csc.com> Date: Fri, 21 Feb 1997 10:33:29 -0400 Subject: Re: Private key possession Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Gene Hilborn/SED/CSC 02/21/97 10:33 AM Frank O'Dwyer argues against requiring a CA to require a subject to prove possession of a private key before the CA issues a certificate (binding the subject to a public key). His argument seems to be that such cooperation of the subject means that the subject consents to all attributes in the certificate. I don't see any such semantics implicit in proof of possession of a private key. An analogous argument is saying that if I go into court and prove who I am then I am consenting to whatever I am accused of. Not so. That is a separate issue. There could be an implicit consent to certificate content when a subject includes and signs the certificate in a transaction, but that is a different matter. I see the real issue as simply whether every PKIX-compliant CA should be *required* to use some specified mechanism to verify that for each of its certificates, a public-key-submitting subject has current possession/usage of the corresponding private key. Or, should this verification be entirely optional as a matter of a CA's policy. If it such verification is optional, interoperability will be enhanced by limiting the CA's choices of mechanisms/protocols to a small specified set - perhaps one. Gene Hilborn From chandras@loc201.tandem.com Fri Feb 21 10:52:25 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id KAA06296; Fri, 21 Feb 1997 10:52:25 -0800 Received: from tahoma.mcom.com by suntan.tandem.com (8.6.12/suntan5.970212) for id KAA06286; Fri, 21 Feb 1997 10:52:23 -0800 Received: from tahoma (localhost [127.0.0.1]) by tahoma.mcom.com (940816.SGI.8.6.9/8.6.9) with SMTP id KAA25103; Fri, 21 Feb 1997 10:47:34 -0800 Sender: gangolli@netscape.com Message-ID: <330DEDC6.345B@netscape.com> Date: Fri, 21 Feb 1997 10:47:34 -0800 From: "Anil R. Gangolli" Organization: Netscape Server Product Development X-Mailer: Mozilla 3.01Gold (X11; U; IRIX 5.3 IP22) MIME-Version: 1.0 To: Simonetti David CC: ietf-pkix@tandem.com Subject: Re: Profiles, Profiles, Profiles References: <8711C1DA@asq8po2.bah.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Simonetti David wrote: > > Anil, > > I am the author of several of these profiles (MISSI and Federal PKI) and let > me say that interoperability is one of the primary objectives in this work. > We have worked closely in the past with those contributing to the PKIX and > MISPC work to ensure that there are no interoperability concerns. > > Due to the general nature of X.509, I feel it is necessary that these > profiles be developed to, in fact, foster interoperability. The intent of > the profile is to standardize implementations and reduce the complexity of > certificate generation and certificate processing. That is why we feel it > necessary in the MISSI and Federal PKI profiles to provide somewhat more > detail that other profiles. We also feel that specific extensions > undoubtedly increase the security of the infrastructure, and that is why > they are explicitly "profiled in". > > Also note that the profiles are not meant to be all inclusive. The profiles > for MISSI and Federal PKI (and an uncoming ISO profile) all permit > communities the opportunity to tailor and control certificate and CRL usage. > > If you have any specific questions on the profiles, please feel free to > contact me. > > David Simonetti > Booz-Allen & Hamilton Inc. > 900 Elkridge Landing Road > Linthicum, MD 21090 Hi, and thank you for responding. I fully agree on the need and support this effort. My only objection is to the plural "profiles". If there is indeed a common core to these proposals, it should be made explicit. Interoperability depends on this core. Maintaining multiple specifications for this common part introduces its own problems: First different language is prone to different interpretation and is thus detrimental to interoperability. Second, maintaining different specifications is comparable in difficulty to maintaining different versions of software --it's hard. There are many out here like me who are trying to keep abreast of these proposals in order to implement compliant and interoperating software. The worthy efforts by you and others in these working groups towards maintaining commonality would be more apparent (and more usable) if, at very least, the specifications would provide some comparative annotation and justification for the differences. At present every reader of every profile spec is left to fend for themselves in this regard. At the risk of sounding repetitive, if you have (or anyone else reading has) a field-by-field comparison available, I would appreciate it if you could post it. I think it would be of service to the community as well. If you could even summarize the differences between those profiles to which you contribute, that would also be helpful to some degree. --a. From chandras@loc201.tandem.com Fri Feb 21 11:48:24 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id LAA16037; Fri, 21 Feb 1997 11:48:24 -0800 Received: from dtol.com by suntan.tandem.com (8.6.12/suntan5.970212) for id LAA16017; Fri, 21 Feb 1997 11:48:19 -0800 Received: from bwdldb.ott.bnr.ca (dialup9 [206.51.1.109]) by dtol.com (8.6.12/8.6.9) with SMTP id PAA26828 for ; Fri, 21 Feb 1997 15:44:58 GMT Received: by bwdldb.ott.bnr.ca with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC2004.6A1ACAB0@bwdldb.ott.bnr.ca>; Fri, 21 Feb 1997 14:34:59 -0500 Message-ID: From: Carlisle Adams To: "'peter@verisign.com'" Cc: "'ietf-pkix@tandem.com'" Subject: RE: Private key possession Date: Fri, 21 Feb 1997 14:34:36 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 117 TEXT Hi, >---------- >From: peter@verisign.com[SMTP:peter@verisign.com] >Sent: Thursday, February 20, 1997 2:58 PM >To: D.Pinkas@frcl.bull.fr; dpkemp@missi.ncsc.mil >Cc: ietf-pkix@tandem.com >Subject: Re: Private key possession > >I would personally agree with the notion than an Internet-centric CA >infrastructure >which is NOT given over to ONLY supporting non-repudation grade services, >should NOT need to make the estabishment of private key of a subscriber a >mandatory, uniform requirement, or that all PKIX-using software should assume such >a condition >of a CA claiming conformance to PKIX > >I would argue, that based on the disclosed operating policy of the CA, and >any reliability criteria, such a property can be relied upon by those >subscribers/users >with a need, based upon their "acceptance" and utility of the policy rules to >their environment. > All I agreeing technically here, is that technical mechanisms and >operating policy are naturally separated in this protocol standard, as everywhere else in the >open networking world. > >On this basis, I would agree with Denis' proposal to change the mandatory >language, and do >react to the apparent intent of those who wrote it to uniformly constrain the >key management infrastructure in a policy-specific manner. Rather than invent slightly malicious "intent" out of the blue, impute it to another party, and then publicly criticize that party for supposedly having that intent, why don't we try to focus on the facts of the issue at hand? What, exactly, does a CA do? It may do a number of things, but the primary thing that it does (in fact, it's entire reason for existence) is to assert a binding between an entity and a key. This binding is, after all, the definition of a certificate, and a CA is not a CA if it does not issue certificates. Fair enough, but *which* key? On the surface, it appears that the binding is between the entity and the public key, since this is what the certificate contains. A few moment's reflection, however, will show that this couldn't possibly be true. The public key, by definition, is a purely public quantity; anyone (and, if interested, everyone) can claim knowledge of it, and an assertion to that effect by a CA is a completely meaningless assertion. No, the CA asserts a binding between the entity and the private key. Under two assumptions ("a", that the entity is the only one who knows the private key, and "b", that it is computationally infeasible to derive the private key from the public key), a certificate for Joe says that "if you encrypt something using the contained public key then only Joe can decrypt it", or "if you verify a signature using the contained public key then Joe must have signed it". Clearly, the CA can only validly assert such a binding if, in fact, it is convinced that such a binding exists. It is hard to put this any more clearly. This is *not* a policy issue, by any stretch of the imagination. A certificate (by definition) states a binding between an entity and its *private* key and a CA (by definition) is trusted to be the one to assert this binding. This is the fundamental underlying principle of a public key infrastructure (i.e., without this principle "certificates" are meaningless bundles of bits and there is no credible PKI). Making proof-of-possession-of-private-key a mandatory aspect of the certification process is not "constraining the key management infrastructure in a policy-specific manner". It is making explicit an underlying principle of the PKI and ensuring that it is implemented correctly. This may not be so important in a closed environment in which one vendor supplies all the bits and pieces and builds the same assumptions into them all, but it is critical in an open environment with open protocols and multiple vendors. That is what PKIX is trying to design for the Internet PKI so it is essential to make those assumptions explicit so that all the bits and pieces do the right thing. O.K., so at this point presumably Denis jumps in and says that he can't trust a CA to do the "right thing" even if it is mandatory in the protocol, which is why he raised this issue in the first place. His solution is to make it optional (or absent) in the protocol and to put the necessary checks and balances in other operational protocols (or perhaps even to modify the certificate format itself). On the contrary, it seems to me that the issue he raises shows that proof-of-possession really should be mandatory. Why? If a CA claims conformance to PKIX, and PKIX mandates proof-of-possession, then when it is discovered that the CA did not actually do the proof-of-possession (i.e., certificates are found for Alice and Bob which contain the same public key), legal action can be taken against the malpractice. The CA can be sued for damages, or driven out of business, or whatever. In any case, its certificate is revoked and all certificates issued by it will no longer verify. If, on the other hand, proof-of-possession is optional or absent, no legal recourse is available and there is no way to remove the bad certificates from the system. Note that making proof-of-possession mandatory does not preclude putting checks and balances in other protocols anyway, if people want to do so; it just makes them unnecessary. To be perfectly honest, I don't understand what all the resistance is about. It's not like adding proof-of-possession adds much extra computation or overhead to the protocol (especially given the assurance it offers). Furthermore, all those proponents of PKCS #10 (Peter, I believe you were one) already *do* proof-of-possession. PKIX-3 is simply stating that this should be done for encryption and Diffie-Hellman certification requests as well, which PKCS #10 does not do in its present form. >-------------------------------------- >Carlisle Adams >Entrust Technologies >cadams@entrust.com >--------------------------------------- From chandras@loc201.tandem.com Fri Feb 21 12:28:29 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id MAA21814; Fri, 21 Feb 1997 12:28:29 -0800 Received: from booz-mail.bah.com by suntan.tandem.com (8.6.12/suntan5.970212) for id MAA21809; Fri, 21 Feb 1997 12:28:28 -0800 Received: from bah.com (smtpnt-al1.bah.com [156.80.9.200]) by booz-mail.bah.com (8.8.5/8.7.3) with SMTP id PAA07687; Fri, 21 Feb 1997 15:26:46 -0500 (EST) Date: Fri, 21 Feb 1997 15:50 -0500 From: "Simonetti David" To: gangolli@netscape.com Cc: ietf-pkix@tandem.com Subject: Re: Profiles, Profiles, Profiles Message-ID: <73FDACE1@asq8po2.bah.com> Anil, I understand your dilemma, and will try to address some of your issues. I expect the MISPC profile and the Federal PKI profile to agree, if not be one in the same, at some point, so I'd like to leave that as that. The MISSI profile and Federal profile have differences that are mainly due to two reasons. First, MISSI is developing its own components, e.g., CAW and User Agent. The Federal group is constrained by the use of "Commercial Off The Shelf" (COTS) products. Thus, as an example, MISSI profiles the use of what I might consider "efficiency-related" extensions such as authorityKeyIdentifier and subjectKeyIdentifier. We've reasoned that requiring the Federal COTS products to implement these extensions may be overly constraining, and products shouldn't be ruled out solely because they did not implement these two extensions. The Federal profile does, however, recommend use of these extensions whenever possible. Secondly, MISSI and the FPKI operate under fundamentally different architectures. MISSI implements a strictly hierarchical infrastructure and prohibits cross-certification at any level below their top-level CA (Policy Approving Authority - PAA). The FPKI implements a hybrid infrastructure combining elements of the hierarchical and network infrastructure models (recommend you review the FPKI CONOP for more info here). These fundamental differences necessitate differences between the profiles. The inhibitPolicyMapping field of policyConstraints is probably a good example of one difference. There are also fundamental differences between the PKIX infrastructure and the MISSI/FPKI infrastructures. PKIX does not assume the existence of an X.500 Directory, and, for example, allows the subject of the base certificate to be "null" and the subjectAltName to be of some form other than directoryName. MISSI and FPKI continue X.500 reliance and require the subject of the base certificate to be the directoryName (yes, potential non-interoperabilty), and make more limited use of the subjectAltName extension. Additionally, PKIX has added private extensions which are not part of the MISSI/FPKI profiles. In summary, there are many fundamental differences between the target systems, much too many for me to identify here. I recommend you review the subject documents for each system; they are intended to provide sufficient detail for implementation (the FPKI document is still draft; I am, at this moment, updating it based on recent comments). I think it is up to the product vendors to decide which community they see as a potential market, and develop their products based on that community's requirements. I think the safe bet is to implement X.509 as it is written (I hope!). It will then be up to the CAs to generate certificates that will work between the intended systems. Hope this helps some. David Simonetti Booz-Allen & Hamilton 900 Elkridge Landing Road Linthicum, MD 21090 ---------- From: Anil R. Gangolli To: Simonetti David Cc: ietf-pkix Subject: Re: Profiles, Profiles, Profiles Date: Friday, February 21, 1997 1:56PM Simonetti David wrote: > > Anil, > > I am the author of several of these profiles (MISSI and Federal PKI) and let > me say that interoperability is one of the primary objectives in this work. > We have worked closely in the past with those contributing to the PKIX and > MISPC work to ensure that there are no interoperability concerns. > > Due to the general nature of X.509, I feel it is necessary that these > profiles be developed to, in fact, foster interoperability. The intent of > the profile is to standardize implementations and reduce the complexity of > certificate generation and certificate processing. That is why we feel it > necessary in the MISSI and Federal PKI profiles to provide somewhat more > detail that other profiles. We also feel that specific extensions > undoubtedly increase the security of the infrastructure, and that is why > they are explicitly "profiled in". > > Also note that the profiles are not meant to be all inclusive. The profiles > for MISSI and Federal PKI (and an uncoming ISO profile) all permit > communities the opportunity to tailor and control certificate and CRL usage. > > If you have any specific questions on the profiles, please feel free to > contact me. > > David Simonetti > Booz-Allen & Hamilton Inc. > 900 Elkridge Landing Road > Linthicum, MD 21090 Hi, and thank you for responding. I fully agree on the need and support this effort. My only objection is to the plural "profiles". If there is indeed a common core to these proposals, it should be made explicit. Interoperability depends on this core. Maintaining multiple specifications for this common part introduces its own problems: First different language is prone to different interpretation and is thus detrimental to interoperability. Second, maintaining different specifications is comparable in difficulty to maintaining different versions of software --it's hard. There are many out here like me who are trying to keep abreast of these proposals in order to implement compliant and interoperating software. The worthy efforts by you and others in these working groups towards maintaining commonality would be more apparent (and more usable) if, at very least, the specifications would provide some comparative annotation and justification for the differences. At present every reader of every profile spec is left to fend for themselves in this regard. At the risk of sounding repetitive, if you have (or anyone else reading has) a field-by-field comparison available, I would appreciate it if you could post it. I think it would be of service to the community as well. If you could even summarize the differences between those profiles to which you contribute, that would also be helpful to some degree. --a. From chandras@loc201.tandem.com Fri Feb 21 15:40:40 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id PAA21154; Fri, 21 Feb 1997 15:40:40 -0800 Received: from zafu.bbn.com by suntan.tandem.com (8.6.12/suntan5.970212) for id PAA21151; Fri, 21 Feb 1997 15:40:39 -0800 Received: from [128.33.229.241] ([128.33.229.241]) by zafu.bbn.com (8.7.5/8.6.5) with ESMTP id SAA15988; Fri, 21 Feb 1997 18:40:29 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <330BB065.161@frcl.bull.fr> References: <199702191524.KAA16394@argon.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Feb 1997 15:25:04 -0500 To: D.Pinkas@frcl.bull.fr From: Stephen Kent Subject: Re: Private key possession Cc: ietf-pkix@tandem.com Denis, The notion of a user countersigning a certificate does address the problem you cited, but since not all uses of signature certificates are for non-repudiation, it seems more appropriate to have an application that requires non-repudiation engineer the necessary mechanisms into the application. Otherwise one could make the argument that a timestamp should be included with each signature (and I have seen such proposals), because of the benefits that would accrue in some applications. Now one might argue that there are other, more general benefits to the countersigned cert approach, but the required change to the cert format is rather significant and one would have to marshall a lot of strong arguments in order to persuade folks to accept it. I don't think we have seen such arguments and, given the charter of PKIX (relative to .509) I don't think it is within scope for this WG. Steve From chandras@loc201.tandem.com Fri Feb 21 15:40:57 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id PAA21193; Fri, 21 Feb 1997 15:40:57 -0800 Received: from zafu.bbn.com by suntan.tandem.com (8.6.12/suntan5.970212) for id PAA21190; Fri, 21 Feb 1997 15:40:56 -0800 Received: from [128.33.229.241] ([128.33.229.241]) by zafu.bbn.com (8.7.5/8.6.5) with ESMTP id SAA16009; Fri, 21 Feb 1997 18:40:48 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3.0.32.19970220115801.0103f0b4@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Feb 1997 16:16:19 -0500 To: Peter Williams From: Stephen Kent Subject: Re: Private key possession Cc: ietf-pkix@tandem.com Peter, I don't agree with your conclusions, though I understand the principle you cite. If our standards require CAs to engage in a protocol that demonstrates the certificate requestor does hold the corresponding private key, then we are, I believe, codifying a practice that most people would assume is appropriate and that is consistent with the basic premises of certification, i.e., that the subject of a certificate does hold the corresponding private key. True, we cannot ensure that all CAs will do this, or will do it properly, but if they fail to do so, then they are non-compliant (and will burn in the fires of hell as a result, no doubt). I think we are merely trying to establish a convention that matches normal expectations, and I have not seen any arguments that convince me that this is a bad thing to do, i.e., that this is an unduly restrictive policy. Yes, one could accomplish a similar (maybe equivalent) effect through the use of appropriate CPSs, but I'm not sure that is the right basis on which to make this decision. Do we believe that there are circumstances where issuance of a cert is appropriate and yet the subject does not hold the private key? If not, then is the issue that it is infeasible for the subject to demonstrate possesion of the private key? If neither or the above, I see no reason for making this an optional, vs. mandatory, aspect of certificate issuance. Steve From chandras@loc201.tandem.com Fri Feb 21 15:40:55 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id PAA21186; Fri, 21 Feb 1997 15:40:55 -0800 Received: from zafu.bbn.com by suntan.tandem.com (8.6.12/suntan5.970212) for id PAA21183; Fri, 21 Feb 1997 15:40:53 -0800 Received: from [128.33.229.241] ([128.33.229.241]) by zafu.bbn.com (8.7.5/8.6.5) with ESMTP id SAA16003; Fri, 21 Feb 1997 18:40:42 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199702210043.AAA11163@brd.ie> References: Your message of "Thu, 20 Feb 1997 14:19:16 PST." <330CCDE4.1E2B@frcl.bull.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Feb 1997 16:04:52 -0500 To: "Frank O'Dwyer" From: Stephen Kent Subject: Re: Private key possession Cc: D.Pinkas@frcl.bull.fr, "David P. Kemp" , ietf-pkix@tandem.com Frank, let me see if I understand the scenario you cited a a justification for not requiring a user to demonstrate possesion of a private key. A CA wants to create a cert with some authorization extensions by taking a public key from some other cert and stuffing it into the new cert. The CA doing this is inside a net associated with the resources to which access will be granted, based on use of the new cert. However, this CA is not able to allow a cert request to reach it from outside, where the user who is to be granted authorization lives, presumably due to security concerns. Is this an accurate characterization? If so, I'd like to observe that CAs performing online cert issuance tend to operate in the fashion that your scenario suggest would not be vaible, i.e., the CA is behind a firewall and it receives cerg requests from the open Internet, and that is exactly how it does it's job. We have supplied CAs of this sort to clients, and I know of others that work this way, and it has not been a problem. Also reusing the same key in multiple certificates is often frowned upon, since it is not clear under what policy the keys are being used, i.e., ambiguity results when any of several certificates can be matched to the same private key. The second set of examples you provided also concern me. As a user, I don't want to be issused a certificate that I didn't ask for, but with my public key in it, in much the same way that I don't like receiving unsolicited credit cards on the mail. Requiring proof of possesion as part of certificate issuance helps prevent such unsolicited issuance, since a CA would not be able to prove that I requested the cert in question. (Of course this does not solve the bigger problem of having a cert issed with some other public key in it and having it bound to my name, but relaxing the proof-of-possesion requirement also does not address that problem.) It seems that there might be a common thread in these examples, i.e., the question of whether a third party ought to be able to cause a certificate to be issued containing a key already associated with a user, but without the consent or active participation of the user. Is this a feature, or a bug? Making proof-of-possesion an optional aspect of cert requests side steps the question, but is that good? Steve From chandras@loc201.tandem.com Fri Feb 21 16:05:35 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id QAA24632; Fri, 21 Feb 1997 16:05:35 -0800 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id QAA24624; Fri, 21 Feb 1997 16:05:34 -0800 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id QAA27757; Fri, 21 Feb 1997 16:03:36 -0800 (PST) Received: from peter.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id QAA12376; Fri, 21 Feb 1997 16:04:16 -0800 (PST) Message-Id: <3.0.32.19970221160555.00704a78@mail> X-Sender: peter@mail X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 21 Feb 1997 16:05:56 -0800 To: Carlisle Adams From: Peter Williams Subject: RE: Private key possession Cc: "'ietf-pkix@tandem.com'" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Carlise, I have no problem verifying the PKCS#10 SIGNED protocol elements (using the procedures defined by the signature algoirithm) on incoming subscription requests seeking to register certified keys, and thus ensuring the CA has assurance of the originator's possession of the private key. Now, is this issue so critical in PKIX, and therefore mandatory for conformance, that I have, as a result, say, to keep proper (repeatable) and auditable records of this verification? We are all agreed testing availability of the private key is generally a good thing, though some argue there are contrary cases. Now why are some folk insisting its mandatory for conformance, versus merely a recommendation, say? Is there a functional or implementation assurance condition present, which can be made explicit to substantiate such the "mandatory" condition requirement? "(especially given the assurance it offers)" >To be perfectly honest, I don't understand what all the resistance is >about. It's not like adding proof-of-possession adds much extra >computation or overhead to the protocol (especially given the assurance >it offers). Furthermore, all those proponents of PKCS #10 (Peter, I >believe you were one) already *do* proof-of-possession. PKIX-3 is >simply stating that this should be done for encryption and >Diffie-Hellman certification requests as well, which PKCS #10 does not >do in its present form. > >>-------------------------------------- >>Carlisle Adams >>Entrust Technologies >>cadams@entrust.com >>--------------------------------------- > > From chandras@loc201.tandem.com Fri Feb 21 16:13:07 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id QAA26043; Fri, 21 Feb 1997 16:13:07 -0800 Received: from relay.ieunet.ie by suntan.tandem.com (8.6.12/suntan5.970212) for id QAA26039; Fri, 21 Feb 1997 16:13:05 -0800 Received: from db-18.dialup.eunet.ie by relay.ieunet.ie with SMTP id aa20108; 22 Feb 97 0:12 +0000 Received: from brd.ie (fod@localhost [127.0.0.1]) by brd.ie (8.7.5/8.7.3) with ESMTP id AAA12368; Sat, 22 Feb 1997 00:03:40 GMT Message-Id: <199702220003.AAA12368@brd.ie> X-Mailer: exmh version 1.6.7 5/3/96 To: ghilborn@va-fch31.csc.com Cc: ietf-pkix@tandem.com Subject: Re: Private key possession In-reply-to: Your message of "Fri, 21 Feb 1997 10:33:29 -0400." <85256445.004DF4CC.00@cscmail.csc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Feb 1997 00:03:39 +0000 From: "Frank O'Dwyer" > Frank O'Dwyer argues against requiring a CA to require a subject to prove > possession of a private key before the CA issues a certificate (binding the > subject to a public key). His argument seems to be that such cooperation > of the subject means that the subject consents to all attributes in the > certificate. I don't see any such semantics implicit in proof of > possession of a private key. No, that's not what I meant. If the _only_way_ of requesting a certificate requires that a proof of possession of the private key be done, then this (as a side effect) turns the private key into an instrument of granting and witholding consent to certification requests. (N.B. - _requests_). I don't believe that's what is intended, and I think it stops you from doing some interesting applications. >From talking to Stephen Farrell, I gather that a possibility is in fact that the proof would be (required to be) done to an RA, but a CA might not necessarily require it of an RA. If I have that right, then that would answer all the concerns I raised in my previous message, since an RA could ask for any certificate it liked, without necessarily needing to know the subject's private key. (And of course a CA could create any certificate it wanted to anyhow). Just to be clear, I do think it's a good idea that somebody somewhere always requires a demonstration of private key possession, since it is a simple measure that makes many "social engineering" attacks against the CA significantly more difficult. The RA seems like a good place to do it. It limits the scope for abuse of requests (because most entities are not RAs), without limiting what you can implement with the PKIX. However putting the requirement all the way back at the _CA_ would imo be too restrictive, for the reasons I gave before. Cheers, Frank O'Dwyer. From chandras@loc201.tandem.com Fri Feb 21 16:38:17 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id QAA00134; Fri, 21 Feb 1997 16:38:17 -0800 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id QAA00129; Fri, 21 Feb 1997 16:38:16 -0800 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id QAA09085; Fri, 21 Feb 1997 16:36:23 -0800 (PST) Received: from peter.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id QAA21442; Fri, 21 Feb 1997 16:37:02 -0800 (PST) Message-Id: <3.0.32.19970221163842.00704a78@mail> X-Sender: peter@mail X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 21 Feb 1997 16:38:42 -0800 To: Carlisle Adams From: Peter Williams Subject: RE: Private key possession Cc: "'ietf-pkix@tandem.com'" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Carlise I suspect you dont mean all this in the literal legal sense, as its just not appropriate for the techncial PKIX1/3 specs to be apparently engineering a legal framework by virtue of its conformance claim design. Its not appropriate for an ISO standard, even given its due process and PICS methods, and even less for an RFC. While I would expect any security provider to explain to the jury why they did not use a standard and publicly reviewed security process/format (having had some proprietary equivalent function broken, and causing user damages), I dont see the language of, or function of, PKIX ever being so tightly drafted or agreed so as to serve more specific judicial purposes concerning regulation of IAs, or supporting civil/professional actions against IAs not satisfying their own local or policy claims. We have to be sure any such intentions are exorcised from a technical interworking spec. If the technical document is truely being rigged for such non-technical purposes, we need much more careful review by accreditation and legal specialists. Such matters are clearly policy. If a CA claims conformance to PKIX, >and PKIX mandates proof-of-possession, then when it is discovered that >the CA did not actually do the proof-of-possession (i.e., certificates >are found for Alice and Bob which contain the same public key), legal >action can be taken against the malpractice. The CA can be sued for >damages, or driven out of business, or whatever. In any case, its >certificate is revoked and all certificates issued by it will no longer >verify. If, on the other hand, proof-of-possession is optional or >absent, no legal recourse is available a From chandras@loc201.tandem.com Fri Feb 21 17:57:24 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id RAA10662; Fri, 21 Feb 1997 17:57:24 -0800 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id RAA10658; Fri, 21 Feb 1997 17:57:23 -0800 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id RAA06019; Fri, 21 Feb 1997 17:55:29 -0800 (PST) Received: from peter.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id RAA13046; Fri, 21 Feb 1997 17:56:10 -0800 (PST) Message-Id: <3.0.32.19970221175749.00707580@mail> X-Sender: peter@mail X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 21 Feb 1997 17:57:49 -0800 To: Stephen Kent From: Peter Williams Subject: Re: Private key possession Cc: ietf-pkix@tandem.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Steve, (a) I find myself disagreeing not with any of your basic recent arguments, but remain wholly unconvinced that a technical protocol should ever embed any issuing or management handling procedures, even when conventionally and/or reasonably expected in a many services defined to use that protocol. My argument is mainly religious, and concerns the known benefits of ensuring protocol and service definition are separated. There are just always enviornment-specific cases where the service needs a different policy. I could expect the PKIX "policy" document to perhaps list those operating expectations - codifying thus the minimal operational conformance criteria for PKIX-conformant IAs, based on their global reasonableness. One could then expect the policy statment of each CA to claim it satisfies the PKIX expectation/issues list, should it wish. If there are indeed elements of default policy built into the protocol design, based on the designer's expections and beliefs, then perhaps they should be identified as options (or at least identified for review purposes), and, as I say, possibly abstracted out as generic policy rules in the policy document. Given that the judgements were already taken, and are present in the document, they cannot be too hard to at least enumerate. This will serve later, by elimination of certain types of legal debate as to intended meanings and policy purposes of technical specs. (b) Expectation-based handling of conditions such as "one key : one certificate", which may produce ambiguity potential, really worry me. Either the policy mechanism and key usage mechanisms in X.509 are sufficient, or not (*). It seems once again we are avoiding use (or design) of standard instruments, and loading semantics and expectations mechanisms into technical procedures. Where there are signals for such purposes, and std or per-CA policy documents to disclose their very precise semantics, it worrying to see their non-use, and therefore a potential biasing of the technical protocol design. (* little can prevent one key being issued with one set of characterisics by one CA, and another set by another CA, and being used by a single subscriber. The only differentiator of semantics and requirements for enrollment ultimately is the issuing policy (CPS) of the CA, and are ultimately enforced only via the agreements of the subscribers and verifying parties, to the various request, use and reliance obligations) (c) "Requiring proof of possesion as part of certificate issuance helps prevent such unsolicited issuance, since a CA would not be able to prove that I requested the cert in question." Once again, I see "leakage" of semantics. We start out with an expectation that its good practice to have proof of possession, and now the CA has suddenly received the obligation to possibly prove it received a request, based upon that information. This would lead me to believe, that the mandatory mechanism could have the effect of requiring CAs to maintain and verify proof of request, given an available mechanism exists for such purpose. In agreeing to enforce something socially friendly (.e. prove possession), a CA now find itself suddenly loaded with ambiguity of semantics, and consequently additional handling obligations which have nothing to do with the intended effect on the quality of the PKI, but which may instrument legal and political matters. Who knows what other implications there are, once there is a first - instrument for registration of crypto-capabilities, possibly!? Perhaps the generic issuing (aka CA ethical behaviour) policy of PKIX wishes to mandate such matters; but once again, the issue should be explicit, and separated from a specification of message formats and crypto handling procedures. Issuing parties can then claim conformance to (i) technical matters (ii) generic policy matters, as their markets and customers require. This was a very way of saying I really disagree with little except your basic conclusions. At 04:04 PM 2/21/97 -0500, Stephen Kent wrote: >Frank, > > let me see if I understand the scenario you cited a a justification >for not requiring a user to demonstrate possesion of a private key. A CA >wants to create a cert with some authorization extensions by taking a >public key from some other cert and stuffing it into the new cert. The CA >doing this is inside a net associated with the resources to which access >will be granted, based on use of the new cert. However, this CA is not >able to allow a cert request to reach it from outside, where the user who >is to be granted authorization lives, presumably due to security concerns. >Is this an accurate characterization? > > If so, I'd like to observe that CAs performing online cert issuance >tend to operate in the fashion that your scenario suggest would not be >vaible, i.e., the CA is behind a firewall and it receives cerg requests >from the open Internet, and that is exactly how it does it's job. We have >supplied CAs of this sort to clients, and I know of others that work this >way, and it has not been a problem. Also reusing the same key in multiple >certificates is often frowned upon, since it is not clear under what policy >the keys are being used, i.e., ambiguity results when any of several >certificates can be matched to the same private key. > > The second set of examples you provided also concern me. As a >user, I don't want to be issused a certificate that I didn't ask for, but >with my public key in it, in much the same way that I don't like receiving >unsolicited credit cards on the mail. Requiring proof of possesion as part >of certificate issuance helps prevent such unsolicited issuance, since a CA >would not be able to prove that I requested the cert in question. (Of >course this does not solve the bigger problem of having a cert issed with >some other public key in it and having it bound to my name, but relaxing >the proof-of-possesion requirement also does not address that problem.) > > It seems that there might be a common thread in these examples, >i.e., the question of whether a third party ought to be able to cause a >certificate to be issued containing a key already associated with a user, >but without the consent or active participation of the user. Is this a >feature, or a bug? Making proof-of-possesion an optional aspect of cert >requests side steps the question, but is that good? > >Steve > > > > From chandras@loc201.tandem.com Fri Feb 21 18:22:39 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id SAA13675; Fri, 21 Feb 1997 18:22:39 -0800 Received: from novell.com by suntan.tandem.com (8.6.12/suntan5.970212) for id SAA13672; Fri, 21 Feb 1997 18:22:38 -0800 Received: from INET-SJF-Message_Server by novell.com with Novell_GroupWise; Fri, 21 Feb 1997 18:22:05 -0800 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 21 Feb 1997 18:21:26 -0800 From: Fred Ou To: smime-dev-request@rsa.com, ietf-pkix@tandem.com Subject: Any ideas of collecting random seeds from NT 4.0 I am going to implement a random number generator for key generation. I like to get some ideas about the good sources in NT 4.x for random seeds collecting from this group. Thank you very much! -Fred From chandras@loc201.tandem.com Sat Feb 22 03:27:13 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id DAA16236; Sat, 22 Feb 1997 03:27:13 -0800 Received: from relay.ieunet.ie by suntan.tandem.com (8.6.12/suntan5.970212) for id DAA16231; Sat, 22 Feb 1997 03:27:10 -0800 Received: from db-32.dialup.eunet.ie by relay.ieunet.ie with SMTP id aa16368; 22 Feb 97 11:26 +0000 Received: from brd.ie (fod@localhost [127.0.0.1]) by brd.ie (8.7.5/8.7.3) with ESMTP id LAA12866; Sat, 22 Feb 1997 11:27:46 GMT Message-Id: <199702221127.LAA12866@brd.ie> To: Stephen Kent Cc: ietf-pkix@tandem.com Subject: Re: Private key possession In-reply-to: Your message of "Fri, 21 Feb 1997 16:04:52 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Feb 1997 11:27:46 +0000 From: "Frank O'Dwyer" > let me see if I understand the scenario you cited a a justification > for not requiring a user to demonstrate possesion of a private key. A CA > wants to create a cert with some authorization extensions by taking a > public key from some other cert and stuffing it into the new cert. The CA > doing this is inside a net associated with the resources to which access > will be granted, based on use of the new cert. However, this CA is not > able to allow a cert request to reach it from outside, where the user who > is to be granted authorization lives, presumably due to security concerns. > Is this an accurate characterization? Yes, that's it. I have two fairly concrete scenarios in mind: (a) the user has a certificate from Verisign or a similar neutral CA outside the company. I want to allow the user limited access based on that public key, but I don't want to allow everyone with a Verisign cert in, and I don't want to have to maintain ACLs. I also want this to be valid for just three weeks, whereas the user's current cert is good for a year. I'm assuming requests for intranet certs cannot traverse the company firewall (although I take your point below). (b) the user has a certificate for use in some other company's intranet. Otherwise, as above. > If so, I'd like to observe that CAs performing online cert issuance > tend to operate in the fashion that your scenario suggest would not be > vaible, i.e., the CA is behind a firewall and it receives cerg requests > from the open Internet, and that is exactly how it does it's job. We have > supplied CAs of this sort to clients, and I know of others that work this > way, and it has not been a problem. What you're describing sounds like a firewalled internet CA, where requests from the internet are normal and expected. However, if you have an _intranet_ CA, then a "nothing from outside" rule would seem quite natural. You can certainly imagine some people wanting that, even if it's only a perception issue. It's new software, after all. > Also reusing the same key in multiple > certificates is often frowned upon, since it is not clear under what policy > the keys are being used, i.e., ambiguity results when any of several > certificates can be matched to the same private key. Well, I think multiple certs for the same key will be a fact of life, if only because we won't all trust the same CAs, but we will still need to interwork. We will also disagree about which attributes belong with a key (and even about which attributes are defined!). Cross-certificates will help here but I don't think they solve every issue. Or, another approach is to have multiple private keys, which will probably happen too, but may not always work either (e.g. suppose you want to sign a doc and have it believed in multiple domains, but they do not have a common point of trust. As far as I can see you then need to sign more than once with different keys, or you need multiple certs for the same key.) > The second set of examples you provided also concern me. As a > user, I don't want to be issused a certificate that I didn't ask for, but > with my public key in it, in much the same way that I don't like receiving > unsolicited credit cards on the mail. Requiring proof of possesion as part > of certificate issuance helps prevent such unsolicited issuance, since a CA > would not be able to prove that I requested the cert in question. (Of > course this does not solve the bigger problem of having a cert issed with > some other public key in it and having it bound to my name, but relaxing > the proof-of-possesion requirement also does not address that problem.) Sure, but the flip side is that, as a CA, I don't want to be constrained to issuing certificates that you request or even certificates that you like. Someone may want to issue a certificate saying "The holder of this public key teases cats", or "the holder of this public key is ugly, incompetent, and known to the police". As soon as the attributes get interesting then there will undoubtedly arise such controversial and even libellous certificates. Whether this type of thing is desirable or not is a political/moral question that people won't agree on. But it doesn't seem appropriate to take a position on it at the protocol level. > It seems that there might be a common thread in these examples, > i.e., the question of whether a third party ought to be able to cause a > certificate to be issued containing a key already associated with a user, > but without the consent or active participation of the user. Is this a > feature, or a bug? Making proof-of-possesion an optional aspect of cert > requests side steps the question, but is that good? To be able to require the active participation of the user would imo be a feature. To be unable to do anything else would imo be a bug. I think maybe if the RA requires the proof, but the CA doesn't necessarily require it, then you get both options? Cheers, Frank O'Dwyer. From chandras@loc201.tandem.com Sat Feb 22 03:58:43 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id DAA17614; Sat, 22 Feb 1997 03:58:43 -0800 Received: from relay.ieunet.ie by suntan.tandem.com (8.6.12/suntan5.970212) for id DAA17610; Sat, 22 Feb 1997 03:58:41 -0800 Received: from db-44.dialup.eunet.ie by relay.ieunet.ie with SMTP id aa20470; 22 Feb 97 11:58 +0000 Received: from brd.ie (fod@localhost [127.0.0.1]) by brd.ie (8.7.5/8.7.3) with ESMTP id LAA13108; Sat, 22 Feb 1997 11:47:24 GMT Message-Id: <199702221147.LAA13108@brd.ie> To: Fred Ou Cc: smime-dev-request@rsa.com, ietf-pkix@tandem.com Subject: Re: Any ideas of collecting random seeds from NT 4.0 In-reply-to: Your message of "Fri, 21 Feb 1997 18:21:26 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Feb 1997 11:47:23 +0000 From: "Frank O'Dwyer" > I am going to implement a random number generator for key generation. > I like to get some ideas about the good sources in NT 4.x for random > seeds collecting from this group. Look for Peter Gutmann's cryptlib on the net. It contains some code that does what you want, and it seems pretty well thought out. Cheers, Frank O'Dwyer. From chandras@loc201.tandem.com Mon Feb 24 03:28:14 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id DAA24922; Mon, 24 Feb 1997 03:28:14 -0800 Received: from clbull.frcl.bull.fr by suntan.tandem.com (8.6.12/suntan5.970212) for id DAA24913; Mon, 24 Feb 1997 03:28:11 -0800 Received: from dore (dore.frcl.bull.fr [129.182.42.156]) by clbull.frcl.bull.fr (8.7.5/8.7.3) with SMTP id MAA15432 for ; Mon, 24 Feb 1997 12:19:17 +0100 Received: from dese22 by dore (AIX 4.1/UCB 5.64/4.03) id AA35482; Mon, 24 Feb 1997 12:26:04 +0100 Message-Id: <3311F9C7.6379@frcl.bull.fr> Date: Mon, 24 Feb 1997 12:27:51 -0800 From: Denis Pinkas Reply-To: D.Pinkas@frcl.bull.fr Organization: Bull X-Mailer: Mozilla 3.0 (Win16; I) Mime-Version: 1.0 To: ietf-pkix@tandem.com Subject: Re: Private key possession Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve, Gene, Carlisle, Peter, Frank ... and all others This is single reply to all of you, that I will attempt to make short, I would like first to re-focus on the original matter. A. The original question was : Should a protocol, proving possession of the private key to the *CA*, be mandatorilly supported to claim conformance to PKIX ? My answer to this question is NO. There are various simple arguments for this, among them: 1) As Franck said , that proof may be given by the user to a RA and the CA will trust the (signed request of the) RA to have done the verification. 2) The CA (or the RA) may be the entity generating the private key and thus the user is unable to support any such protocol.. In other words we cannot suppose that the subject will always generate the key. This demonstrates that the proposed protocol is just one of the alternatives to do it, and not the *single* way to do it. Can we, first, all agree on this ? B. The remaining of this E-mail is important as well, but I would really like the opinion of the group on that question first. :-) I truly like many parts of the presentation from Carlisle in particular when he says that "the CA asserts a binding between the entity and the private key". I also agree to say that proof-of-possession-of-private-key is a mandatory aspect of the certification process (this does not mean that this must be done by that *protocol* only). I almost agree when he says " Clearly, (an honest) CA can only validly assert such a binding if, in fact, it is convinced that such a binding exists". The general statement is that any CA should use appropriate mechanisms AND procedures to make sure that for each of its certificates, the subject has current possession/usage of the corresponding private key. Can we agree on that statemment too ? Carlisle says (and I fully agree) : " If a CA claims conformance to PKIX, and PKIX mandates proof-of- possession, then when it is discovered that the CA did not actually do the proof-of-possession (i.e., certificates are found for Alice and Bob which contain the same public key), legal action can be taken against the malpractice. The CA can be sued for damages, or driven out of business, or whatever. " How can we discover that the CA did not actually do the proof-of- possession (by whatever means) ? So the BIG question is : Should that discovery be done : 1 - at the time the checking using the certificate is performed, or 2 - long after ? My personal answer is : At the time the checking using the certificate is performed. Otherwise wrong decisions (false authentication or steal of signatures) would be discovered too late and damages would have already occurred. Can we agree on this ? If by some means an application protocol allows to make sure of an effective knowledge of the private key due to some real time computation, then possession of the private key is done by the subject [and thus does not need to be provided by the CA]. Note that proof-of-possession can also be proven *by the subject* to other parties, not necessarily by the CA, using one of the two techniques I already mentioned: a) counter-signature of the certificate by the user or b) inclusion of the certification path (or only the certificate) in some data signed using the subject private key. Note that the support of one of these two techniques is not necessarily required for any protocol. However including it would never hurt and it would be most advisable to always include it, when the size of the message is not a major concern. On the contrary a more detailed analysis of the protocol would be necessary. My conclusion would be that "all PKIX-using software" should NOT assume that each CA has indeed performed the check correctly (which is a point on which Carlisle and myself may still share a different view). :-( Denis -- Denis Pinkas Bull S.A. E-mail : D.Pinkas@frcl.bull.fr Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 From chandras@loc201.tandem.com Mon Feb 24 06:35:27 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id GAA08193; Mon, 24 Feb 1997 06:35:27 -0800 Received: from woozle.isode.com by suntan.tandem.com (8.6.12/suntan5.970212) for id GAA08186; Mon, 24 Feb 1997 06:35:22 -0800 Received: from isode.com (actually dougal.isode.com) by woozle.isode.com with SMTP (local); Mon, 24 Feb 1997 14:34:02 +0000 X-Mailer: exmh version 1.6.7 5/3/96 To: "Frank O'Dwyer" cc: ietf-pkix@tandem.com Subject: Re: Private key possession In-reply-to: Your message of "Sat, 22 Feb 1997 11:27:46 GMT." <199702221127.LAA12866@brd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Feb 1997 14:34:01 +0000 Message-ID: <11091.856794841@isode.com> From: David Boyce "Frank O'Dwyer" writes: >Yes, that's it. I have two fairly concrete scenarios in mind: > >(a) the user has a certificate from Verisign or a similar >neutral CA outside the company. I want to allow the user >limited access based on that public key, but I don't want to >allow everyone with a Verisign cert in, and I don't want to >have to maintain ACLs. I also want this to be valid for >just three weeks, whereas the user's current cert is good >for a year. I'm assuming requests for intranet certs >cannot traverse the company firewall (although I take your >point below). > >(b) the user has a certificate for use in some other >company's intranet. Otherwise, as above. Carlisle has a sound argument that proof-of-possession is inherent in certification, but it is possible to consider a scheme by which a CA need not perform this proof itself, providing adequate proof is available. It has some flaws which I've identified below, and there are probably others I've missed; but I hope it may provide a way forward in this discussion. The key-possession issue may perhaps be managed by mandating that a CA is always responsible for providing a route to verifying of possession, but is not necessarily the source of proof itself. This may be handled by 'yet another' extension named privateKeyPossessionPath which holds information (e.g. a certificate path) identifying the entity responsible for verifying possession of the private key corresponding to the public key in the certificate. This entity might be another CA or an RA. I think this extension *should* be critical, but this may be impractical for existing applications. In ordinary cases, the CA would itself be the verifier of possession, and this would be mandated to be the case when the certificate contains no such extension. Hence 'ordinary' certificates have the mandatory characteristics desired. When a CA routinely works in association with an RA, I would expect this to be stated in the policy of the issuing CA, and hence this extension would not be required for this case. The privateKeyPossessionPath extension allows a CA to issue a certificate without itself proving possession of the private key (by generating a certificate with the extension) provided that it trusts the original proof of possession assertion (a statement to the effect that this is the case should be stated in its policy). Should an application accept such a certificate? It boils down to how far the user trusts two entities: the issuing CA, and the named possession-verifying authority (PVA). If the named PVA is recognised by the application (and it is able to verify the certificate path), there remains the question of whether the application trusts the issuing CA's right to bind information to a public key whose private component has been verified by another authority. This Does this scheme address Frank's requirements? Let's see: a) [Public certificate case] Frank's CA can issue a certificate with the extension containing the Verisign certificate and any additional path his applications require to recognise it. One issue may be how they gain access to CRL information for these certificates through the firewall. b) [Intranet certificate case] Frank's CA has a problem, since the chances are that no application will be able to verify the certificate path, even if a cross-certificate is generated (no access to CRLs). If this can be surmounted, then perhaps there's a chance. [Perhaps a present but EMPTY privateKeyPossessionPath extension could be understood to mean 'Frank's CA hasn't verified the possession of the private key, but if you trust Frank's CA, then trust the binding anyway'. In this case, the extension definitely should be critical.] David. -- David Boyce Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND I'net: d.boyce@isode.com Isode's WWW: http://www.isode.com/ X.400: I=d;S=boyce;P=isode;A=mailnet;C=fi; From chandras@loc201.tandem.com Mon Feb 24 07:05:34 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id HAA11374; Mon, 24 Feb 1997 07:05:34 -0800 Received: from netcomsv.netcom.com by suntan.tandem.com (8.6.12/suntan5.970212) for id HAA11366; Mon, 24 Feb 1997 07:05:32 -0800 Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id GAA20828; Mon, 24 Feb 1997 06:51:29 -0800 Received: from cc:Mail by spysouth.spyrus.com id AA856795226 Mon, 24 Feb 97 06:40:26 Date: Mon, 24 Feb 97 06:40:26 From: "Housley, Russ" Encoding: 1418 Text Message-Id: <9701248567.AA856795226@spysouth.spyrus.com> To: ietf-pkix@tandem.com Subject: Re: Private key possession All: I just reread this thread, and I think we have lost sight of the original issue. In his original message, Denis Pinkas said: At the last PKIX meeting we had some discussion to say that each CA SHALL verify the possession of the private key by the user before issuing a certificate containing the corresponding public key. I would like to show that, while this is desirable, it does not solve all problems, in particular the problem of steeling a signature from some one else. [Stuff deleted] The conclusion is that each CA SHOULD verify the possession of the private [key] by the user before issuing a certificate containing the corresponding public key. As a consequence, this means that having a protocol to verify the possession of a private signature key shall not be mandatory and if we defined one, it should only be optionally supported. So, his point is that CAs should verify possion of the private key. He does not advocate the removal of fields that permit validation, rather he suggests that they should be optional. I think that this verification is easy to do, and that it should remain mandatory. If a CA does not actually perform the processing necessary to verify this, then it will be discovered before too long and that CA will loose customers. Russ From chandras@loc201.tandem.com Mon Feb 24 07:50:53 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id HAA15824; Mon, 24 Feb 1997 07:50:53 -0800 Received: from zafu.bbn.com by suntan.tandem.com (8.6.12/suntan5.970212) for id HAA15821; Mon, 24 Feb 1997 07:50:52 -0800 Received: from [128.33.229.235] ([128.33.229.235]) by zafu.bbn.com (8.7.5/8.6.5) with ESMTP id KAA29324; Mon, 24 Feb 1997 10:50:43 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199702220003.AAA12368@brd.ie> References: Your message of "Fri, 21 Feb 1997 10:33:29 -0400." <85256445.004DF4CC.00@cscmail.csc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Feb 1997 10:25:01 -0500 To: "Frank O'Dwyer" From: Stephen Kent Subject: Re: Private key possession Cc: ietf-pkix@tandem.com Frank, I'd like to think that having an RA, as an agent of a CA, verify private key possesion is acceptable as an alternative to direct CA validation. However, I'd also like to think that the proof afforded to the RA could be made available to the CA to help resolve any later dispute over whether the user in question did make a certificate request (vs. unsolicited certificate issuance). is this inconsistent with your model? Steve From chandras@loc201.tandem.com Mon Feb 24 07:46:44 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id HAA15443; Mon, 24 Feb 1997 07:46:44 -0800 Received: from clbull.frcl.bull.fr by suntan.tandem.com (8.6.12/suntan5.970212) for id HAA15413; Mon, 24 Feb 1997 07:46:31 -0800 Received: from dore (dore.frcl.bull.fr [129.182.42.156]) by clbull.frcl.bull.fr (8.7.5/8.7.3) with SMTP id QAA14932; Mon, 24 Feb 1997 16:37:41 +0100 Received: from dese22 by dore (AIX 4.1/UCB 5.64/4.03) id AA34582; Mon, 24 Feb 1997 16:44:29 +0100 Message-Id: <3312365A.2EB8@frcl.bull.fr> Date: Mon, 24 Feb 1997 16:46:18 -0800 From: Denis Pinkas Reply-To: D.Pinkas@frcl.bull.fr Organization: Bull X-Mailer: Mozilla 3.0 (Win16; I) Mime-Version: 1.0 To: David Boyce Cc: "Frank O'Dwyer" , ietf-pkix@tandem.com Subject: Re: Private key possession References: <11091.856794841@isode.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit David Boyce wrote: (...) 'yet another' extension named privateKeyPossessionPath (...) We already have many extensions. There are simpler solutions, life is already enough complicated. :-) Denis. -- Denis Pinkas Bull S.A. E-mail : D.Pinkas@frcl.bull.fr Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 From chandras@loc201.tandem.com Mon Feb 24 08:00:22 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id IAA16763; Mon, 24 Feb 1997 08:00:22 -0800 Received: from zafu.bbn.com by suntan.tandem.com (8.6.12/suntan5.970212) for id IAA16700; Mon, 24 Feb 1997 08:00:01 -0800 Received: from [128.33.229.235] ([128.33.229.235]) by zafu.bbn.com (8.7.5/8.6.5) with ESMTP id KAA00630; Mon, 24 Feb 1997 10:59:27 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199702221127.LAA12866@brd.ie> References: Your message of "Fri, 21 Feb 1997 16:04:52 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Feb 1997 10:59:39 -0500 To: "Frank O'Dwyer" From: Stephen Kent Subject: Re: Private key possession Cc: ietf-pkix@tandem.com Frank, Let's examine the scenarios you provided in more detail: >(a) the user has a certificate from Verisign or a similar >neutral CA outside the company. I want to allow the user >limited access based on that public key, but I don't want to >allow everyone with a Verisign cert in, and I don't want to >have to maintain ACLs. I also want this to be valid for >just three weeks, whereas the user's current cert is good >for a year. I'm assuming requests for intranet certs >cannot traverse the company firewall (although I take your >point below). > >(b) the user has a certificate for use in some other >company's intranet. Otherwise, as above. Whether the cert comes from Verisign or some other, external organization doesn't seem to be central to the argument. The intranet CA still needs to be contacted by the user to request the cert (if this is an offline, e.g., phone request, this point may not be relevant) and the CA needs to acquire the cert and relevant CRLs, and all of this entails communications across the firewall protecting the CA and its domain. A key question here seems to be whether the protocols needed to acquire the certificate for the user (who may have requested access for this domain in some online fashion) are more "dangerous" than fielding a cert request through the firewall. Our experience at BBN in providing the latter functionality would suggest otherwise. >What you're describing sounds like a firewalled internet CA, where >requests from the internet are normal and expected. However, if >you have an _intranet_ CA, then a "nothing from outside" rule >would seem quite natural. You can certainly imagine some people >wanting that, even if it's only a perception issue. It's new >software, after all. But there really must be some communication between the CA and the outside world, for the reasons cited above. >> Also reusing the same key in multiple >> certificates is often frowned upon, since it is not clear under what policy >> the keys are being used, i.e., ambiguity results when any of several >> certificates can be matched to the same private key. > >Well, I think multiple certs for the same key will be a fact of >life, if only because we won't all trust the same >CAs, but we will still need to interwork. We will also disagree >about which attributes belong with a key (and even about which >attributes are defined!). I don't understand your argument here. I expect to have different keys for different cert sfrom different CAs. Not trusting the same CAs is not the issue here; in fact, a lack of inter-CA trust is a very good motivation for wanting a different key in each certificate, as I mentioned earlier. >Cross-certificates will help here but I don't think >they solve every issue. Or, another approach is to have >multiple private keys, which will probably happen too, >but may not always work either (e.g. suppose you want to sign >a doc and have it believed in multiple domains, but they >do not have a common point of trust. As far as I can see >you then need to sign more than once with different keys, >or you need multiple certs for the same key.) This example better motivates your point about the desire for the same public key to be embedded in multiple certs, i.e., the need to sign a document and have it recognized across multiple certification domains. However, the examples provided earlier are for authorization certs, not for certs use for document signature (maybe non-repudiation?) purposes. Also, because of the complex problems of non-repudiation systems, it is extremely dangerous to have the same key in multiple certs issued by different CAs. I do believe that cross certs are the best way to address the need you cited here, i.e., a signature recognizable across many different certification domains. >> The second set of examples you provided also concern me. As a >> user, I don't want to be issused a certificate that I didn't ask for, but >> with my public key in it, in much the same way that I don't like receiving >> unsolicited credit cards on the mail. Requiring proof of possesion as part >> of certificate issuance helps prevent such unsolicited issuance, since a CA >> would not be able to prove that I requested the cert in question. (Of >> course this does not solve the bigger problem of having a cert issed with >> some other public key in it and having it bound to my name, but relaxing >> the proof-of-possesion requirement also does not address that problem.) > >Sure, but the flip side is that, as a CA, I don't want to be >constrained to issuing certificates that you request >or even certificates that you like. Someone may want to issue >a certificate saying "The holder of this public key teases cats", >or "the holder of this public key is ugly, incompetent, and known >to the police". As soon as the attributes get interesting then >there will undoubtedly arise such controversial and even >libellous certificates. Whether this type of thing is desirable >or not is a political/moral question that people won't agree on. >But it doesn't seem appropriate to take a position on it at the >protocol level. Sorry, but I cannot agree with the argument that unsolicited cert issuance is a feature! It has all the appeal of junk mail and telemarketing calls. I don't really believe that opinion is divided here, as you suggest, but maye a straw poll is in order to test this belief. How many people believe that issuing a cert to a user who has not requested one is an important feature. (Note, the question is not whether the user gets a cert with exactly the attributes he requested, as John Lowry pointed out earlier. The question is whether you want certs to be issued with your public key (and maybe your name) without your knowledge. Of course a CA could do this, unilaterally, but the question is how many forlks this this is a desirable feature and thus the PKIX standards should be structured to allow (encourage?) such cert issuance? >> It seems that there might be a common thread in these examples, >> i.e., the question of whether a third party ought to be able to cause a >> certificate to be issued containing a key already associated with a user, >> but without the consent or active participation of the user. Is this a >> feature, or a bug? Making proof-of-possesion an optional aspect of cert >> requests side steps the question, but is that good? > >To be able to require the active participation of the user would >imo be a feature. To be unable to do anything else would imo be >a bug. I think maybe if the RA requires the proof, but the CA doesn't >necessarily require it, then you get both options? I don't think that the examples provided so far support the conclusion that requiring proof-of-possesion is a bug, but I remain open to more evidence. At least the discussion is causing us to better explore the underlying assumptions and issues surrounding the complex topic. Steve From chandras@loc201.tandem.com Mon Feb 24 08:11:03 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id IAA17982; Mon, 24 Feb 1997 08:11:03 -0800 Received: from guardian.guard.ncsc.mil by suntan.tandem.com (8.6.12/suntan5.970212) for id IAA17972; Mon, 24 Feb 1997 08:10:52 -0800 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id LAA15338 for ; Mon, 24 Feb 1997 11:10:07 -0500 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma015332; Mon Feb 24 11:10:01 1997 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id LAA01876 for ; Mon, 24 Feb 1997 11:07:09 -0500 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id LAA19123; Mon, 24 Feb 1997 11:09:39 -0500 Date: Mon, 24 Feb 1997 11:09:39 -0500 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199702241609.LAA19123@argon.ncsc.mil> To: ietf-pkix@tandem.com Subject: Re: Private key possession X-Sun-Charset: US-ASCII > From: "Frank O'Dwyer" > > There is another reason why demonstrating possession of a private > key might not be a good thing to make mandatory, and I think it > is more plausible than the patent example. For example, I might > want to make a local intranet certificate which binds certain > X.509 extensions to your key. This certificate permits you (say) > to upload signed files via my firewall. That doesn't seem an > unreasonable requirement, but I can't do it if I need to demonstrate > ability to use your private key. Certainly you (or your agent) could > request the same cert, but an intranet CA is likely to reject > out of hand certification requests that originate from outside. > > There are clearly other examples, too, where you might not want > to consent to an attribute (e.g. it says you are not a > good risk for a loan). Or, it might be confidential (you can't > decrypt it and therefore _can't_ consent to it). Still, I might wish > to request it, the CA might be willing to grant it, and someone else > might wish to trust it. But it's all impossible if I have to know > your private key. > > Seems like a broad class of applications to be ruling out. They aren't being ruled out at all. Your examples are all of the form "authority A asserts that attribute B applies to subject C". The assertions could be in the form of an "attribute certificate" (whatever that is) or could be any other signed document, such as a signed email message saying "the subject holding public key xxyyzz is a bad credit risk". Clearly, anyone can write and sign such an email message, just as anyone could make the same assertion by issuing an attribute certificate. But an assertion of the form "authority A asserts that public key B belongs to the subject using the name C", i.e. an identity certificate, is a special case of a signed statement, and must be treated specially if it is to have any meaning beyond that of a generic signed object. The whole point of designing a public key infrastructure (standardizing the format of certification paths and management protocols) is to facilitate the automation of trust decisions regarding generic signed objects. I agree that in principle, cert management protocols could be made entirely policy-neutral, and a CA's proof of possession policy could be documented in the CPS, perhaps even in machine-parseable format. Or it could in principle be documented in something like David Boyce's "privateKeyPossessionPath" certificate extension. But just because ridiculously complicated policy expressions are possible does not mean that they should be used. Proof of possession is a fundamental requirement, not an optional feature, of any meaningful Public Key Infrastructure. Offering 10 different options (none mandatory) for accomplishing it, in the name of policy-neutrality, is counterproductive. -------- Denis raised two related but separate questions: 1) should proof of possession be mandatory for the CA, since the existing certificate format offers no proof that is demonstrable to a third party?, and 2) should the specific PKIX proof-of-possession PROTOCOL be a mandatory mechanism for accomplishing it? To address only question 2, yes the protocol should be mandatory to implement. This seems to be a recurring theme in nearly all IETF working groups, and the answer is always the same: * REQUIRED features are so designated to provide a least-common-denominator for interoperability. * REQUIRED features do not have to actually be used by everyone, they just have to be supported in every implementation that claims to comply with the standard. Given that the PKIX mechanism is not a significant burden to implement, and given that those who have better ideas on how to demonstrate possession of a private key and those who feel proof of possession is unnecessary are free to turn off the PKIX mechanism for their installations, the PKIX mechanism should remain a REQUIRED capability of PKIX-compliant software. From chandras@loc201.tandem.com Mon Feb 24 08:16:03 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id IAA18635; Mon, 24 Feb 1997 08:16:03 -0800 Received: from zionsbank.com by suntan.tandem.com (8.6.12/suntan5.970212) for id IAA18621; Mon, 24 Feb 1997 08:15:58 -0800 Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Mon, 24 Feb 1997 09:12:41 -0700 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 24 Feb 1997 09:12:28 -0700 From: Mike Smith To: D.Pinkas@frcl.bull.fr, ietf-pkix@tandem.com Subject: Re: Private key possession -Reply Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Question: Would it be assumed that a cross-certification of a well known CA public key require a "signed" request? I think that that would be optional on the cross-certifying CA's part. Michael >>> Denis Pinkas 02/24/97 01:27pm >>> Steve, Gene, Carlisle, Peter, Frank ... and all others This is single reply to all of you, that I will attempt to make short, I would like first to re-focus on the original matter. A. The original question was : Should a protocol, proving possession of the private key to the *CA*, be mandatorilly supported to claim conformance to PKIX ? My answer to this question is NO. There are various simple arguments for this, among them: 1) As Franck said , that proof may be given by the user to a RA and the CA will trust the (signed request of the) RA to have done the verification. 2) The CA (or the RA) may be the entity generating the private key and thus the user is unable to support any such protocol.. In other words we cannot suppose that the subject will always generate the key. This demonstrates that the proposed protocol is just one of the alternatives to do it, and not the *single* way to do it. Can we, first, all agree on this ? B. The remaining of this E-mail is important as well, but I would really like the opinion of the group on that question first. :-) I truly like many parts of the presentation from Carlisle in particular when he says that "the CA asserts a binding between the entity and the private key". I also agree to say that proof-of-possession-of-private-key is a mandatory aspect of the certification process (this does not mean that this must be done by that *protocol* only). I almost agree when he says " Clearly, (an honest) CA can only validly assert such a binding if, in fact, it is convinced that such a binding exists". The general statement is that any CA should use appropriate mechanisms AND procedures to make sure that for each of its certificates, the subject has current possession/usage of the corresponding private key. Can we agree on that statemment too ? Carlisle says (and I fully agree) : " If a CA claims conformance to PKIX, and PKIX mandates proof-of- possession, then when it is discovered that the CA did not actually do the proof-of-possession (i.e., certificates are found for Alice and Bob which contain the same public key), legal action can be taken against the malpractice. The CA can be sued for damages, or driven out of business, or whatever. " How can we discover that the CA did not actually do the proof-of- possession (by whatever means) ? So the BIG question is : Should that discovery be done : 1 - at the time the checking using the certificate is performed, or 2 - long after ? My personal answer is : At the time the checking using the certificate is performed. Otherwise wrong decisions (false authentication or steal of signatures) would be discovered too late and damages would have already occurred. Can we agree on this ? If by some means an application protocol allows to make sure of an effective knowledge of the private key due to some real time computation, then possession of the private key is done by the subject [and thus does not need to be provided by the CA]. Note that proof-of-possession can also be proven *by the subject* to other parties, not necessarily by the CA, using one of the two techniques I already mentioned: a) counter-signature of the certificate by the user or b) inclusion of the certification path (or only the certificate) in some data signed using the subject private key. Note that the support of one of these two techniques is not necessarily required for any protocol. However including it would never hurt and it would be most advisable to always include it, when the size of the message is not a major concern. On the contrary a more detailed analysis of the protocol would be necessary. My conclusion would be that "all PKIX-using software" should NOT assume that each CA has indeed performed the check correctly (which is a point on which Carlisle and myself may still share a different view). :-( Denis -- Denis Pinkas Bull S.A. E-mail : D.Pinkas@frcl.bull.fr Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 From chandras@loc201.tandem.com Mon Feb 24 08:40:37 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id IAA22326; Mon, 24 Feb 1997 08:40:37 -0800 Received: from dave.bbn.com by suntan.tandem.com (8.6.12/suntan5.970212) for id IAA22319; Mon, 24 Feb 1997 08:40:35 -0800 Received: (jlowry@localhost) by dave.bbn.com (8.6.9/150.200.504) id LAA19650; Mon, 24 Feb 1997 11:40:14 -0500 Date: Mon, 24 Feb 1997 11:40:14 -0500 From: John Lowry Message-Id: <199702241640.LAA19650@dave.bbn.com> To: fod@brd.ie, kent@bbn.com Subject: Re: Private key possession Cc: ietf-pkix@tandem.com X-Sun-Charset: US-ASCII More importantly, the proof must be transitive as the RA may not be a function provided by (as opposed to supported by) the CA. Consider the case where the CA is a service provider and the RA is operated by the CA's customer (or agent of the CA's customer !) I question whether the RA is an agent only of the CA. It seems to me that the RA is an agent of both the CA and the "customer". The RA _may_ be bound procedurally to verify possession but how can the CA always rely on that ? For some cases the CA will still need to verify proof of possession or verify that the RA performed that function. It is important that there be technical means to do that verification and that the CA can look to its local store to confirm performance of its agents. > From chandras%loc201.tandem.com@suntan.tandem.com Mon Feb 24 11:20:58 1997 > X-Sender: kent@po1.bbn.com > Mime-Version: 1.0 > Date: Mon, 24 Feb 1997 10:25:01 -0500 > To: "Frank O'Dwyer" > From: Stephen Kent > Subject: Re: Private key possession > Cc: ietf-pkix@tandem.com > > Frank, > > I'd like to think that having an RA, as an agent of a CA, verify > private key possesion is acceptable as an alternative to direct CA > validation. However, I'd also like to think that the proof afforded to the > RA could be made available to the CA to help resolve any later dispute over > whether the user in question did make a certificate request (vs. > unsolicited certificate issuance). is this inconsistent with your model? > > Steve > > From chandras@loc201.tandem.com Mon Feb 24 08:58:34 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id IAA25232; Mon, 24 Feb 1997 08:58:34 -0800 Received: from clbull.frcl.bull.fr by suntan.tandem.com (8.6.12/suntan5.970212) for id IAA25227; Mon, 24 Feb 1997 08:58:32 -0800 Received: from dore (dore.frcl.bull.fr [129.182.42.156]) by clbull.frcl.bull.fr (8.7.5/8.7.3) with SMTP id RAA15328; Mon, 24 Feb 1997 17:49:44 +0100 Received: from dese22 by dore (AIX 4.1/UCB 5.64/4.03) id AA34914; Mon, 24 Feb 1997 17:56:33 +0100 Message-Id: <3312473D.35EA@frcl.bull.fr> Date: Mon, 24 Feb 1997 17:58:21 -0800 From: Denis Pinkas Reply-To: D.Pinkas@frcl.bull.fr Organization: Bull X-Mailer: Mozilla 3.0 (Win16; I) Mime-Version: 1.0 To: "Housley, Russ" Cc: ietf-pkix@tandem.com Subject: Re: Private key possession References: <9701248567.AA856795226@spysouth.spyrus.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Housley, Russ wrote: > He does not advocate the removal of fields that permit validation, rather > he suggests that they should be optional. Correct. > I think that this verification is easy to do, and that it should remain > mandatory. I do not think that because "it is easy to do" is a valid argument. Please have a look at the mail I sent today. Denis -- Denis Pinkas Bull S.A. E-mail : D.Pinkas@frcl.bull.fr Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 From chandras@loc201.tandem.com Mon Feb 24 10:48:52 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id KAA11298; Mon, 24 Feb 1997 10:48:52 -0800 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id KAA11285; Mon, 24 Feb 1997 10:48:48 -0800 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id KAA14261; Mon, 24 Feb 1997 10:46:53 -0800 (PST) Received: from peter.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id KAA01414; Mon, 24 Feb 1997 10:47:36 -0800 (PST) Message-Id: <3.0.32.19970224104910.00ae9f30@mail> X-Sender: peter@mail X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 24 Feb 1997 10:49:11 -0800 To: dpkemp@missi.ncsc.mil (David P. Kemp), ietf-pkix@tandem.com From: Peter Williams Subject: Re: Private key possession Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >Given that the PKIX mechanism is not a significant burden to implement, >and given that those who have better ideas on how to demonstrate >possession of a private key and those who feel proof of possession is >unnecessary are free to turn off the PKIX mechanism for their >installations, the PKIX mechanism should remain a REQUIRED capability >of PKIX-compliant software. Im going to hold off responding much to this thread for a while, so others can get a shot in. But, for later general use, I am now going to introduce two sets of facts which make the above seemingly reasonable statement invalid in real life of a diverse world based on commercial objectives, not military command=and=control principles. (a) it is a burden to implement, as the consequences of having done so are burdensome on the CA/RA party which implicitely makes a representation of having received a request, by a cliam of conformance to generic PKIX, and by admission of the designers, may be required to demonstrate proof of such act by the legitmiate subscriber to satisfy a claim of unethical/unlicensed-issuance under the prevailing ethical or legal standard. Costs just went up 1000% due to the terms "legal" and "ethical". All *PKIX* cert-server, and "RA"-server software just got 100* more complicated, requiring basis for higher trust. While it is possible in OECD signatory countries that govt immunity could be imposed to limit the liabilities on CAs and RAs, through accredititation and licensing type means, this is hardly an IETF issue, or something suitable to serve as basis for open-forum technical protocol design for systems to be deployed without regard to such environmental expectations. (b) The use of certiifcates to impose any control policy is a policy-specific matter - be that policy mandatory escrow, mandatory crypto-registration, mandatory licensing of providers, or be it mandatory imposure of some other regulation system such as taxation, or sign-up to VISA operating regulations on account usage... It is not the purpose of the technical PKI infrastructure to (a) impose any such policy (b) provide a sufficient technical basis for uniformly imposing any such rule. A cooperationg domain of CA/RA/users within the internet PKI interworking space, each acepting use of a policy oid value "foo" can sign-up to, and give/accept notice of, aspects of operating policy which give rise to that domain's "meaningful PKI". As per 1422, there will likely be a small number of meaningful certification domains, which would not naturally share subscribers and users. You will not have permission to use your VISA SET merchant cert/keys to establish secure SSL-based shopping service, for example. Enablement of the separation of policy and technology is the purpose of the X.509 policy extn, and external control-enabling-policy mechanism, and what it should be used for. PKIX should mandate use of the standard verification algorithm expressed now in X.509, to instrument such a diverse world based on the std policy signal. This call-to-recollect fact is even a suggestion conformant with US Federal Govt. designs for its uniform world-wide KMI to be imposed upon all internet persons. The policy conformance requirements can be stated critically, nor non-critically, (X.509 has the optional criticality mechanism, remember) as means to insist upon enforcement of the control *policy* of the domain, by conforming end-systems. Operators of domains, and CAs/RAs, can offer some or all the available control policies, as normal business and market conditions require (SET | SSL | KMI | ...} . They can innovate, add-value, and/or ignore control objectives, as the customers/users demand. Not everyone needs to buy and sell using the SET payment service! From chandras@loc201.tandem.com Mon Feb 24 13:09:58 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id NAA03460; Mon, 24 Feb 1997 13:09:58 -0800 Received: from netcomsv.netcom.com by suntan.tandem.com (8.6.12/suntan5.970212) for id NAA03457; Mon, 24 Feb 1997 13:09:57 -0800 Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id MAA02119; Mon, 24 Feb 1997 12:49:36 -0800 Received: from cc:Mail by spysouth.spyrus.com id AA856816614 Mon, 24 Feb 97 12:36:54 Date: Mon, 24 Feb 97 12:36:54 From: "Housley, Russ" Encoding: 533 Text Message-Id: <9701248568.AA856816614@spysouth.spyrus.com> To: Peter Williams CC: ietf-pkix@tandem.com Subject: Re: Private key possession Peter: You said: If there are indeed elements of default policy built into the protocol design, based on the designer's expections and beliefs, then perhaps they should be identified as options (or at least identified for review purposes), and, as I say, possibly abstracted out as generic policy rules in the policy document. If the protocol does not include fields that can be used to verify private key possession, then we would not support a large class of resonable policies. Russ From chandras@loc201.tandem.com Mon Feb 24 14:03:04 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id OAA10926; Mon, 24 Feb 1997 14:03:04 -0800 Received: from csmes.ncsl.nist.gov by suntan.tandem.com (8.6.12/suntan5.970212) for id OAA10916; Mon, 24 Feb 1997 14:03:02 -0800 Received: from thunderbolt (thunderbolt.ncsl.nist.gov [129.6.54.130]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id QAA07340 for ; Mon, 24 Feb 1997 16:57:12 -0500 Message-Id: <199702242157.QAA07340@csmes.ncsl.nist.gov> X-Sender: burr@csmes.ncsl.nist.gov X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Feb 1997 17:59:11 -0500 To: ietf-pkix@tandem.com From: william.burr@nist.gov (Bill Burr) Subject: Re: Private Key Possession I'm quite confused about this thread, which I've been trying to follow with ever diminishing success as it continues. I don't understand what aspect of the PKIX the debate is about. Specifically: - Are we talking about PKIX-1 or PKIX-3 here? - Does a certificate have to be issued via PKIX-3 to be a valid PKIX certificate? Is it a condition of "PKIX conformance" that a certificate that conforms to the syntax and semantics of PKIX-1, must also have been issued via the PKIX-3 protocol to be a "conforming PKIX certificate?" - If, as I hope, you don't necessarily have to use the PKIX-3 protocol to issue conforming PKIX certificates, then is the argument about a semantic requirement in PKIX-1 that the issuing CA shall ensure that the certificate subject prove that he knows the private key corresponding to the certified subject public key, whatever the protocol used to issue the certificate? - Or is the question simply limited to whether the PKIX-3 protocol should or should not allow for less rigorous issuance options where the prospective certificate holder does not have to demonstrate possession of the private key? Surely nobody is arguing that the protocol need not even provide a way to prove that the certificate holder actually has the private key, are they? It seems to me that there is a respectable (but by no means overwhelming) case to be made that the PKIX should choose to be only for "high assurance" certificates and single out this one important principle as a vital for any claim of "PKIX conformance." It also seem to me that there's an even better case to be made for confining the PKIX-3 protocol to reasonably high assurance cases where the possession of the private key is verified. That's certainly the case of the most interest to me. Then it might be sufficient for a certificate practice statement to say that certificates are issued via PKIX-3, and not be necessary to further state what was done to ensure the integrity of the binding, But it would seem to me to be a very bad idea to link PKIX-1 conformance to certificate issuance via PKIX-3. After all, the certificate is issued once, and the issuance protocol could very well be by some non-standard protocol, but the certificate could still be perfectly interoperable with PKIX certificates issued in completely different ways. There is a much stronger reason for needing PKIX-1 level interoperability than PKIX-3 level interoperablity. Regards, Bill Burr 301-975-2914 http://www.nist.gov/itl/div877/staff/burr/ From chandras@loc201.tandem.com Mon Feb 24 15:30:32 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id PAA24582; Mon, 24 Feb 1997 15:30:32 -0800 Received: from relay.ieunet.ie by suntan.tandem.com (8.6.12/suntan5.970212) for id PAA24562; Mon, 24 Feb 1997 15:30:28 -0800 Received: from db-36.dialup.eunet.ie by relay.ieunet.ie with SMTP id aa13930; 24 Feb 97 23:09 +0000 Received: from brd.ie (fod@localhost [127.0.0.1]) by brd.ie (8.7.5/8.7.3) with ESMTP id UAA17014; Mon, 24 Feb 1997 20:54:59 GMT Message-Id: <199702242054.UAA17014@brd.ie> To: Stephen Kent , ietf-pkix@tandem.com Subject: Re: Private key possession In-reply-to: Your message of "Mon, 24 Feb 1997 10:25:01 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Feb 1997 20:54:58 +0000 From: "Frank O'Dwyer" > Frank, > > I'd like to think that having an RA, as an agent of a CA, verify > private key possesion is acceptable as an alternative to direct CA > validation. However, I'd also like to think that the proof afforded to the > RA could be made available to the CA to help resolve any later dispute over > whether the user in question did make a certificate request (vs. > unsolicited certificate issuance). is this inconsistent with your model? No, that sounds fine, so long as it's a policy matter for the CA whether or not to require this of the RA. I do think it makes good sense for the RA to always require it of the user. I see it more as a safety catch mechanism rather than something that you could use later on to resolve disputes, though. Cheers, Frank O'Dwyer. From chandras@loc201.tandem.com Mon Feb 24 15:30:33 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id PAA24595; Mon, 24 Feb 1997 15:30:33 -0800 Received: from relay.ieunet.ie by suntan.tandem.com (8.6.12/suntan5.970212) for id PAA24577; Mon, 24 Feb 1997 15:30:31 -0800 Received: from db-36.dialup.eunet.ie by relay.ieunet.ie with SMTP id aa13931; 24 Feb 97 23:09 +0000 Received: from brd.ie (fod@localhost [127.0.0.1]) by brd.ie (8.7.5/8.7.3) with ESMTP id WAA17061; Mon, 24 Feb 1997 22:23:40 GMT Message-Id: <199702242223.WAA17061@brd.ie> To: Stephen Kent cc: ietf-pkix@tandem.com Subject: Re: Private key possession In-reply-to: Your message of "Mon, 24 Feb 1997 10:59:39 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Feb 1997 22:23:40 +0000 From: "Frank O'Dwyer" [...] > The intranet CA still needs to > be contacted by the user to request the cert (if this is an offline, e.g., > phone request, this point may not be relevant) and the CA needs to acquire > the cert and relevant CRLs, and all of this entails communications across > the firewall protecting the CA and its domain. A key question here seems > to be whether the protocols needed to acquire the certificate for the user > (who may have requested access for this domain in some online fashion) are > more "dangerous" than fielding a cert request through the firewall. Our > experience at BBN in providing the latter functionality would suggest > otherwise. A lot depends on who initiates the communications. I would rather import the odd certificate than to hang an RA out in the breeze for all-comers to throw gnarly ASN.1 requests at. You've got to presume that these things have bugs. Also, whereas I (presumably) _need_ the ability to get your certificate, I don't _need_ to provide an online RA service to the internet. Why accept a risk (or spend money) if you don't have to? [...] > I expect to have different keys for > different cert sfrom different CAs. Not trusting the same CAs is not the > issue here; in fact, a lack of inter-CA trust is a very good motivation for > wanting a different key in each certificate, as I mentioned earlier. Why? If I trust Verisign CA more than Newbie CA and don't trust Digicrime CA at all, then I won't request a cert for my key from Digicrime CA. (It may still issue one, of course). But if I got a cert from the other two, why would I care if the keys were the same or not? How could it possibly get any worse than the Digicrime CA using the key from my Verisign cert? And what could any CA do that my having another key would stop them doing? [As a matter of fact, I would be extremely keen on having my key certified by multiple CAs. I would also like if verifiers would require at least N independent certs before accepting my key (the PGP model). This protects me against CAs. I don't really expect this to happen, though - especially if you have to pay for certs.] [...] > Sorry, but I cannot agree with the argument that unsolicited cert issuance > is a feature! It has all the appeal of junk mail and telemarketing calls. It's really nothing like junk mail or telemarketing since it's purpose is to NOT involve uninterested or uncooperative parties. If someone creates and makes available a certificate concerning Joe, how is this like Joe getting spammed? The certificate might indicate 'holder posts thoughtful articles to sci.crypt', or it might say 'holder repeatedly posts 10,000 line articles to comp.os.ms-windows.advocacy arguing that the moon shot was faked in a hollywood studio'. Joe need never see either certificate - it just happens to certify something _about_ him, to anyone who cares to believe the issuer. But you want people to call Joe up and get him to use his key before they can certify to interested parties that he is a guru/idiot (delete as applicable). Now THAT would be like junk mail and telemarketing. Cheers, Frank O'Dwyer From chandras@loc201.tandem.com Mon Feb 24 17:55:43 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id RAA15325; Mon, 24 Feb 1997 17:55:43 -0800 Received: from cheetah.llnl.gov by suntan.tandem.com (8.6.12/suntan5.970212) for id RAA15318; Mon, 24 Feb 1997 17:55:41 -0800 Received: from [198.128.36.55] by cheetah.llnl.gov (8.8.5/LLNL-2.0) id RAA24611; Mon, 24 Feb 1997 17:54:27 -0800 (PST) Message-Id: <199702250154.RAA24611@cheetah.llnl.gov> X-Sender: azb@198.128.36.8 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Feb 1997 17:59:51 -0800 To: "Frank O'Dwyer" From: azb@llnl.gov (Tony Bartoletti) Subject: Re: Private key possession Cc: ietf-pkix@tandem.com Frank O'Dwyer wrote: >It's really nothing like junk mail or telemarketing since it's purpose >is to NOT involve uninterested or uncooperative parties. If someone >creates and makes available a certificate concerning Joe, how is this >like Joe getting spammed? The certificate might indicate 'holder posts >thoughtful articles to sci.crypt', or it might say 'holder >repeatedly posts 10,000 line articles to comp.os.ms-windows.advocacy >arguing that the moon shot was faked in a hollywood studio'. Joe >need never see either certificate - it just happens to certify something >_about_ him, to anyone who cares to believe the issuer. But you want >people to call Joe up and get him to use his key before they can >certify to interested parties that he is a guru/idiot (delete as >applicable). Now THAT would be like junk mail and telemarketing. >Cheers, >Frank O'Dwyer I tend to agree with you, but... Please respond to David Kemp's comments. The line between "certificate" and "signed message" is eroding quickly. It seems that the public key is simply being used as a stand-in for the target's "name". I think I see a drifting here to accomodate SPKI, which intends to "simply" certify that "entity-that-can-sign-as XXX has YYY attribute, authority, etc." I can sign a message attributing anything to anyone, and I don't need their permission. I can be sued for libel, defamation, etc., of course. But what difference if my message refers to them by name, address, or public key? Does my reference to their public key make my signed message a "certificate"? Perhaps it does, in a vague sense at least. To me, the fundamental responsibility of any PKI is to provide a standard way of "validating a certificate chain (or mesh?)" to the satisfaction of the relying party. Where such satisfaction desires proof-of-ability-to-sign, this capability should be addressed in some fashion by ANY PKI. A form of challenge-response along these lines can be the foundation of a very strong set of bindings, and I believe this was in the minds of the SPKI group, who use it as a bootstrap via "self-signed certificates". (IMNSHO) ___TONY___ Tony Bartoletti LL SPI Project Leader LL LL Computer Security Technology Center LL LL LL Lawrence Livermore National Lab LL LL LL PO Box 808, L - 303 LL LL LLLLLLLL Livermore, CA 94551-9900 LL LLLLLLLL email: azb@llnl.gov phone: 510-422-3881 LLLLLLLL From chandras@loc201.tandem.com Tue Feb 25 11:29:38 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id LAA25760; Tue, 25 Feb 1997 11:29:38 -0800 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id LAA25753; Tue, 25 Feb 1997 11:29:37 -0800 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id LAA14051; Tue, 25 Feb 1997 11:27:40 -0800 (PST) Received: from peter.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id LAA22569; Tue, 25 Feb 1997 11:28:24 -0800 (PST) Message-Id: <3.0.32.19970225112957.00bf000c@mail> X-Sender: peter@mail X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 25 Feb 1997 11:29:58 -0800 To: william.burr@nist.gov (Bill Burr), ietf-pkix@tandem.com From: Peter Williams Subject: Re: Private Key Possession Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Bill, My take is we are determining the nature of the intended PKIX infrastructure, by the question being considered. The technical subject being argued (mandatory/required checking of an assurance entitled "proof of possession") could have been one of several control instruments being used. There are those who see PKIX as a toolkit of standard elements for building certification domains, of quality expressed by the X.509 policy field (ME! based on X.509 standard semantics) And there are those who are engineering into the technical protocols for management some miminal assurance requirements for all domains. Such minimal assurances are perhaps expressed in the APKI I-D, which I know I personally can see little commercial value. I just dont believe in the management culture it envisions - for commercial purposes. At the end of the day, I expect to go with the flow of the group; if APKI objectives are what the protocol helps instrument, then executing the agreed standard is what participating in an open standards process is all about! I putting my contribution in the pot, versus seeking to hold things up for any pariticular purpose. Authors shoudl take and ignore what they want, from my contributions. Now, I read the WG scope very specifically - it allows 1422 like management culture, including the culture of persona CAs. Others seem to disagree when it comes to the practice of conforming to the spec. I think this is the underlying tension, causing what is perhaps one of the final hurdles to just doing it, and amending the 2 documents later, if their procedures break, or receive too much adverse technically-motivated feedback upon deployment. The choice of language is perhaps all we are now considering - a normal event in standards processes reaching maturity. its a final statge of concensus building, to ensure the language exhibits the intended environment and space for all interested players to now "just do it". At 05:59 PM 2/24/97 -0500, Bill Burr wrote: >I'm quite confused about this thread, which I've been trying to follow with >ever diminishing success as it continues. I don't understand what aspect of >the PKIX the debate is about. Specifically: > >- Are we talking about PKIX-1 or PKIX-3 here? > >- Does a certificate have to be issued via PKIX-3 to be a valid PKIX >certificate? Is it a condition of "PKIX conformance" that a certificate >that conforms to the syntax and semantics of PKIX-1, must also have been >issued via the PKIX-3 protocol to be a "conforming PKIX certificate?" > >- If, as I hope, you don't necessarily have to use the PKIX-3 protocol to >issue conforming PKIX certificates, then is the argument about a semantic >requirement in PKIX-1 that the issuing CA shall ensure that the certificate >subject prove that he knows the private key corresponding to the certified >subject public key, whatever the protocol used to issue the certificate? > >- Or is the question simply limited to whether the PKIX-3 protocol should or >should not allow for less rigorous issuance options where the prospective >certificate holder does not have to demonstrate possession of the private >key? Surely nobody is arguing that the protocol need not even provide a way >to prove that the certificate holder actually has the private key, are they? > > >It seems to me that there is a respectable (but by no means overwhelming) >case to be made that the PKIX should choose to be only for "high assurance" >certificates and single out this one important principle as a vital for any >claim of "PKIX conformance." > >It also seem to me that there's an even better case to be made for confining >the PKIX-3 protocol to reasonably high assurance cases where the possession >of the private key is verified. That's certainly the case of the most >interest to me. Then it might be sufficient for a certificate practice >statement to say that certificates are issued via PKIX-3, and not be >necessary to further state what was done to ensure the integrity of the binding, > >But it would seem to me to be a very bad idea to link PKIX-1 conformance to >certificate issuance via PKIX-3. After all, the certificate is issued once, >and the issuance protocol could very well be by some non-standard protocol, >but the certificate could still be perfectly interoperable with PKIX >certificates issued in completely different ways. There is a much stronger >reason for needing PKIX-1 level interoperability than PKIX-3 level >interoperablity. > > >Regards, > >Bill Burr >301-975-2914 >http://www.nist.gov/itl/div877/staff/burr/ > > > From chandras@loc201.tandem.com Wed Feb 26 13:57:21 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id NAA15329; Wed, 26 Feb 1997 13:57:21 -0800 Received: from relay.ieunet.ie by suntan.tandem.com (8.6.12/suntan5.970212) for id NAA15299; Wed, 26 Feb 1997 13:57:13 -0800 Received: from db-01.dialup.eunet.ie by relay.ieunet.ie with SMTP id aa09344; 26 Feb 97 21:56 +0000 Received: from brd.ie (fod@localhost [127.0.0.1]) by brd.ie (8.7.5/8.7.3) with ESMTP id WAA25025; Wed, 26 Feb 1997 22:01:34 GMT Message-Id: <199702262201.WAA25025@brd.ie> To: "David P. Kemp" cc: ietf-pkix@tandem.com Subject: Re: Private key possession In-reply-to: Your message of "Mon, 24 Feb 1997 11:09:39 EST." <199702241609.LAA19123@argon.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain Date: Wed, 26 Feb 1997 22:01:34 +0000 From: "Frank O'Dwyer" > Your examples are all of the form "authority A asserts that > attribute B applies to subject C". The assertions could be in the > form of an "attribute certificate" (whatever that is) or could be > any other signed document, such as a signed email message saying > "the subject holding public key xxyyzz is a bad credit risk". > > Clearly, anyone can write and sign such an email message, just as > anyone could make the same assertion by issuing an attribute certificate. > > But an assertion of the form "authority A asserts that public key B > belongs to the subject using the name C", i.e. an identity certificate, > is a special case of a signed statement, and must be treated specially > if it is to have any meaning beyond that of a generic signed object. > The whole point of designing a public key infrastructure > (standardizing the format of certification paths and management > protocols) is to facilitate the automation of trust decisions regarding > generic signed objects. Sure, but names are not the only special case. "..the subject authorized to do..." and "...a subject considered to be..." are also special, and also interesting. I suppose you could even, at a stretch, consider these a type of name (the first is very like a role or group, and the second is like a label**). In my opinion any statements that are "about" a subject that uses keys, and which can be vouched for by a trusted third party - these are fair game for a certificate. Even more so if some application can automatically process them. After all, "bad credit risks" also create generic signed objects. Since PKIX-1 (or at least X.509 v3) is clearly open-ended for new attributes, and the PKIX-3 stuff can be used to request any attributes that are going, I don't really see why there should be a problem with attributes that are not names (at least, not in the conventional sense). Except of course, that you might want to say something "about" a key-holding subject without their co-operation - which is where I came in... Cheers, Frank O'Dwyer. ** There are also other interesting certificates which don't appear to contain anything that would ordinarily be considered a name. For example, I would be interested in a certificate whose main attribute was a GIF or EPS of a company logo. Is a logo a name? (I guess it is if you are The Artist Formerly Known As Prince, but otherwise...). Also interesting would be a cert with just a jpeg of somebody's face, or with the image or text from a hyperlink (as distinct from the URL). I wrote a paper a while back about 'Hyperlink Spoofing' which proposed these types of extensions to SSL (i.e. X.509 v3) certificates as a remedy for fake hyperlinks - it's at http://www.brd.ie/papers/sslpaper/sslpaper.htm if anyone is interested. From chandras@loc201.tandem.com Fri Feb 28 06:43:29 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id GAA02712; Fri, 28 Feb 1997 06:43:29 -0800 Received: from ns.newbridge.com by suntan.tandem.com (8.6.12/suntan5.970212) for id GAA02708; Fri, 28 Feb 1997 06:43:27 -0800 Received: (from smap@localhost) by ns.newbridge.com (8.6.12/8.6.12) id JAA25632 for ; Fri, 28 Feb 1997 09:43:26 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma025370; Fri Feb 28 09:42:30 1997 Received: (from smap@localhost) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) id JAA13531 for ; Fri, 28 Feb 1997 09:42:26 -0500 Received: from tsntsrv2.timestep.com(192.168.219.191) by kanmaster.ca.newbridge.com via smap (V1.3) id sma012911; Fri Feb 28 09:35:32 1997 Received: by tsntsrv2.timestep.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC255B.02033EB0@tsntsrv2.timestep.com>; Fri, 28 Feb 1997 09:37:26 -0500 Message-ID: From: Paul Kierstead To: "'ietf-pkix@tandem.com'" Subject: Unknown string type (28) and content of private enterprise extensions. Date: Fri, 28 Feb 1997 09:37:25 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit While browsing some X.509 certificates included with Internet Explorer, I came across some names encoded using a tag identifier of 28. I would appear to be ASCII with each character encoded as 4-bytes. Now obviously it was intended for more then just ASCII; I presume the other three bytes are used under some conditions. Does anybody know exactly what these string are? Peter Gutman, in his style guide, referred to a 4 byte scheme which he guessed to be Unicode .... however Unicode is 16-bit. Is it Unicode encoded as 32-bit? Is Universal String TAG 28? My (admittidly old) documents do not refer to UniversalString. Or BMPString, for that matter. More along these lines .... the Verisign certificates have private enterprise extensions ( { 1 3 6 1 4 1 311 2 1 27} and { 1 3 6 1 4 1 311 2 1 10} ). Anybody know the content format of these extensions? Any concrete knowledge would be greatly appreciated .... ------------------------------ Paul Kierstead TimeStep Corporation mailto:pmkierst@timestep.com http:\\www.timestep.com From chandras@loc201.tandem.com Fri Feb 28 09:16:15 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id JAA19225; Fri, 28 Feb 1997 09:16:15 -0800 Received: from guardian.guard.ncsc.mil by suntan.tandem.com (8.6.12/suntan5.970212) for id JAA19220; Fri, 28 Feb 1997 09:16:13 -0800 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id MAA03949; Fri, 28 Feb 1997 12:15:50 -0500 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma003947; Fri Feb 28 12:15:38 1997 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id MAA19610; Fri, 28 Feb 1997 12:12:45 -0500 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id MAA22934; Fri, 28 Feb 1997 12:15:15 -0500 Date: Fri, 28 Feb 1997 12:15:15 -0500 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199702281715.MAA22934@argon.ncsc.mil> To: ietf-pkix@tandem.com, pmkierst@timestep.com Subject: Re: Unknown string type (28) and content of private enterprise extensions. X-Sun-Charset: US-ASCII > From: Paul Kierstead > > Is Universal String TAG 28? My (admittidly old) documents do not refer > to UniversalString. Or BMPString, for that matter. > > More along these lines .... the Verisign certificates have private > enterprise extensions ( { 1 3 6 1 4 1 311 2 1 27} and { 1 3 6 1 4 1 > 311 2 1 10} ). Anybody know the content format of these extensions? > > Any concrete knowledge would be greatly appreciated .... Finding concrete knowledge is certainly much more difficult than it should be. Ideally there would be a repository of this information somewhere that anyone could consult, but if there is one, I don't know about it. So we just limp along, trading tidbits of information one piece at a time. Here are the universal-class definitions from the 1993 version of X.680: /* 0: reserved for end marker */ #define BOOLEAN 0x01 /* 1: TRUE or FALSE */ #define INTEGER 0x02 /* 2: Arbitrary precision integer */ #define BITSTRING 0x03 /* 2: Sequence of bits */ #define OCTETSTRING 0x04 /* 4: Sequence of bytes */ #define NULLTAG 0x05 /* 5: NULL */ #define OID 0x06 /* 6: Object Identifier (numeric sequence) */ #define OBJDESCRIPTOR 0x07 /* 7: Object Descriptor (Graphic String) */ #define EXTERNAL 0x08 /* 8: External / Instance Of */ #define REAL 0x09 /* 9: Real (Mantissa * Base^Exponent) */ #define ENUMERATED 0x0a /* 10: Enumerated */ #define EMBEDDED_PDV 0x0b /* 11: Embedded Presentation Data Value */ #define SEQUENCE 0x10 /* 16: Constructed Sequence / Sequence Of */ #define SET 0x11 /* 17: Constructed Set / Set Of */ #define NUMERICSTR 0x12 /* 18: Numeric String (digits 0-9 and space) */ #define PRINTABLESTR 0x13 /* 19: Printable String (74 chars) */ #define TELETEXSTR 0x14 /* 20: T.61 String (Teletex) */ #define VIDEOTEXSTR 0x15 /* 21: Videotex String */ #define IA5STR 0x16 /* 22: Int'l Alphabet 5 (ISO 646 - 128 chars) */ #define UTCTIME 0x17 /* 23: UTC Time */ #define GENERALIZEDTIME 0x18 /* 24: Generalized Time */ #define GRAPHICSTR 0x19 /* 25: Graphic String */ #define VISIBLESTR 0x1a /* 26: Visible String (ISO 646 - 95 chars) */ #define GENERALSTR 0x1b /* 27: General String */ #define UNIVERSALSTR 0x1c /* 28: Universal String (4 octets/char) */ #define CHARACTERSTR 0x1d /* 29: Unrestricted Character String */ #define BMPSTR 0x1e /* 30: Basic Multilingual Plane (2 octets) */ /* 31: High tag number follows in radix 128 */ And here is a little info about the root of the OID tree: /* * ITU(0) includes: Recommendation(0), Question(1), Administration(2), * Network-Operator(3), Identified-Organization(4) * * ISO(1) includes: Standard(0), Member-Body(2), Identified-Organization(3) * 1 2 includes: us(840), ca(124) * 1 3 includes: osinet(4), gosip(5), dod(6), oiw(14) * * JOINT-ISO-CCITT(2) includes: Directory Service(5), Country(16) * 2 16 includes: us(840), ca(124) * 2 16 840 includes: organization(1), mhs-md(2), state(3) * * From ISO/IEC 9594-2 (X.501) "The Directory: Models" * * Directory Service ds ::= {joint-iso-ccitt(2) ds(5)} * attributeType id-at ::= {ds 4} * algorithm ::= {ds 8} * certificateExtension id-ce ::= {ds 29} (from AM 4) * * From ISO/IEC 9594-6 (X.520) "The Directory: Selected Attribute Types" * id-at-commonName ::= {id-at 3} * id-at-countryName ::= {id-at 6} * id-at-localityName ::= {id-at 7} * id-at-stateOrProvinceName ::= {id-at 8} * id-at-organizationName ::= {id-at 10} * id-at-organizationalUnitName ::= {id-at 11} */ So you can see that {1 3 6 ...} is in the ISO dod arc, but I can't help you from there. MISSI uses the joint-iso-itu arc for dod: {joint (2) country (16) us (840) organization (1) gov (101) dod (2)}. ---------------------------------- My questions are: 1) draft-ietf-asid-inetorgperson-00.txt defines these OIDs: 2.16.840.1.113730.3.1.1 carLicense" 2.16.840.1.113730.3.1.2 departmentNumber" 2.16.840.1.113730.3.1.3 employeeNumber" 2.16.840.1.113730.3.1.4 employeeType" 2.16.840.1.113730.3.2.2 inetOrgPerson" A Verisign cert request included the following OIDs: 2.16.840.1.113730.1.1 2.16.840.1.113730.1.8 2.16.840.1.113730.1.13 RSADSI is 1.2.840.113549, but who is 2.16.840.1.113730, and where are the OIDs under it defined? 2) The 1 December 1996 Draft Amendment to X.509 lists certificate extensions id-ce 9, 14-21, 23-24, 27-36 and lists id-ce 34 as deprecated. It also includes the following comment: "The following OBJECT IDENTIFIERS are not used by this specification:" id-ce 2-8, 10-13, 22, 25, 26. That comment is not as helpful as it could be, since it says nothing about id-ce 1, and doesn't point to the specification that *does* use id-ce 2-8 ... The same Verisign cert request mentioned above included 2.5.29.3 (id-ce 3). That extension is pretty useless if it isn't documented somewhere, and it would be nice if X.509 DAM 1 pointed to the appropriate specification. From chandras@loc201.tandem.com Fri Feb 28 10:25:01 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id KAA29934; Fri, 28 Feb 1997 10:25:01 -0800 Received: from tahoma.mcom.com by suntan.tandem.com (8.6.12/suntan5.970212) for id KAA29827; Fri, 28 Feb 1997 10:24:24 -0800 Received: from tahoma (localhost [127.0.0.1]) by tahoma.mcom.com (940816.SGI.8.6.9/8.6.9) with ESMTP id KAA00683; Fri, 28 Feb 1997 10:20:47 -0800 Sender: gangolli@netscape.com Message-ID: <331721FF.1CFB@netscape.com> Date: Fri, 28 Feb 1997 10:20:47 -0800 From: "Anil R. Gangolli" Organization: Netscape Server Product Development X-Mailer: Mozilla 4.0b2 (X11; I; IRIX 5.3 IP22) MIME-Version: 1.0 To: "David P. Kemp" CC: ietf-pkix@tandem.com, pmkierst@timestep.com Subject: Re: Unknown string type (28) and content of private enterprise extensions. X-Priority: 3 (Normal) References: <199702281715.MAA22934@argon.ncsc.mil> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii David P. Kemp wrote: > My questions are: > > 1) draft-ietf-asid-inetorgperson-00.txt defines these OIDs: > > 2.16.840.1.113730.3.1.1 carLicense" > 2.16.840.1.113730.3.1.2 departmentNumber" > 2.16.840.1.113730.3.1.3 employeeNumber" > 2.16.840.1.113730.3.1.4 employeeType" > 2.16.840.1.113730.3.2.2 inetOrgPerson" > > A Verisign cert request included the following OIDs: > > 2.16.840.1.113730.1.1 > 2.16.840.1.113730.1.8 > 2.16.840.1.113730.1.13 > > RSADSI is 1.2.840.113549, but who is 2.16.840.1.113730, and where are > the OIDs under it defined? 2.16.840.1.113730 is Netscape Communications Corp. I will ask the keeper of the Netscape registry to make sure the definitions are available from our web site. --a. From chandras@loc201.tandem.com Fri Feb 28 13:37:18 1997 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id NAA25437; Fri, 28 Feb 1997 13:37:18 -0800 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id NAA25432; Fri, 28 Feb 1997 13:37:16 -0800 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id NAA02612; Fri, 28 Feb 1997 13:35:12 -0800 (PST) Received: from peter by mentat.verisign.com (8.8.5/BCH1.0) id NAA18502; Fri, 28 Feb 1997 13:35:59 -0800 (PST) Message-Id: <3.0.32.19970228133637.0090c2c0@mail> X-Sender: peter@mail X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 28 Feb 1997 13:36:38 -0800 To: dpkemp@missi.ncsc.mil (David P. Kemp), ietf-pkix@tandem.com, pmkierst@timestep.com From: Peter Williams Subject: Re: Unknown string type (28) and content of private enterprise extensions. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Folks, Its very hard to conform to something which is not ratified formally, even when one wants to, as I do, and have commented here before now about the lack of formality of the base material. As part of I-D requirements, of course we do not claim to conform to an I-D, such as PKIX; its unethical within the IETF spirit. I do promote PKIX all over the place, as "the" forum. I asked the ISO rapporteur for advice about conformance, when he worked at Nortel/BNR at the time, (a one Warwick Ford, who now runs our formal standards effort at VeriSign, and who also performs the PKIX co-chair role to our mutual benefits) and he advised: use the oids in the then current draft, (known as the final text) and move to the standard oids when they become stable/if-they-change and available in software. This is why we use the {id-ce 3} oid, and syntax, as defined by ISO (though I tried very hard last week to phase this out...in favour of the new definition, but failed for interworking reasons). It is non-critical in all public-purpose service offerings; those who do not know it, can safely ignore it. Those who rely upon it, may do so. So, for now, we are using oids for which there is end-user software available to handle the syntaxes and enforce the semantics. Having openly participated here in this profiling activity, Im waiting for PKIX-1 (18 months, Im waiting) before making a move to standardise the public elemnents of cert content for universal benefit in the internet spirit. I personally cant do as DOD/US Gov, and agitate for a concensus standard in public, whilst defining private material for its own use for similar general purposes. There is a formal repository available for OIDS; its called ISO, and ANSI (for US jurisdiction); these are recognised by US govt, formally, as legitimate international and national organizations. The repositories are based upon formal registration authority procedures, and perform with due process, as outlined in the X/650/660 standards) as regards to publication of repository material, and dispute resolution during primitive value assignment. Ive never before heard of an attack on the integrity of their processes. 2.16.840.1.113730 is the oid for Netscape,I believe, an organization authorised to thus act as an oid registry for its private purposes, as published by ANSI, and to millions of people on Netscape SSL-related technology disclosure pages. As a ssl-talk list recipient, David, you must have seen this pointer go by several times... As I remember, { 1 3 6 1 4 1 311 2 1 10} is the Microsoft registered oid used as part of the enforcement of the semantics of the software publishers trust domain underpining the Authenticode initiative to provide accountability and discretionary access control capability against malicious java or other applet technologies during the download sequence to corporate domains, and/or workstations. Full details are available on request to Microsoft, when one applies to join the programme; GTE and VeriSign were the founding CA parties, FYI. see http://www.microsoft.com/workshop/prog/security/ Peter. At 12:15 PM 2/28/97 -0500, David P. Kemp wrote: >> From: Paul Kierstead >> >> Is Universal String TAG 28? My (admittidly old) documents do not refer >> to UniversalString. Or BMPString, for that matter. >> >> More along these lines .... the Verisign certificates have private >> enterprise extensions ( { 1 3 6 1 4 1 311 2 1 27} and { 1 3 6 1 4 1 >> 311 2 1 10} ). Anybody know the content format of these extensions? >> >> Any concrete knowledge would be greatly appreciated .... > > >Finding concrete knowledge is certainly much more difficult than >it should be. Ideally there would be a repository of this information >somewhere that anyone could consult, but if there is one, I don't know >about it. So we just limp along, trading tidbits of information one >piece at a time. > >Here are the universal-class definitions from the 1993 version of X.680: > > /* 0: reserved for end marker */ >#define BOOLEAN 0x01 /* 1: TRUE or FALSE */ >#define INTEGER 0x02 /* 2: Arbitrary precision integer */ >#define BITSTRING 0x03 /* 2: Sequence of bits */ >#define OCTETSTRING 0x04 /* 4: Sequence of bytes */ >#define NULLTAG 0x05 /* 5: NULL */ >#define OID 0x06 /* 6: Object Identifier (numeric sequence) */ >#define OBJDESCRIPTOR 0x07 /* 7: Object Descriptor (Graphic String) */ >#define EXTERNAL 0x08 /* 8: External / Instance Of */ >#define REAL 0x09 /* 9: Real (Mantissa * Base^Exponent) */ >#define ENUMERATED 0x0a /* 10: Enumerated */ >#define EMBEDDED_PDV 0x0b /* 11: Embedded Presentation Data Value */ >#define SEQUENCE 0x10 /* 16: Constructed Sequence / Sequence Of */ >#define SET 0x11 /* 17: Constructed Set / Set Of */ >#define NUMERICSTR 0x12 /* 18: Numeric String (digits 0-9 and space) */ >#define PRINTABLESTR 0x13 /* 19: Printable String (74 chars) */ >#define TELETEXSTR 0x14 /* 20: T.61 String (Teletex) */ >#define VIDEOTEXSTR 0x15 /* 21: Videotex String */ >#define IA5STR 0x16 /* 22: Int'l Alphabet 5 (ISO 646 - 128 chars) */ >#define UTCTIME 0x17 /* 23: UTC Time */ >#define GENERALIZEDTIME 0x18 /* 24: Generalized Time */ >#define GRAPHICSTR 0x19 /* 25: Graphic String */ >#define VISIBLESTR 0x1a /* 26: Visible String (ISO 646 - 95 chars) */ >#define GENERALSTR 0x1b /* 27: General String */ >#define UNIVERSALSTR 0x1c /* 28: Universal String (4 octets/char) */ >#define CHARACTERSTR 0x1d /* 29: Unrestricted Character String */ >#define BMPSTR 0x1e /* 30: Basic Multilingual Plane (2 octets) */ > /* 31: High tag number follows in radix 128 */ > > >And here is a little info about the root of the OID tree: > >/* > * ITU(0) includes: Recommendation(0), Question(1), Administration(2), > * Network-Operator(3), Identified-Organization(4) > * > * ISO(1) includes: Standard(0), Member-Body(2), Identified-Organization(3) > * 1 2 includes: us(840), ca(124) > * 1 3 includes: osinet(4), gosip(5), dod(6), oiw(14) > * > * JOINT-ISO-CCITT(2) includes: Directory Service(5), Country(16) > * 2 16 includes: us(840), ca(124) > * 2 16 840 includes: organization(1), mhs-md(2), state(3) > * > * From ISO/IEC 9594-2 (X.501) "The Directory: Models" > * > * Directory Service ds ::= {joint-iso-ccitt(2) ds(5)} > * attributeType id-at ::= {ds 4} > * algorithm ::= {ds 8} > * certificateExtension id-ce ::= {ds 29} (from AM 4) > * > * From ISO/IEC 9594-6 (X.520) "The Directory: Selected Attribute Types" > * id-at-commonName ::= {id-at 3} > * id-at-countryName ::= {id-at 6} > * id-at-localityName ::= {id-at 7} > * id-at-stateOrProvinceName :