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