From owner-ietf-pkix@imc.org Tue Aug 1 12:17:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21014 for ; Tue, 1 Aug 2000 12:16:59 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA10451; Tue, 1 Aug 2000 09:11:52 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 1 Aug 2000 09:11:34 -0700 Received: from htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA10383 for ; Tue, 1 Aug 2000 09:11:33 -0700 (PDT) Received: from rgm.htt-consult.com ([147.73.134.30]) by htt-consult.com ; Tue, 01 Aug 2000 10:15:00 -0400 Message-Id: <4.3.2.7.2.20000801095804.03c955c0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 Aug 2000 10:13:57 -0400 To: ietf-pkix@imc.org From: Robert Moskowitz Subject: Company OIDs for free for PIs? In-Reply-To: <398159AB.C98D9F3A@bull.net> References: <000c01bff87f$dd26b620$0201a8c0@mega.vincent.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I have often thought about how little companies can get OIDs for free. After all, a few thousand bills for a small company can be a lot of money... What I have seen is every company can have an EDI identifier. X.435 (EDIFACT) has defined over 300 EDI identifier namespaces (DUNS being the most common, supposedly). I **THINK** this is the EDIFACT UNB IdentificationCode X.435 has its own arc: 2.6.7.11 If we can get the EDI arc registered this way (probably is and only documented in X.435), the PRESTO! Any company that has an EDI identifier has an OID arc. Can anyone fill in the missing parts of this and then perhaps Denis can add this as a recommendation for company PIs. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ietf-pkix@imc.org Tue Aug 1 12:38:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26440 for ; Tue, 1 Aug 2000 12:38:27 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA11452; Tue, 1 Aug 2000 09:34:10 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 1 Aug 2000 09:34:08 -0700 Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11422 for ; Tue, 1 Aug 2000 09:34:07 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id MAA11137 for ; Tue, 1 Aug 2000 12:24:51 -0400 (EDT) Message-Id: <200008011624.MAA11133@roadblock.missi.ncsc.mil> Date: Tue, 1 Aug 2000 12:33:32 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Company OIDs for free for PIs? To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4j+iCgy0lNDZBiGBdU/0zQ== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Bob, Have you considered using Private Enterprise codes (http://www.isi.edu/in-notes/iana/assignments/enterprise-numbers)? True, the arc 2.6.7.11 is a little shorter than the IETF's 1.3.6.1.4.1, but that shouldn't be a big deal. They're both free. Dave > Date: Tue, 01 Aug 2000 10:13:57 -0400 > To: ietf-pkix@imc.org > From: Robert Moskowitz > Subject: Company OIDs for free for PIs? > > I have often thought about how little companies can get OIDs for > free. After all, a few thousand bills for a small company can be a lot of > money... > > What I have seen is every company can have an EDI identifier. X.435 > (EDIFACT) has defined over 300 EDI identifier namespaces (DUNS being the > most common, supposedly). > > I **THINK** this is the EDIFACT UNB IdentificationCode > > X.435 has its own arc: 2.6.7.11 > > If we can get the EDI arc registered this way (probably is and only > documented in X.435), the PRESTO! Any company that has an EDI identifier > has an OID arc. > > Can anyone fill in the missing parts of this and then perhaps Denis can add > this as a recommendation for company PIs. > > Robert Moskowitz > ICSA > Security Interest EMail: rgm-sec@htt-consult.com > > > > ***************************************************************************** > This confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ****************************************************************************** From owner-ietf-pkix@imc.org Tue Aug 1 15:03:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21695 for ; Tue, 1 Aug 2000 15:03:14 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA14454; Tue, 1 Aug 2000 11:58:53 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 1 Aug 2000 11:58:07 -0700 Received: from htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA14416 for ; Tue, 1 Aug 2000 11:58:06 -0700 (PDT) Received: from rgm.htt-consult.com ([147.73.134.30]) by htt-consult.com ; Tue, 01 Aug 2000 13:01:31 -0400 Message-Id: <4.3.2.7.2.20000801125102.03c96890@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 Aug 2000 13:00:31 -0400 To: "David P. Kemp" , ietf-pkix@imc.org From: Robert Moskowitz Subject: Re: Company OIDs for free for PIs? In-Reply-To: <200008011624.MAA11133@roadblock.missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 12:33 PM 8/1/2000 -0400, David P. Kemp wrote: >Have you considered using Private Enterprise codes >(http://www.isi.edu/in-notes/iana/assignments/enterprise-numbers)? Actually, I have. I got one for the AIAG (Automotive Industry Action Group) a couple of years ago :) >True, the arc 2.6.7.11 is a little shorter than the IETF's 1.3.6.1.4.1, >but that shouldn't be a big deal. They're both free. We would need to educate small businesses and IANA would have to get ready for a flood of 10Ks of company requests. My little DBA, HTT Consulting, already has a DUNs #. Once I know how this arc would work (eg 2.6.7.11.4.5), I would then have a defacto arc. In Europe, WIPO assigns company #s, they have over 25000 such companies registered already. Again, instant arc. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ietf-pkix@imc.org Tue Aug 1 15:05:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21924 for ; Tue, 1 Aug 2000 15:05:09 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA14570; Tue, 1 Aug 2000 12:00:53 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 1 Aug 2000 12:00:51 -0700 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14535 for ; Tue, 1 Aug 2000 12:00:50 -0700 (PDT) From: tgindin@us.ibm.com Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA24996; Tue, 1 Aug 2000 15:04:25 -0400 Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id PAA24976; Tue, 1 Aug 2000 15:04:27 -0400 Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525692E.0068C3C5 ; Tue, 1 Aug 2000 15:04:18 -0400 X-Lotus-FromDomain: IBMUS To: "David P. Kemp" , denis.pinkas@bull.net cc: ietf-pkix@imc.org Message-ID: <8525692E.0068C144.00@D51MTA04.pok.ibm.com> Date: Tue, 1 Aug 2000 15:04:10 -0400 Subject: Re: Company OIDs for free for PIs? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe IANA even publishes their OID assignments at that location, which neutralizes the major advantage of using a URI of the approximate format http://domain/EmployeeAssignments?DateOfFirstUse. In view of that, that alternative is no longer necessary, although I'm sorry to have missed the meeting in Pittsburgh. The application form for new assignments in IANA's OID list is at IANA proper: http://www.iana.org/cgi-bin/enterprise.pl. My only remaining question is whether IANA will continue to provide a free service if every company with > 100 employees asks for this. I suppose they could charge a SMALL fee instead. Tom Gindin "David P. Kemp" on 08/01/2000 12:33:32 PM Please respond to "David P. Kemp" To: ietf-pkix@imc.org cc: Subject: Re: Company OIDs for free for PIs? Bob, Have you considered using Private Enterprise codes (http://www.isi.edu/in-notes/iana/assignments/enterprise-numbers)? True, the arc 2.6.7.11 is a little shorter than the IETF's 1.3.6.1.4.1, but that shouldn't be a big deal. They're both free. Dave > Date: Tue, 01 Aug 2000 10:13:57 -0400 > To: ietf-pkix@imc.org > From: Robert Moskowitz > Subject: Company OIDs for free for PIs? > > I have often thought about how little companies can get OIDs for > free. After all, a few thousand bills for a small company can be a lot of > money... > > What I have seen is every company can have an EDI identifier. X.435 > (EDIFACT) has defined over 300 EDI identifier namespaces (DUNS being the > most common, supposedly). > > I **THINK** this is the EDIFACT UNB IdentificationCode > > X.435 has its own arc: 2.6.7.11 > > If we can get the EDI arc registered this way (probably is and only > documented in X.435), the PRESTO! Any company that has an EDI identifier > has an OID arc. > > Can anyone fill in the missing parts of this and then perhaps Denis can add > this as a recommendation for company PIs. > > Robert Moskowitz > ICSA > Security Interest EMail: rgm-sec@htt-consult.com > > > > ***************************************************************************** > This confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ****************************************************************************** From owner-ietf-pkix@imc.org Tue Aug 1 20:32:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19155 for ; Tue, 1 Aug 2000 20:32:13 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA21436; Tue, 1 Aug 2000 17:28:03 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 1 Aug 2000 17:27:56 -0700 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA21399 for ; Tue, 1 Aug 2000 17:27:54 -0700 (PDT) Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46555) id <0FYN004012S0MT@ext-mail.valicert.com> for ietf-pkix@imc.org; Tue, 01 Aug 2000 17:31:24 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46555) with ESMTP id <0FYN0037X1VOTD@ext-mail.valicert.com> for ietf-pkix@imc.org; Tue, 01 Aug 2000 17:11:48 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Tue, 01 Aug 2000 17:02:56 -0700 Content-return: allowed Date: Tue, 01 Aug 2000 17:02:55 -0700 From: Stefan Richards Subject: RE: OCSP, SCVP vendors To: "'ietf-pkix@imc.org'" Message-id: <27FF4FAEA8CDD211B97E00902745CBE20140AAF0@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe ValiCert Inc. actively tests ValiCert partner products for interoperability with OCSP. ValiCert and RSA Data Security Inc. will soon be hosting an OCSP interoperability testing site to provide a testbed for OCSP-enabled applications to achieve interoperability (http://www.rsasecurity.com/standards/ocsp/). ValiCert would like to premote the same sort of intiatives for SCVP and is interested in working with a partner or partners on such efforts. For more information on the subject, please feel free to contact me directly. --Stefan ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Stefan Richards (650)567-5604 ValiCert Inc. stefanr@valicert.com Securing e-Transactions(tm) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --- Mohamed A. Elissa wrote: Hi all, I need to know if there are any vendors doing interoperability tests for OCSP and SCVP, and where to get more information about the products passed the tests. Mohamed A. Eissa Intel of Canada, Ltd. (416) 622-7175 2 Eva Road, Suite 220 Toronto, Ontario, M9C 2A8 From owner-ietf-pkix@imc.org Tue Aug 1 22:11:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10248 for ; Tue, 1 Aug 2000 22:11:44 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA29724; Tue, 1 Aug 2000 19:07:33 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 1 Aug 2000 19:07:26 -0700 Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA29692 for ; Tue, 1 Aug 2000 19:07:24 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Aug 2000 22:11:49 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF22DCEE@panda.chrysalis-its.com> To: tim.polk@nist.gov Cc: ietf-pkix@imc.org Subject: RE: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-00.txt Date: Tue, 1 Aug 2000 22:11:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFFC27.044D9782" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFFC27.044D9782 Content-Type: text/plain; charset="iso-8859-1" Hi Tim, Here are some minor comments on this draft: a. Section 3.3, the description and presentation of what key usage extensions may optionally appear in a CA and/or an end entity certificate should be made consistent between the different algorithms. For example, the draft does not distinguish between a CA and an end entity certificate for ECDSA. The draft only mentions for ECDSA that if the keyCertSign and cRLSign values may only be asserted if the basicConstraints extension is present and cA is TRUE, but not for other algorithms. The draft mentions for KEA that the encipherOnly and decipherOnly values may only be asserted if the keyAgreement value is also asserted, but not Diffie-Hellman. b. Section 3.3.4, you refer to sections 3.1.1 and 3.1.2 in many instances, however these two sections have nothing to do with KEA. Regards, Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 ------_=_NextPart_001_01BFFC27.044D9782 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-00.txt

Hi Tim,

Here are some minor comments on this draft:

a.  Section 3.3, the description and = presentation of what key usage extensions may optionally appear in a CA = and/or an end entity certificate should be made consistent between the = different algorithms. For example, the draft does not distinguish = between a CA and an end entity certificate for ECDSA. The draft only = mentions for ECDSA that if the keyCertSign and cRLSign values may only = be asserted if the basicConstraints extension is present and cA is = TRUE, but not for other algorithms. The draft mentions for KEA that the = encipherOnly and decipherOnly values may only be asserted if the = keyAgreement value is also asserted, but not Diffie-Hellman.

b.  Section 3.3.4, you refer to sections 3.1.1 = and 3.1.2 in many instances, however these two sections have nothing to = do with KEA.

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078

------_=_NextPart_001_01BFFC27.044D9782-- From owner-ietf-pkix@imc.org Tue Aug 1 22:41:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14706 for ; Tue, 1 Aug 2000 22:41:49 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA02269; Tue, 1 Aug 2000 19:37:44 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 1 Aug 2000 19:37:40 -0700 Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA02230 for ; Tue, 1 Aug 2000 19:37:33 -0700 (PDT) Received: from [128.33.238.18] (TC018.BBN.COM [128.33.238.18]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id WAA20225 for ; Tue, 1 Aug 2000 22:41:09 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: Date: Tue, 1 Aug 2000 22:24:44 -0400 To: ietf-pkix@imc.org From: Stephen Kent Subject: draft WG meeting minutes Content-Type: multipart/alternative; boundary="============_-1246938322==_ma============" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --============_-1246938322==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" The draft minutes for today's WG meeting are reproduced below. I'll accept corrections until 8/11. Steve ------- PKIX WG Meeting 8/1/00 Edited by Steve Kent (WG co-chair) The PKIX WG met once during the 48th IETF and a total of approximately 180 individuals participated in this meeting. The meeting began with the announcement that Tim Polk of NIST will take over from Warwick Ford as a co-chair of the WG. Warwick received a round of applause from the audience, for his service to the Wg since its inception. Tim began the meeting with a review of the status of all of the WG documents. The following text summarizes the status of the documents: PKIX COMPLETED DOCUMENTS (RFCs) PKIX Cert/CRL Profile (RFC 2459) HTTP/FTP Operations (RFC 2585) LDAP V2 Operational Protocols (RFC 2559) LDAP V2 Schema (RFC 2587) OCSP (RFC 2560) CMP (RFC 2510) CRMF (RFC 2511) CMC (RFC 2797) Diffie-Hellman POP (RFC 2875) Certificate Policy/Practices Guideline (RFC 2527) KEA Algorithms for Profile (RFC 2528) PKIX WORK IN PROGRESS (Internet Drafts) Revised Profile (draft-ietf-pkix-new-part1-02.txt) Algorithms for Profile (draft-ietf-pkix-ipki-pkalgs-00.txt) Qualified Certificates (draft-ietf-pkix-qc-05.txt) Time Stamp (draft-ietf-pkix-time-stamp-09.txt) PKIX Roadmap (draft-ietf-pkix-roadmap-05.txt) Revised CMP (draft-ietf-pkix-rfc2510bis.01) CMP Transports (draft-ietf-pkix-cmp-transport-protocols-01.txt) Operational Protocols - LDAPv3 (draft-ietf-pkix-ldap-v3-02.txt) Additional LDAP Schema (draft-ietf-pkix-ldap-schema-00.txt) Attribute Certificate Profile for Authorization (draft-ietf-pkix-ac509prof-04.txt) Limited Attribute Cert Acquisition Prot (draft-ietf-pkix-laap-01.txt) DCS (draft-ietf-pkix-dcs-05.txt) Simple Certificate Validation Protocol (SCVP) (draft-ietf-pkix-scvp-03.txt) Permanent Identifier (draft-ietf-pkix-pi-00.txt) Repository Locator Service (draft-ietf-pkix-pkixrep-00.txt) Tech. Rqmts. For Non-Repudiation (draft-ietf-pkix-technr-01.txt) ACTIVE PROJECTS: LDAP v3 Profile (D. Chadwick-U. of Salford) Split profile into two pieces: protocol vs. schema. The protocol parts should be completed in the next 6-8 weeks and be ready for WG last call. (Suggestion that the LDAP WG also be included in this last call.) The schema work will take longer, as it is a new topic. A major change for the schema is to allow searching on certificate fields, rather than searching on the directory attributes extracted from the certificate. For now, plan to keep the schema work related to certificates in PKIX, not in an LDAP WG, with David acting as principal liaison between the two groups. RFC 2459 evolution (T. Polk-NIST) 2459 has been split into algorithm profiles vs. certificate & CRL syntax and processing. This allows the algorithms document to be revised as algorithms change, without affecting the syntax and processing standard. There is little new material here, mostly clarifications, editorial revisions, etc. We will hold a straw poll on the list on naming mandatory algorithms, e.g., RSA and SHA-1. With the end of the RSA patent period, many other security WGs are taking similar steps. Also, if the WG decides to identify mandatory algorithms, we need to decide whether they are specified in the certificate and CRL processing document, or in the algorithms document. (See slides for more details.) We should be able to go to WG last call very soon on these documents. Qualified Certificates (S. Santesson-AddTrust) Discussions at this IETF meeting have resolved the few remaining points of contention with regard to this draft. Minor changes in wording will result in a new draft by the end of this week and this draft will be forwarded to the security area directors to proceed with the IESG last call. Permanent Identifiers (D, Pinkas-Bull) To be used only in certificates issued to individuals. Designed to track real world identity in the face of name changes, e.g., marriage or job changes within an organization. The ID is expressed as a new name type, with two components; an assigner authority and a name. The first component may be omitted, in which case the certificate Issuer is presumed to be the assigner authority. Note that a registered ID (from general name form) has the necessary property that it is globally unique, and permanent (although not directly meaningful). Thus, depending on which general name form is employed, one can compare names either within a CA domain, or globally, across all CAs. Plan for now is to proceed with it as a separate document, not merged with the QC or son-of-RFC-2459 documents. (See slides for more details.) Time Stamping Protocol (D. Pinkas-Bull) Now on version 9. Several changes made after last call completed. Changes include definition of the serial number consistent with 2459 (can even be a hash of up to 160 bits!), change to SIA from AIA, etc. A number of minor wording changes were made, but the restriction on exclusive use of the TSA private key for signing responses has been preserved. Ready for forwarding to the IESG. Preface to OCSPX and SCVP discussions: As proposed at the Adelaide meeting, a small group was formed and generated a requirements document to characterize the motivations for remote validation services, to define the requirements for such services. The group did not compare the candidate protocols relative to these requirements. OCSP Extensions (M. Myers-VeriSign) Previous ID has expired, expunged from IETF web site. Mike argues that OCSP is the right choice for remote path processing (RPP), via the addition of extensions. Proposal is to revise RFC 2560, to fix minor problems, clarify OCPS role as a framework for remote validation services. Then, create separate documents to define extensions for remote path validation, remote path discovery, etc. So, there would not be an OCSPX document, but rather definitions for syntax and processing for standard extensions. (See slides for more details.) D. Pinkas provided some slides addressing the parameters of remote path processing, e.g., how the requestor constrains the path processing or path construction operation. So, the format needs to be able to indicate whether the requestor wants CRLs or OCSP responses, what security policy to use in evaluating a certificate path, other constraints, etc. Denis argues that the requirements document needs to cover more of these details. However, Paul Hoffman noted that the group was not able to agree to a larger set of "requirements." (See slides for more details.) SCVP (A. Malpani-ValiCert) The speaker reviewed RPP requirements and what OCSP does to support part of the process. Ambarish argues that changes to OCSP to meet these extended requirements may break existing OCSP implementations, and that the code base for OCSP is small, so there is not much to leverage in building an RPP protocol. SCVP will support both ASN.1 and XML, consistent with perceived client requirements to retain data in this format. (See slides for more details.) Attribute Certificates (S. Farrell-Baltimore) Profile has been updated, synchronized with latest X.509 version, and has completed WG last call. It is suggested that this document reference the successor to 2459, which clears up the residual reference issues. CMP (C. Adams-Entrust) CMP RFC is being revised to reflect minor changes. Plan is to wait until completion of interoperability testing (in the PKI forum) to finalize changes to this document, to reflect any further clarifications that arise from this testing. Repository Locator (P. Hallem-Baker-Verisign) Goal of this document is to specify a means by which one can map an RFC822 name for a user to the LDAP server where the user's certificates are stored. The proposed approach is to use the SRV record in the DNS to provide the necessary pointer. The SRV record is analogous to an MX record, but more general, supporting a list of services and matching addresses. Open questions include the internationalization of DNS (which the DNS WG will address), plus communicating conventions for access protocols (LDAP, HTTP, ...). The base document is a very small work item, because it is merely profiling the existing SRV record. Separate documents will be generated to describe each access protocol convention, e.g., LDAP, OCSP, and HTTP. Need to coordinate with LDAP WG and maybe DNS WGs on their plans for using SRV records for LDAP directory location. (See slides for more details.) CMP Interoperability testing (B. Moskowitz-ICSA) ICSA is working with PKI Forum to coordinate these interoperability tests. Three workshops have been conducted to date, with more scheduled for August and September. Various algorithms, transport protocols, POP mechanisms have been tested. A number vendors have participated. Planned public demo at NISSC in October. Experience shows that variants in CA-side implementations do cause interoperability problems, and further clarifications are needed in RFC 2510 to help resolve ambiguities. CMC interoperability testing may also be pursued in the future. --============_-1246938322==_ma============ Content-Type: text/enriched; charset="us-ascii" The draft minutes for today's WG meeting are reproduced below. I'll accept corrections until 8/11. Steve ------- Courier_NewPKIX WG Meeting 8/1/00 Edited by Steve Kent (WG co-chair) The PKIX WG met once during the 48th IETF and a total of approximately 180 individuals participated in this meeting. The meeting began with the announcement that Tim Polk of NIST will take over from Warwick Ford as a co-chair of the WG. Warwick received a round of applause from the audience, for his service to the Wg since its inception. Tim began the meeting with a review of the status of all of the WG documents. The following text summarizes the status of the documents: PKIX COMPLETED DOCUMENTS (RFCs) PKIX Cert/CRL Profile (RFC 2459) HTTP/FTP Operations (RFC 2585) LDAP V2 Operational Protocols (RFC 2559) LDAP V2 Schema (RFC 2587) OCSP (RFC 2560) CMP (RFC 2510) CRMF (RFC 2511) CMC (RFC 2797) Diffie-Hellman POP (RFC 2875) Certificate Policy/Practices Guideline (RFC 2527) KEA Algorithms for Profile (RFC 2528) PKIX WORK IN PROGRESS (Internet Drafts) Revised Profile (draft-ietf-pkix-new-part1-02.txt) Algorithms for Profile (draft-ietf-pkix-ipki-pkalgs-00.txt) Qualified Certificates (draft-ietf-pkix-qc-05.txt) Time Stamp (draft-ietf-pkix-time-stamp-09.txt) PKIX Roadmap (draft-ietf-pkix-roadmap-05.txt) Revised CMP (draft-ietf-pkix-rfc2510bis.01) CMP Transports (draft-ietf-pkix-cmp-transport-protocols-01.txt) Operational Protocols - LDAPv3 (draft-ietf-pkix-ldap-v3-02.txt) Additional LDAP Schema (draft-ietf-pkix-ldap-schema-00.txt) Attribute Certificate Profile for Authorization (draft-ietf-pkix-ac509prof-04.txt) Limited Attribute Cert Acquisition Prot (draft-ietf-pkix-laap-01.txt) DCS (draft-ietf-pkix-dcs-05.txt) Simple Certificate Validation Protocol (SCVP) (draft-ietf-pkix-scvp-03.txt) Permanent Identifier (draft-ietf-pkix-pi-00.txt) Repository Locator Service (draft-ietf-pkix-pkixrep-00.txt) Tech. Rqmts. For Non-Repudiation (draft-ietf-pkix-technr-01.txt) ACTIVE PROJECTS: LDAP v3 Profile (D. Chadwick-U. of Salford) Split profile into two pieces: protocol vs. schema. The protocol parts should be completed in the next 6-8 weeks and be ready for WG last call. (Suggestion that the LDAP WG also be included in this last call.) The schema work will take longer, as it is a new topic. A major change for the schema is to allow searching on certificate fields, rather than searching on the directory attributes extracted from the certificate. For now, plan to keep the schema work related to certificates in PKIX, not in an LDAP WG, with David acting as principal liaison between the two groups. RFC 2459 evolution (T. Polk-NIST) 2459 has been split into algorithm profiles vs. certificate & CRL syntax and processing. This allows the algorithms document to be revised as algorithms change, without affecting the syntax and processing standard. There is little new material here, mostly clarifications, editorial revisions, etc. We will hold a straw poll on the list on naming mandatory algorithms, e.g., RSA and SHA-1. With the end of the RSA patent period, many other security WGs are taking similar steps. Also, if the WG decides to identify mandatory algorithms, we need to decide whether they are specified in the certificate and CRL processing document, or in the algorithms document. (See slides for more details.) We should be able to go to WG last call very soon on these documents. Qualified Certificates (S. Santesson-AddTrust) Discussions at this IETF meeting have resolved the few remaining points of contention with regard to this draft. Minor changes in wording will result in a new draft by the end of this week and this draft will be forwarded to the security area directors to proceed with the IESG last call. Permanent Identifiers (D, Pinkas-Bull) To be used only in certificates issued to individuals. Designed to track real world identity in the face of name changes, e.g., marriage or job changes within an organization. The ID is expressed as a new name type, with two components; an assigner authority and a name. The first component may be omitted, in which case the certificate Issuer is presumed to be the assigner authority. Note that a registered ID (from general name form) has the necessary property that it is globally unique, and permanent (although not directly meaningful). Thus, depending on which general name form is employed, one can compare names either within a CA domain, or globally, across all CAs. Plan for now is to proceed with it as a separate document, not merged with the QC or son-of-RFC-2459 documents. (See slides for more details.) Time Stamping Protocol (D. Pinkas-Bull) Now on version 9. Several changes made after last call completed. Changes include definition of the serial number consistent with 2459 (can even be a hash of up to 160 bits!), change to SIA from AIA, etc. A number of minor wording changes were made, but the restriction on exclusive use of the TSA private key for signing responses has been preserved. Ready for forwarding to the IESG. Preface to OCSPX and SCVP discussions: As proposed at the Adelaide meeting, a small group was formed and generated a requirements document to characterize the motivations for remote validation services, to define the requirements for such services. The group did not compare the candidate protocols relative to these requirements. OCSP Extensions (M. Myers-VeriSign) Previous ID has expired, expunged from IETF web site. Mike argues that OCSP is the right choice for remote path processing (RPP), via the addition of extensions. Proposal is to revise RFC 2560, to fix minor problems, clarify OCPS role as a framework for remote validation services. Then, create separate documents to define extensions for remote path validation, remote path discovery, etc. So, there would not be an OCSPX document, but rather definitions for syntax and processing for standard extensions. (See slides for more details.) D. Pinkas provided some slides addressing the parameters of remote path processing, e.g., how the requestor constrains the path processing or path construction operation. So, the format needs to be able to indicate whether the requestor wants CRLs or OCSP responses, what security policy to use in evaluating a certificate path, other constraints, etc. Denis argues that the requirements document needs to cover more of these details. However, Paul Hoffman noted that the group was not able to agree to a larger set of "requirements." (See slides for more details.) SCVP (A. Malpani-ValiCert) The speaker reviewed RPP requirements and what OCSP does to support part of the process. Ambarish argues that changes to OCSP to meet these extended requirements may break existing OCSP implementations, and that the code base for OCSP is small, so there is not much to leverage in building an RPP protocol. SCVP will support both ASN.1 and XML, consistent with perceived client requirements to retain data in this format. (See slides for more details.) Attribute Certificates (S. Farrell-Baltimore) Profile has been updated, synchronized with latest X.509 version, and has completed WG last call. It is suggested that this document reference the successor to 2459, which clears up the residual reference issues. CMP (C. Adams-Entrust) CMP RFC is being revised to reflect minor changes. Plan is to wait until completion of interoperability testing (in the PKI forum) to finalize changes to this document, to reflect any further clarifications that arise from this testing. Repository Locator (P. Hallem-Baker-Verisign) Goal of this document is to specify a means by which one can map an RFC822 name for a user to the LDAP server where the user's certificates are stored. The proposed approach is to use the SRV record in the DNS to provide the necessary pointer. The SRV record is analogous to an MX record, but more general, supporting a list of services and matching addresses. Open questions include the internationalization of DNS (which the DNS WG will address), plus communicating conventions for access protocols (LDAP, HTTP, ...). The base document is a very small work item, because it is merely profiling the existing SRV record. Separate documents will be generated to describe each access protocol convention, e.g., LDAP, OCSP, and HTTP. Need to coordinate with LDAP WG and maybe DNS WGs on their plans for using SRV records for LDAP directory location. (See slides for more details.) CMP Interoperability testing (B. Moskowitz-ICSA) ICSA is working with PKI Forum to coordinate these interoperability tests. Three workshops have been conducted to date, with more scheduled for August and September. Various algorithms, transport protocols, POP mechanisms have been tested. A number vendors have participated. Planned public demo at NISSC in October. Experience shows that variants in CA-side implementations do cause interoperability problems, and further clarifications are needed in RFC 2510 to help resolve ambiguities. CMC interoperability testing may also be pursued in the future. --============_-1246938322==_ma============-- From owner-ietf-pkix@imc.org Wed Aug 2 00:48:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10919 for ; Wed, 2 Aug 2000 00:48:29 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA10501; Tue, 1 Aug 2000 21:44:28 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 1 Aug 2000 21:44:20 -0700 Received: from texcel.net (w092.z208037077.nyc-ny.dsl.cnc.net [208.37.77.92]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA10465; Tue, 1 Aug 2000 21:44:17 -0700 (PDT) From: Subject: FREE Computer Support & Consulting for your Business - to remove Send a Blank Reply Date: Wed, 2 Aug 2000 00:47:30 Message-Id: <466.887800.842154@texcel.net> Reply-To: remove@texcel.net Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Precedence: bulk To: undisclosed-recipients:; List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Networking and Computer Solutions - TEXCEL provides Computer Solutions and Networking Services for small to mid-sized businesses. From owner-ietf-pkix@imc.org Wed Aug 2 09:27:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09887 for ; Wed, 2 Aug 2000 09:27:07 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA06174; Wed, 2 Aug 2000 06:22:27 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 2 Aug 2000 06:22:06 -0700 Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA06127 for ; Wed, 2 Aug 2000 06:22:05 -0700 (PDT) Received: from [128.33.238.71] (TC071.BBN.COM [128.33.238.71]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id JAA09560; Wed, 2 Aug 2000 09:25:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <8525692A.0080C532.00@D51MTA04.pok.ibm.com> References: <8525692A.0080C532.00@D51MTA04.pok.ibm.com> Date: Wed, 2 Aug 2000 08:49:02 -0400 To: tgindin@us.ibm.com From: Stephen Kent Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt Cc: "PKIX-List" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Tom, > My point is that in very many cases, an employee serial number or >something like that is just as good for the RP's as a department. Its >greater stability compensates for its lack of user-friendliness. As you >rightly pointed out to Anders, if manual selection of one user from a list >of choices is the primary scenario in which an extra attribute is used, >serial numbers aren't the best way to make such a selection. However, they >may well be more useful for access control lists or for non-repudiation. I think the employee serial number serves a different function from the organizational fine structure attributes. the former is appropriate when stability over time is critical, for the reasons that Denis has introduced his permanent identifier attribute. However, when one wants to make an access control decision based on organizational affiliation, the later form of ID is more helpful. Also, as I noted earlier, from a human cognitive perspective, serial numbers are not a useful way to disambiguate individuals. Steve From owner-ietf-pkix@imc.org Thu Aug 3 13:10:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25882 for ; Thu, 3 Aug 2000 13:10:23 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA19721; Thu, 3 Aug 2000 10:05:14 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 3 Aug 2000 10:03:49 -0700 Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19676 for ; Thu, 3 Aug 2000 10:03:47 -0700 (PDT) Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA19186 for ; Thu, 3 Aug 2000 13:07:35 -0400 (EDT) Received: from anuxc.mv.lucent.com (h135-13-160-12.lucent.com [135.13.160.12]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA19138; Thu, 3 Aug 2000 13:07:33 -0400 (EDT) Received: from irene by anuxc.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA03015; Thu, 3 Aug 2000 13:04:53 -0400 (EDT) Message-Id: <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> X-Sender: irg@anuxc.mv.lucent.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 03 Aug 2000 13:08:14 -0400 To: Simon Tardell From: Irene Gassko Subject: RE: OCSP request Cc: "'Denis Pinkas'" , Juergen Brauckmann , ietf-pkix@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_525358525==_.ALT" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --=====================_525358525==_.ALT Content-Type: text/plain; charset="us-ascii" At 11:46 AM 07/27/2000 +0200, Simon Tardell wrote: >Denis, > >> > This is not sufficient for systems that must be robust/tolerant against >CA >> > key compromise or such things. >> >> Key compromise is an exceptional event (that should not happen, but >> might happen) that must be addressed under a disaster recovery plan >> (i.e. revoke the CA whose key has been compromised in all the >> certificates that has been issued for that CA by other CAs). > >I see the disaster, but I don't see the recovery in this. > >As I see it, the problem the German model tries to tackle is that a CA which >has issued lots of certificates to the public (say millions) gets it keys >compromised somehow. Time-stamping services secure documents signed before >this moment, but there is another problem. Millions of germans are now >unable to go about their daily business. Potentially the German economy >grinds to a halt while the CA reissues millions of smart cards. Obviously >this would be a very bad thing. I'd hate to know that this scenario has not >been prepared in advance. Since the end-user keys did not get compromised >they can still be trusted. What is a problem is the linkage between the >holder and his keys, embodied in the certificates. Actually, such a scenario can be avoided. We suggest a possible solution in our paper which my coauthor put on his web site http:// www.bell-labs.com/user/philmac/research/cert-pkcfinal.ps.gz The main idea is to eliminate signatures in certificates and have CA sign a Merkle tree of certificates instead. Then CA key compromise requires the change in that signature (which can be downloaded separately) but leaves cards and certificates unperturbed. You can use multiple signatures with different signature algorithms and keep keys on different continents if you wish. This scheme also helps with archiving. And you do not need a CRL. It can be used with X.509 certificates, making the signature on a certificate optional, rather than mandatory. Or you can make it an owner's signature instead of a CA's signature. Irene ---------------------------------------------------------------------------- ------------------------------------------------------- Irene Gassko Bell Laboratories http://www.lucent.com Lucent Technologies Secure Technologies Dept. 1600 Osgood Street phone: (978) 960-5767 Room 30-2-A31 e-mail: gassko@lucent.com N. Andover, MA 01845 fax: (978) 960-3240 --=====================_525358525==_.ALT Content-Type: text/html; charset="us-ascii" At 11:46 AM 07/27/2000 +0200, Simon Tardell wrote:
>Denis,
>
>> > This is not sufficient for systems that must be  robust/tolerant against
>CA
>> > key compromise or such things.
>>
>> Key compromise is an exceptional event (that should not happen, but
>> might happen) that must be addressed under a disaster recovery plan
>> (i.e. revoke the CA whose key has been compromised in all the
>> certificates that has been issued for that CA by other CAs).
>
>I see the disaster, but I don't see the recovery in this.
>
>As I see it, the problem the German model tries to tackle is that a CA which
>has issued lots of certificates to the public (say millions) gets it keys
>compromised somehow. Time-stamping services secure documents signed before
>this moment, but there is another problem. Millions of germans are now
>unable to go about their daily business. Potentially the German economy
>grinds to a halt while the CA reissues millions of smart cards. Obviously
>this would be a very bad thing. I'd hate to know that this scenario has not
>been prepared in advance. Since the end-user keys did not get compromised
>they can still be trusted. What is a problem is the linkage between the
>holder and his keys, embodied in the certificates.

Actually, such a scenario can be avoided. We suggest a possible solution
in our paper which my coauthor put on his web site

http://www.bell-labs.com/user/philmac/research/cert-pkcfinal.ps.gz

The main idea is to eliminate signatures in certificates and have CA
sign a Merkle tree of certificates instead. Then CA key compromise
requires the change in that signature (which can be downloaded separately)
but leaves cards and certificates unperturbed. You can use multiple
signatures with different signature algorithms and keep keys on different
continents if you wish. This scheme also helps with archiving. And you do not
need a CRL. It can be used with X.509 certificates, making the signature
on a certificate optional, rather than mandatory. Or you can make it
an owner's signature instead of a CA's signature.

Irene


-----------------------------------------------------------------------------------------------------------------------------------
Irene Gassko                     Bell Laboratories              http://www.lucent.com
Lucent Technologies             Secure Technologies Dept.
1600 Osgood Street                       phone: (978) 960-5767
Room 30-2-A31                    e-mail:        gassko@lucent.com
N. Andover, MA 01845             fax:   (978) 960-3240 --=====================_525358525==_.ALT-- From owner-ietf-pkix@imc.org Thu Aug 3 22:28:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27419 for ; Thu, 3 Aug 2000 22:28:02 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA15499; Thu, 3 Aug 2000 19:23:50 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 3 Aug 2000 19:22:22 -0700 Received: from sina.com ([202.106.187.164]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA15298 for ; Thu, 3 Aug 2000 19:22:21 -0700 (PDT) Received: (qmail 9017 invoked by uid 99); 4 Aug 2000 02:26:25 -0000 Message-ID: <20000804022625.9012.qmail@sina.com> From: wxhietf To: ietf-pkix@imc.org Subject: Difference IN Enterprise CA And Trade CA Date: Fri Aug 4 02:26:25 2000 X-Mailer: SinaMail 3.0Beta (FireToad) X-Priority: 3 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hello Everyone, we are planning to set up a Enterprise CA ,But the conception between Enterprise CA And Trade Ca( such as a financial Ca or a Post CA ) is not so clear to us. Anyone with the experence please help me. thanks wxh.ietf ______________________________________ =================================================================== ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn ²Î¼ÓÐÂÀË°ÂÔËÇéÂÂÌØʹÆÀÑ¡»î¶¯£¬Ç×ÁÙϤÄáǧìû°ÂÔËÊ¢»á¡£¿ìÀ´²Î¼Ó¡£ http://ad2.sina.com.cn/ads/olympics/ From owner-ietf-pkix@imc.org Thu Aug 3 22:28:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27617 for ; Thu, 3 Aug 2000 22:28:55 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA15624; Thu, 3 Aug 2000 19:24:47 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 3 Aug 2000 19:23:26 -0700 Received: from sina.com ([202.106.187.166]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA15426 for ; Thu, 3 Aug 2000 19:23:25 -0700 (PDT) Received: (qmail 27624 invoked by uid 99); 4 Aug 2000 02:28:15 -0000 Message-ID: <20000804022815.27623.qmail@sina.com> From: wxhietf To: ietf-pkix@imc.org Subject: Difference IN Enterprise CA And Trade CA Date: Fri Aug 4 02:28:15 2000 X-Mailer: SinaMail 3.0Beta (FireToad) X-Priority: 3 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hello Everyone, we are planning to set up a Enterprise CA ,But the conception between Enterprise CA And Trade Ca( such as a financial Ca or a Post CA ) is not so clear to us. Anyone with the experence please help me. My Email: wxhietf@sina.com thanks wxh.ietf ______________________________________ =================================================================== ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn ²Î¼ÓÐÂÀË°ÂÔËÇéÂÂÌØʹÆÀÑ¡»î¶¯£¬Ç×ÁÙϤÄáǧìû°ÂÔËÊ¢»á¡£¿ìÀ´²Î¼Ó¡£ http://ad2.sina.com.cn/ads/olympics/ From owner-ietf-pkix@imc.org Fri Aug 4 05:49:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03017 for ; Fri, 4 Aug 2000 05:49:43 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA20976; Fri, 4 Aug 2000 02:45:27 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 4 Aug 2000 02:45:14 -0700 Received: from fox.netfront.com.cn ([202.106.144.158]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA20937 for ; Fri, 4 Aug 2000 02:45:12 -0700 (PDT) Received: from wshu ([192.168.10.5]) by fox.netfront.com.cn (8.8.7/8.8.7) with SMTP id RAA20539 for ; Fri, 4 Aug 2000 17:41:41 +0800 From: "Star Wang" To: Subject: RE: Difference IN Enterprise CA And Trade CA Date: Fri, 4 Aug 2000 17:50:28 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20000804022815.27623.qmail@sina.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Hi, WXH: I am a system designer of PKI products. I don't know what you mean. You want to buy a product and set up a CA, or just develope and set up your organization's CA. I think the conceptions are not so imporant as you think, what you should know is investigating the real requirements, and set up a CA what can meet the requirements of your organization. So just forget "Enterprise CA" and "Trade CA", I think the basic functions of them are same, a user should apply his/her certificate (or the administrator apply the certificate for the user), and an administrator will look through the application, and ... ... . The import thing is what your organization's needs are, and you should make the policy according to the actual conditions, so you can do the following things. I think I can't write down all of the details in one mail, and my email is star_wang@sina.com, you can contract with me directly. So we can communication. Star Wang > -----Original Message----- > From: wxhietf [mailto:wxhietf@sina.com] > Sent: Friday, August 04, 2000 2:28 AM > To: ietf-pkix@imc.org > Subject: Difference IN Enterprise CA And Trade CA > > > Hello Everyone, > we are planning to set up a Enterprise CA ,But the conception between > Enterprise CA And Trade Ca( such as a financial Ca or a Post CA ) is not > so clear to us. > Anyone with the experence please help me. > > My Email: wxhietf@sina.com > > > thanks > wxh.ietf > ______________________________________ > > =================================================================== > ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn > ²Î¼ÓÐÂÀË°ÂÔËÇéÂÂÌØʹÆÀÑ¡»î¶¯£¬Ç×ÁÙϤÄáǧìû°ÂÔËÊ¢»á¡£¿ìÀ´²Î¼Ó¡£ > http://ad2.sina.com.cn/ads/olympics/ > From owner-ietf-pkix@imc.org Fri Aug 4 07:36:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03368 for ; Fri, 4 Aug 2000 07:36:16 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA27254; Fri, 4 Aug 2000 04:31:51 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 4 Aug 2000 04:31:40 -0700 Received: from dmz0101.rrl.co.uk (mail.rrl.co.uk [195.166.68.179]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA27200 for ; Fri, 4 Aug 2000 04:31:37 -0700 (PDT) Received: from nts006.rrl.co.uk (unverified) by dmz0101.rrl.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 04 Aug 2000 12:35:36 +0100 Received: from nts006.rrl.co.uk (unverified) by nts006.rrl.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 04 Aug 2000 12:34:32 +0100 Received: by nts006.rrl.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 4 Aug 2000 12:34:32 +0100 Message-Id: From: "Brian.Clarke" To: ietf-pkix@imc.org Subject: How should an OCSP responder cope with policy IDs Date: Fri, 4 Aug 2000 12:34:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe While implementing an OCSP responder we have been considering how to process extensions in requestors' certificates, i.e. if an OCSP request is signed, we should handle any extensions present in the signer's certificate correctly. Do people have a view on how a critically marked policy ID extension (id-ce-certificatePolicies) should be handled? For example, would the OCSP responder be expected to check the policy IDs against a list of known IDs. If the IDs were found the responder would then accept the request, but if a policy ID which was unknown to the responder was given, the responder would reject the request. Alternatively the responder could just ignore the policy Id information and process the OCSP request regardless. Any suggestions gratefully received. Brian. ---------------------------------------------------------------------- This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and may not be divulged to any third party without the express permission of the originator. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Racal Research Ltd. ---------------------------------------------------------------------- From owner-ietf-pkix@imc.org Sun Aug 6 16:01:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08315 for ; Sun, 6 Aug 2000 16:01:08 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA24096; Sun, 6 Aug 2000 12:56:08 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sun, 6 Aug 2000 12:54:52 -0700 Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24045 for ; Sun, 6 Aug 2000 12:54:50 -0700 (PDT) Received: from mega (t5o69p22.telia.com [213.64.110.22]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id VAA24588; Sun, 6 Aug 2000 21:58:48 +0200 (CEST) Message-ID: <001201bfffe8$fc2ff480$0201a8c0@mega.vincent.se> From: "Anders Rundgren" To: "PKIX-List" Subject: Digital Signatures - Legal Advice Wanted Date: Sun, 6 Aug 2000 22:57:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA24046 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Hi, I am working with an e-commerce standard that features server-based, organization-signed orders. However, server-based, organization-oriented digital signatures do currently not, to the my knowledge, have explicit support in any legal system. How to solve this? One way (the current one) is to state in separate agreements between the trading partners, that you will stand by these signatures in court. I wonder if there could be a more general solution like: A company officer digitally signs (using a personal certificate), a document where he/she states that signatures associated with a certain trading partner certificate are to be considered as legally binding from the company’s point of view. Such a document is preferably published on the company’s home-page for easy reference. How does this sound in the ears of lawyers? regards Anders Rundgren From owner-ietf-pkix@imc.org Sun Aug 6 16:57:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20348 for ; Sun, 6 Aug 2000 16:57:22 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA24762; Sun, 6 Aug 2000 13:52:58 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sun, 6 Aug 2000 13:52:54 -0700 Received: from hamster.gadens.com.au (root@dns.gadens.com.au [203.32.220.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24732 for ; Sun, 6 Aug 2000 13:52:33 -0700 (PDT) Received: from exchange.gadens.com.au ([10.1.8.3]) by hamster.gadens.com.au (8.9.3/8.9.3) with ESMTP id GAA85003; Mon, 7 Aug 2000 06:56:20 +1000 (EST) (envelope-from AMcCullagh@exchange.gadens.com.au) Received: by exchange.gadens.com.au with Internet Mail Service (5.5.2650.21) id <3YWS666Y>; Mon, 7 Aug 2000 07:00:32 +1000 Message-ID: From: Adrian McCullagh To: "'Anders Rundgren'" , PKIX-List Subject: RE: Digital Signatures - Legal Advice Wanted Date: Mon, 7 Aug 2000 07:00:27 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Anders In the paper based environment a company does not have its own signature. Companies are artificial legal entities and as such can only act through human agents. (Now this may change through the use of software agents but that is another issue). Hence for a company to be bound to a commercial transaction the human agent must have some authority either implied or express. A person digitally signing a digital document that attempts to bind a company should use their own private key for such action. The issue then revolves around the concept of authority. If the signer does not have the appropriate authority then the signer may be liable for "Breach of Warranty of Authority". If the signer has express authority to sign the document and thus bind the principal then the issue is simple. In Common law countries like the USA, Australia, UK and Canada, there is a doctrine known as ostensible authority. This provides that if a person signs a document on behalf of another legal entity (the principal) and the signer has some external reasonably perceived authority such that a reasonable person looking at the transaction objectively would believe that such person through his/her position had such authority to bind the principal then the principal is bound by the signers action. So as I see it, a director could digitally sign the digital document using the directors own personal private key and as part of the text of the document state the following word "signed for and on behalf of Company XXXX". This would indicate to the world that the signer is NOT signing the digital document so as to be personally bound but is signing as an agent and as such is attempting to bind the principal (company). The recipient would on receipt verify the digital signature using the signer's personal certificate that has the public key embodied in it. If the recipient is concerned about the authority then the recipient can check the company records to determine if the signer has the necessary implied/ostensible authority. To accelerate the process of verification of authority there may be some solution in the use of role based certificates or attribute certificates but I have not really give this issue sufficient thought. If there is still some doubt then the recipient can always check with the Company secretary or the Managing director as to such authority. The Uniform Electronic Transactions Act that is forming part of the Uniform Commercial Code of various US States does anticipate software agents and thus server based organisation digital signatures. But there are no cases that specifically deal with your issue. The simple solution is for a company officer to digitally sign the digital document and affix the words noted above in the text prior to digitally signing. I hope this is helpful. Adrian McCullagh Director of Electronic CommerceTel: 617 3231 1522 Gadens Lawyers Fax: 617 3229 5850 level 39 Central Plaza 1 345 Queen Street Brisbane Australia 4000 Ph. D. Candidate Thesis "The Incorporation of Trust Strategies in Digital Signature Regimes for Elec. Comm." Information Security Research Centre Queensland University of Technology - -----Original Message----- From: Anders Rundgren [ mailto:anders.rundgren@telia.com] Sent: Monday, August 07, 2000 6:58 AM To: PKIX-List Subject: Digital Signatures - Legal Advice Wanted Hi, I am working with an e-commerce standard that features server-based, organization-signed orders. However, server-based, organization-oriented digital signatures do currently not, to the my knowledge, have explicit support in any legal system. How to solve this? One way (the current one) is to state in separate agreements between the trading partners, that you will stand by these signatures in court. I wonder if there could be a more general solution like: A company officer digitally signs (using a personal certificate), a document where he/she states that signatures associated with a certain trading partner certificate are to be considered as legally binding from the company's point of view. Such a document is preferably published on the company's home-page for easy reference. How does this sound in the ears of lawyers? regards Anders Rundgren -----BEGIN PGP SIGNATURE----- Version: PGP Personal Edition 6.0.2 iQA/AwUBOY1FTJWt1NGjt4vzEQLdmACeJiR1FMKZ//6Mtfq+v5DfAGGo/q4AoJoM bWjrz+F/Xll2zwotTzuligVm =sEx7 -----END PGP SIGNATURE----- From owner-ietf-pkix@imc.org Mon Aug 7 09:59:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28635 for ; Mon, 7 Aug 2000 09:59:38 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA19355; Mon, 7 Aug 2000 06:54:49 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 7 Aug 2000 06:54:29 -0700 Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA19318 for ; Mon, 7 Aug 2000 06:54:28 -0700 (PDT) Received: from [128.33.238.66] (TC066.BBN.COM [128.33.238.66]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id JAA29865; Mon, 7 Aug 2000 09:58:32 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> References: <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> Date: Sun, 6 Aug 2000 17:55:17 -0400 To: Irene Gassko From: Stephen Kent Subject: RE: OCSP request Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Irene, >The main idea is to eliminate signatures in certificates and have CA >sign a Merkle tree of certificates instead. Then CA key compromise >requires the change in that signature (which can be downloaded separately) >but leaves cards and certificates unperturbed. You can use multiple >signatures with different signature algorithms and keep keys on different >continents if you wish. This scheme also helps with archiving. And you do not >need a CRL. It can be used with X.509 certificates, making the signature >on a certificate optional, rather than mandatory. Or you can make it >an owner's signature instead of a CA's signature. Irrespective of the merit of the approach to which you allude, the result would not be an X.509 cert. Signatures are mandatory, not optional, in the format that is the basis of this WG's activity. Steve From owner-ietf-pkix@imc.org Mon Aug 7 10:20:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09197 for ; Mon, 7 Aug 2000 10:20:28 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA19930; Mon, 7 Aug 2000 07:15:40 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 7 Aug 2000 07:15:38 -0700 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19897 for ; Mon, 7 Aug 2000 07:15:38 -0700 (PDT) Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA23631 for ; Mon, 7 Aug 2000 10:19:45 -0400 (EDT) Received: from anuxc.mv.lucent.com (h135-13-160-12.lucent.com [135.13.160.12]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA23615; Mon, 7 Aug 2000 10:19:44 -0400 (EDT) Received: from irene by anuxc.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA20757; Mon, 7 Aug 2000 10:17:03 -0400 (EDT) Message-Id: <4.1.20000807101230.03173400@anuxc.mv.lucent.com> X-Sender: irg@anuxc.mv.lucent.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 07 Aug 2000 10:19:54 -0400 To: Stephen Kent From: Irene Gassko Subject: RE: OCSP request Cc: ietf-pkix@imc.org In-Reply-To: References: <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Steve, You are right and I know that currently signatures are mandatory. But making changes in order to solve serious problems is a part of the standards process, isn't it? A lot of discussion in this group is devoted to suggested improvements in the standard. If making signatures optional can help with CA key change and cert archiving, would not it be a good idea to allow such usage (as in MAY)? Irene At 05:55 PM 08/06/2000 -0400, Stephen Kent wrote: >Irene, > > > > >>The main idea is to eliminate signatures in certificates and have CA >>sign a Merkle tree of certificates instead. Then CA key compromise >>requires the change in that signature (which can be downloaded separately) >>but leaves cards and certificates unperturbed. You can use multiple >>signatures with different signature algorithms and keep keys on different >>continents if you wish. This scheme also helps with archiving. And you do not >>need a CRL. It can be used with X.509 certificates, making the signature >>on a certificate optional, rather than mandatory. Or you can make it >>an owner's signature instead of a CA's signature. > >Irrespective of the merit of the approach to which you allude, the >result would not be an X.509 cert. Signatures are mandatory, not >optional, in the format that is the basis of this WG's activity. > >Steve ---------------------------------------------------------------------------- ------------------------------------------------------- Irene Gassko Bell Laboratories http://www.lucent.com Lucent Technologies Secure Technologies Dept. 1600 Osgood Street phone: (978) 960-5767 Room 30-2-A31 e-mail: gassko@lucent.com N. Andover, MA 01845 fax: (978) 960-3240 From owner-ietf-pkix@imc.org Mon Aug 7 10:36:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18577 for ; Mon, 7 Aug 2000 10:36:49 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA20515; Mon, 7 Aug 2000 07:32:09 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 7 Aug 2000 07:32:06 -0700 Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20483 for ; Mon, 7 Aug 2000 07:32:03 -0700 (PDT) Received: by ns.celocom.se; id QAA18164; Mon, 7 Aug 2000 16:36:09 +0200 (CEST) Received: from seexchange.celocom.se(10.10.10.11) by ns.celocom.se via smap (4.1) id xma018146; Mon, 7 Aug 00 16:35:14 +0200 Received: from celocom.se (levitte.celocom.se [10.10.10.124]) by seexchange.celocom.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QBR2MXTA; Mon, 7 Aug 2000 16:38:48 +0200 Sender: levitte@celocom.se Message-ID: <398EC915.1A06FE1@celocom.se> Date: Mon, 07 Aug 2000 16:35:01 +0200 From: Richard Levitte Organization: Celo Communications, Ltd. X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Irene Gassko CC: Stephen Kent , ietf-pkix@imc.org Subject: Re: OCSP request References: <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> <4.1.20000807101230.03173400@anuxc.mv.lucent.com> Content-Type: multipart/mixed; boundary="------------8E2B775E0071C9A35395E006" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. --------------8E2B775E0071C9A35395E006 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think we're into a little bit of nit-picking here. On this list, it's probably not possible to suggest a change of an ITU (do I remember correctly?) standard, such as X.509. Talking about changes to an RFC would probably prove a bit more fruitful. In this case, you probably mean RFC2459 or whatever draft that updates it. However, if I understand correctly, the meaning of RFC2459 is to be as close as possible to X.509, which makes the RFC bound to X.509, therefore making incompatible changes a bad thing. Furthermore, if making the signature OPTIONAL (which I assume would be the result), I'm sure there would be changes in the ASN.1 coding (be it BER, DER, or whatever) that doesn't allow correct interpretation of older certificates. Don't take my word for it though, I haven't studied the possible effects enough to actually know. This is just a hunch (sp?)... Irene Gassko wrote: > > You are right and I know that currently signatures are mandatory. > But making changes in order to solve serious problems is a part > of the standards process, isn't it? A lot of discussion in this > group is devoted to suggested improvements in the standard. If > making signatures optional can help with CA key change and cert > archiving, would not it be a good idea to allow such usage (as in > MAY)? -- Richard Levitte !!! New cell phone number !!! richard.levitte@celocom.se /* You might enjoy viewing the complete vCard */ --------------8E2B775E0071C9A35395E006 Content-Type: text/x-vcard; charset=us-ascii; name="richard.levitte.vcf" Content-Description: Card for Richard Levitte Content-Disposition: attachment; filename="richard.levitte.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Levitte;Richard tel;cell:+46-733-72 8811 tel;work:+46-8-58 72 8811 x-mozilla-html:FALSE org:Celo Communications version:2.1 email;internet:richard.levitte@celocom.se title:Software Artist adr;quoted-printable:;;Sveav=E4gen 145, 5tr=0D=0AStockholm;;;;SWEDEN note;quoted-printable:
=0D=0A=0D=0A=0D=0A =0D=0A=0D=0A
c=EAlo, =E2vi, =E2tum, (latin) 1,v.a.=0D=0A to hide something from one, to keep secret, to conceal.=0D=0A
=0D=0A
=0D=0A=0D=0A=0D=0A =0D=0A=0D=0A
=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A
o/~Coding, coding, coding
=0D=0A Keep'em hackers coding
=0D=0A And When They're Done Coding
=0D=0A COMPIIIIIIILE!!
=0D=0A
fn:Richard Levitte end:vcard --------------8E2B775E0071C9A35395E006-- From owner-ietf-pkix@imc.org Mon Aug 7 10:46:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24218 for ; Mon, 7 Aug 2000 10:46:02 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA21031; Mon, 7 Aug 2000 07:41:16 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 7 Aug 2000 07:41:15 -0700 Received: from dvnet8.dvnet.com ([209.121.31.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20999 for ; Mon, 7 Aug 2000 07:41:06 -0700 (PDT) Received: from CC787228-A (cc787228-a.hwrd1.md.home.com [24.180.131.6]) by dvnet8.dvnet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QK5F02F9; Mon, 7 Aug 2000 10:47:45 -0400 Received: by localhost with Microsoft MAPI; Mon, 7 Aug 2000 10:45:45 -0400 Message-ID: <01C0005C.A43805A0.aarsenault@dvnet.com> From: Al Arsenault To: "'Irene Gassko'" , Stephen Kent Cc: "ietf-pkix@imc.org" Subject: RE: OCSP request Date: Mon, 7 Aug 2000 10:45:45 -0400 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 79 TEXT Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe The problem with this scheme is that, even if it does help with archiving and recovery in the case of CA key compromise, it doesn't help in the normal certificate processing operations. With a certificate signed by a CA, I know that "the CA has vouched for the correctness of each of the data items in this certificate", subject to the normal discussions on how thoroughly the CA has verified them, yada, yada, yada. With a certificate not being signed, or being signed by the originator, I just know that I have a data structure, and I'm not sure about the CA's willingness to vouch for those items, until such time as I go fetch the signed Merkle tree that pertains and verify it, recursively to where I get to a trusted root. That is, I don't know if I have a complete spoof attempt, a corrupted cert, or anything else, until such time as I do the "revocation check". So it seems to me that in the normal processing mode, this proposal is actually somewhat *less* efficient than the current scheme, where I can do some checks on the cert BEFORE I fetch the CRL or ping the OCSP responder, and thus not even bother with revocation checking on things that have already failed. Al Arsenault Chief Security Architect Diversinet Corp. -----Original Message----- From: Irene Gassko [SMTP:gassko@lucent.com] Sent: Monday, August 07, 2000 10:20 AM To: Stephen Kent Cc: ietf-pkix@imc.org Subject: RE: OCSP request Steve, You are right and I know that currently signatures are mandatory. But making changes in order to solve serious problems is a part of the standards process, isn't it? A lot of discussion in this group is devoted to suggested improvements in the standard. If making signatures optional can help with CA key change and cert archiving, would not it be a good idea to allow such usage (as in MAY)? Irene At 05:55 PM 08/06/2000 -0400, Stephen Kent wrote: >Irene, > > > > >>The main idea is to eliminate signatures in certificates and have CA >>sign a Merkle tree of certificates instead. Then CA key compromise >>requires the change in that signature (which can be downloaded separately) >>but leaves cards and certificates unperturbed. You can use multiple >>signatures with different signature algorithms and keep keys on different >>continents if you wish. This scheme also helps with archiving. And you do not >>need a CRL. It can be used with X.509 certificates, making the signature >>on a certificate optional, rather than mandatory. Or you can make it >>an owner's signature instead of a CA's signature. > >Irrespective of the merit of the approach to which you allude, the >result would not be an X.509 cert. Signatures are mandatory, not >optional, in the format that is the basis of this WG's activity. > >Steve ------------------------------------------------------------------------ ---- ------------------------------------------------------- Irene Gassko Bell Laboratories http://www.lucent.com Lucent Technologies Secure Technologies Dept. 1600 Osgood Street phone: (978) 960-5767 Room 30-2-A31 e-mail: gassko@lucent.com N. Andover, MA 01845 fax: (978) 960-3240 From owner-ietf-pkix@imc.org Mon Aug 7 11:30:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21939 for ; Mon, 7 Aug 2000 11:30:51 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA25927; Mon, 7 Aug 2000 08:25:59 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 7 Aug 2000 08:25:52 -0700 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA25872 for ; Mon, 7 Aug 2000 08:25:51 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 07 Aug 2000 09:29:14 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 07 Aug 2000 09:29:09 -0600 From: "Bob Jueneman" To: , , Subject: RE: Digital Signatures - Legal Advice Wanted Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_D0886ADA.C6A7CC5D" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_D0886ADA.C6A7CC5D Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Anders, I am not an attorney (IANA), but I would suggest that Adrian has expressed a generally conservative view that would constitute good defensive legal practice, but may leave the impression that=20 without going through all of these steps, the transaction would presumably not be valid. But there is a different danger, and that is that transactions that=20 are digitally signed using a key that is apparently under the control=20 of the corporation or organization, might very well be held to be binding even without an explicit confirmation. In other words, I would suggest that Adrian's recommendations would almost certainly be sufficient, but they may not be necessary. Even though both the US and Australia are Common Law countries, there may be differences in the degree to which what Adrian refers to=20 as ostensible authority is accepted. My understanding is that in the US, the concept is fairly widely applied, in order to facilitate commerce. The closest analog I can think of to the corporate digital signature=20 is the mechanical signature plate that is used to sign corporate checks. Yes, because of the paper world precedents, the signature is a=20 facsimile of the treasurer's manual signature, and the words on the paper indicate that he is causing his signature to be affixed to that check as a agent of the corporation. But do you think that any recipient of such a check actually bothers to=20 verify that the signature really is that of the treasurer, or that the = treasurer has been authorized to sign checks by the Board of Directors? No way! In simple language, apply the duck test: If something looks like a duck, walks like a duck, and quacks like a duck, it probably is a duck. =20 In the case of a check, it was preprinted with the name of the corporation,= it was presumably tendered as a result of some consideration, debt, or other obligation (it didn't just fall out of the sky), and to all intents = and purposes it appears to be in order. Reliance on that treasurer's ostensible = authority would certainly be quite reasonable. (Note that there is no claim being = made that the check was a forgery, which would be a different matter.) So if I launch my browser to www.amazon.com, I see all sorts of stuff = appear=20 on my screen that would be consistent with the fact that I was connected = to=20 amazon, and the lock icon confirms that an SSL session has been established= with a server, on which a private key has apparently been installed that = corresponds to a public key certificate issued by a reputable CA (one whose root I = have accepted), then I have every right to believe that I am communicating with a server = that is=20 controlled by amazon. Granted, an SSL connection does not provide nonrepudiation for a particular= transaction. But supposing that I enter my credit card number or other personal = information over that session, and later I can establish that that information was not handled = properly. Could I sue amazon for not protecting my information adequately, and be = successful? Almost certainly, even without the www.amazon.com certificate. Certainly = no judge in the US would dismiss such a suite because I failed to provide satisfactory = evidence that the Board of Directors of amazon had in fact properly authorized the IT = department to=20 acquire a certificate, set up a server to conduct business, etc. In this case, it sure sounds like a duck. I suspect that your server-based organizational orders would fall into the = same situation. And in particular, once the first such transaction has been accepted = without complaint,=20 it is all downhill from there, since the commercial practice would then be = increasingly=20 well-established. Regards, Bob >>> Adrian McCullagh 08/06/00 03:00PM = >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Anders In the paper based environment a company does not have its own signature. Companies are artificial legal entities and as such can only act through human agents. (Now this may change through the use of software agents but that is another issue). Hence for a company to be bound to a commercial transaction the human agent must have some authority either implied or express.=20 A person digitally signing a digital document that attempts to bind a company should use their own private key for such action. The issue then revolves around the concept of authority. If the signer does not have the appropriate authority then the signer may be liable for "Breach of Warranty of Authority". If the signer has express authority to sign the document and thus bind the principal then the issue is simple. In Common law countries like the USA, Australia, UK and Canada, there is a doctrine known as ostensible authority. This provides that if a person signs a document on behalf of another legal entity (the principal) and the signer has some external reasonably perceived authority such that a reasonable person looking at the transaction objectively would believe that such person through his/her position had such authority to bind the principal then the principal is bound by the signers action. So as I see it, a director could digitally sign the digital document using the directors own personal private key and as part of the text of the document state the following word "signed for and on behalf of Company XXXX". This would indicate to the world that the signer is NOT signing the digital document so as to be personally bound but is signing as an agent and as such is attempting to bind the principal (company). The recipient would on receipt verify the digital signature using the signer's personal certificate that has the public key embodied in it.=20 If the recipient is concerned about the authority then the recipient can check the company records to determine if the signer has the necessary implied/ostensible authority. To accelerate the process of verification of authority there may be some solution in the use of role based certificates or attribute certificates but I have not really give this issue sufficient thought. If there is still some doubt then the recipient can always check with the Company secretary or the Managing director as to such authority. The Uniform Electronic Transactions Act that is forming part of the Uniform Commercial Code of various US States does anticipate software agents and thus server based organisation digital signatures. But there are no cases that specifically deal with your issue. The simple solution is for a company officer to digitally sign the digital document and affix the words noted above in the text prior to digitally signing. I hope this is helpful. Adrian McCullagh Director of Electronic CommerceTel: 617 3231 1522 Gadens Lawyers Fax: 617 3229 5850 =20 level 39 Central Plaza 1 345 Queen Street Brisbane Australia 4000 Ph. D. Candidate Thesis "The Incorporation of Trust Strategies in Digital Signature Regimes for Elec. Comm." Information Security Research Centre Queensland University of Technology - -----Original Message----- From: Anders Rundgren [ mailto:anders.rundgren@telia.com] Sent: Monday, August 07, 2000 6:58 AM To: PKIX-List Subject: Digital Signatures - Legal Advice Wanted Hi, I am working with an e-commerce standard that features server-based, organization-signed orders. However, server-based, organization-oriented digital signatures do currently not, to the my knowledge, have explicit support in any legal system. How to solve this? One way (the current one) is to state in separate agreements between the trading partners, that you will stand by these signatures in court. I wonder if there could be a more general solution like: A company officer digitally signs (using a personal certificate), a document where he/she states that signatures associated with a certain trading partner certificate are to be considered as legally binding from the company's point of view. Such a document is preferably published on the company's home-page for easy reference. How does this sound in the ears of lawyers? regards Anders Rundgren -----BEGIN PGP SIGNATURE----- Version: PGP Personal Edition 6.0.2 iQA/AwUBOY1FTJWt1NGjt4vzEQLdmACeJiR1FMKZ//6Mtfq+v5DfAGGo/q4AoJoM bWjrz+F/Xll2zwotTzuligVm =3DsEx7 -----END PGP SIGNATURE----- --=_D0886ADA.C6A7CC5D Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Anders,
 
I am not an attorney (IANA), but I would suggest = that=20 Adrian
has expressed a generally conservative view that = would=20 constitute
good defensive legal practice, but may leave the = impression=20 that
without going through all of these steps, the = transaction=20 would
presumably  not be=20 valid.
 
But there is a different danger, and that is that = transactions=20 that
are digitally signed using a key that is apparently = under the=20 control
of the corporation or organization, might very well be = held to=20 be binding
even without an explicit confirmation.
 
In other words, I would suggest that Adrian's=20 recommendations
would almost certainly be sufficient, but they may not = be=20 necessary.
 
Even though both the US and Australia are Common = Law=20 countries,
there may be differences in the degree to which what = Adrian=20 refers to
as ostensible authority is accepted.  My = understanding is=20 that in the US,
the concept is fairly widely applied, in order to = facilitate=20 commerce.
 
The closest analog I can think of to the corporate = digital=20 signature
is the mechanical signature plate that is used to = sign=20 corporate checks.
Yes, because of the paper world precedents, the = signature is a=20
facsimile of the treasurer's manual signature, and the = words=20 on the paper
indicate that he is causing his signature to be = affixed to=20 that check
as a agent of the corporation.
 
But do you think that any recipient of such a check = actually=20 bothers to
verify that the signature really is that of the = treasurer, or=20 that the treasurer
has been authorized to sign checks by the Board of=20 Directors?  No way!
 
In simple language, apply the duck test:
 
If something looks like a duck, walks like a duck, and = quacks=20 like a duck,
it probably is a duck. 
 
In the case of a check, it was preprinted with the = name of the=20 corporation,
it was presumably tendered as a result of some = consideration,=20 debt, or
other obligation (it didn't just fall out of the sky), = and to=20 all intents and purposes
it appears to be in order.  Reliance on that = treasurer's=20 ostensible authority
would certainly be quite reasonable.  (Note that = there is=20 no claim being made that
the check was a forgery, which would be a different=20 matter.)
 
So if I launch my browser to www.amazon.com, I see all sorts of = stuff appear=20
on my screen that would be consistent with the fact = that I was=20 connected to
amazon, and the lock icon confirms that an SSL session = has=20 been established
with a server, on which a private key has apparently = been=20 installed that corresponds
to a public key certificate issued by a reputable CA = (one=20 whose root I have accepted),
then I have every right to believe that I am communicat= ing=20 with a server that is
controlled by amazon.
 
Granted, an SSL connection does not provide nonrepudiat= ion for=20 a particular transaction.
But supposing that I enter my credit card number or = other=20 personal information over that
session, and later I can establish that that informatio= n was=20 not handled properly.
 
Could I sue amazon for not protecting my information=20= adequately, and be successful?
Almost certainly, even without the www.amazon.com certificate.  = Certainly no=20 judge in the
US would dismiss such a suite because I failed to = provide=20 satisfactory evidence that
the Board of Directors of am= azon had=20 in fact properly authorized the IT department to
acquire a certificate, set up a server to conduct = business,=20 etc.
 
In this case, it sure sounds like a duck.
 
I suspect that your server-based organizational orders = would=20 fall into the same situation.
And in particular, once the first such transaction has = been=20 accepted without complaint,
it is all downhill from there, since the commercial = practice=20 would then be increasingly
well-established.
 
Regards,
 
Bob
 

>>> Adrian McCullagh <AMcCullagh@exchange.gadens.com.a= u>=20 08/06/00 03:00PM >>>
-----BEGIN PGP SIGNED MESSAGE-----
Hash= :=20 SHA1

Dear Anders

In the paper based environment a company = does not=20 have its own
signature.  Companies are artificial legal entities = and as=20 such can
only act through human agents. (Now this may change through = the use=20 of
software agents but that is another issue).  Hence for a = company to=20 be
bound to a commercial transaction the human agent must have=20 some
authority either implied or express.

A person digitally = signing=20 a digital document that attempts to bind a
company should use their = own=20 private key for such action.  The issue
then revolves around the = concept=20 of authority.  If the signer does not
have the appropriate = authority=20 then the signer may be liable for
"Breach of Warranty of Authority".&nbs= p; If=20 the signer has express
authority to sign the document and thus bind = the=20 principal then the
issue is simple.

In Common law countries like = the=20 USA, Australia, UK and Canada, there
is a doctrine known as ostensible= =20 authority.  This provides that if a
person signs a document on = behalf of=20 another legal entity (the
principal) and the signer has some external=20= reasonably perceived
authority such that a reasonable person looking at = the=20 transaction
objectively would believe that such person through = his/her=20 position
had such authority to bind the principal then the principal = is=20 bound
by the signers action.

So as I see it, a director could=20 digitally sign the digital document
using the directors own personal = private=20 key and as part of the text
of the document state the following word = "signed=20 for and on behalf of
Company XXXX".  This would indicate to the = world=20 that the signer is
NOT signing the digital document so as to be = personally=20 bound but is
signing as an agent and as such is attempting to bind = the=20 principal
(company).

The recipient would on receipt verify the = digital=20 signature using the
signer's personal certificate that has the public = key=20 embodied in it.
If the recipient is concerned about the authority then = the=20 recipient
can check the company records to determine if the signer = has=20 the
necessary implied/ostensible authority.   To accelerate = the=20 process of
verification of authority there may be some solution in the = use=20 of
role based certificates or attribute certificates but I have = not
really=20 give this issue sufficient thought.

If there is still some doubt = then the=20 recipient can always check with
the Company secretary or the Managing=20= director as to such authority.

The Uniform Electronic Transactions = Act=20 that is forming part of the
Uniform Commercial Code of various US = States does=20 anticipate software
agents and thus server based organisation digital=20= signatures.

But there are no cases that specifically deal with = your=20 issue.

The simple solution is for a company officer to digitally = sign=20 the
digital document and affix the words noted above in the text = prior=20 to
digitally signing.

I hope this is helpful.


Adrian= =20 McCullagh
Director of Electronic CommerceTel: 617 3231 1522
Gadens=20= Lawyers           &n= bsp;         =20 Fax: 617 3229 5850    
level 39
Central = Plaza=20 1
345 Queen Street
Brisbane Australia 4000

Ph. D.=20 Candidate
Thesis "The Incorporation of Trust Strategies in Digital=20 Signature
Regimes for Elec. Comm."
Information Security Research=20 Centre
Queensland University of Technology



- -----Origina= l=20 Message-----
From: Anders Rundgren [ mailto:anders.rundgren@telia.com= ]
Sent:=20 Monday, August 07, 2000 6:58 AM
To: PKIX-List
Subject: Digital = Signatures=20 - Legal Advice Wanted


Hi,
I am working with an e-commerce = standard=20 that features server-based,
organization-signed orders.

However,= =20 server-based, organization-oriented digital signatures do
currently = not, to=20 the my knowledge,
have explicit support in any legal system.  How = to=20 solve this?  One
way (the current one) is to state
in = separate=20 agreements between the trading partners, that you will
stand by = these=20 signatures in court.

I wonder if there could be a more general = solution=20 like: A company
officer digitally signs (using a personal
certificate= ), a=20 document where he/she states that signatures
associated with a = certain=20 trading partner
certificate are to be considered as legally binding = from the=20 company's
point of view.
Such a document is preferably published on = the=20 company's home-page for
easy reference.

How does this sound in = the=20 ears of lawyers?

regards
Anders Rundgren



-----BEGI= N PGP=20 SIGNATURE-----
Version: PGP Personal Edition=20 6.0.2

iQA/AwUBOY1FTJWt1NGjt4vzEQLdmACeJiR1FMKZ//6Mtfq+v5DfAGGo/q4AoJ= oM
bWjrz+F/Xll2zwotTzuligVm
=3DsEx7
-----END=20 PGP SIGNATURE-----
--=_D0886ADA.C6A7CC5D-- From owner-ietf-pkix@imc.org Mon Aug 7 14:18:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00224 for ; Mon, 7 Aug 2000 14:18:05 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA00490; Mon, 7 Aug 2000 11:13:15 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 7 Aug 2000 11:13:04 -0700 Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00458 for ; Mon, 7 Aug 2000 11:13:02 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA15399; Mon, 7 Aug 2000 11:12:15 -0700 (PDT) Message-Id: <4.2.2.20000807111002.00a8a740@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 07 Aug 2000 11:20:42 -0700 To: Adrian McCullagh , "'Anders Rundgren'" , PKIX-List From: Tony Bartoletti Subject: RE: Digital Signatures - Legal Advice Wanted In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 07:00 AM 8/7/00 +1000, Adrian McCullagh wrote: >In Common law countries like the USA, Australia, UK and Canada, there >is a doctrine known as ostensible authority. This provides that if a >person signs a document on behalf of another legal entity (the >principal) and the signer has some external reasonably perceived >authority such that a reasonable person looking at the transaction >objectively would believe that such person through his/her position >had such authority to bind the principal then the principal is bound >by the signers action. > >So as I see it, a director could digitally sign the digital document >using the directors own personal private key and as part of the text >of the document state the following word "signed for and on behalf of >Company XXXX". This would indicate to the world that the signer is >NOT signing the digital document so as to be personally bound but is >signing as an agent and as such is attempting to bind the principal >(company). (Please correct me, Anders, if I am mistaken, but) I believe the issue is a little different than Adrian supposes. Rather than have a (company) individual sign on behalf of "the company", I believe that the issue is whether a company (ok, an individual acting on behalf of the company if you must) can hold "customer's keys" and apply "customer's signatures", given some trail of evidence that the customer, on a case-by- case basis, has authorized that their signature be affixed to a given transaction. The primary goal being to keep the customer's "secret keys" in an environment more secure than the customer may be expected to maintain. (The legal precedent for this might be "power of attorney"?) If I'm wrong ... nevermind :) ___tony___ >The recipient would on receipt verify the digital signature using the >signer's personal certificate that has the public key embodied in it. >If the recipient is concerned about the authority then the recipient >can check the company records to determine if the signer has the >necessary implied/ostensible authority. To accelerate the process of >verification of authority there may be some solution in the use of >role based certificates or attribute certificates but I have not >really give this issue sufficient thought. > >If there is still some doubt then the recipient can always check with >the Company secretary or the Managing director as to such authority. > >The Uniform Electronic Transactions Act that is forming part of the >Uniform Commercial Code of various US States does anticipate software >agents and thus server based organisation digital signatures. > >But there are no cases that specifically deal with your issue. > >The simple solution is for a company officer to digitally sign the >digital document and affix the words noted above in the text prior to >digitally signing. > >I hope this is helpful. > > >Adrian McCullagh >Director of Electronic CommerceTel: 617 3231 1522 >Gadens Lawyers Fax: 617 3229 5850 >level 39 >Central Plaza 1 >345 Queen Street >Brisbane Australia 4000 > >Ph. D. Candidate >Thesis "The Incorporation of Trust Strategies in Digital Signature >Regimes for Elec. Comm." >Information Security Research Centre >Queensland University of Technology > > > >- -----Original Message----- >From: Anders Rundgren [ mailto:anders.rundgren@telia.com] >Sent: Monday, August 07, 2000 6:58 AM >To: PKIX-List >Subject: Digital Signatures - Legal Advice Wanted > > >Hi, >I am working with an e-commerce standard that features server-based, >organization-signed orders. > >However, server-based, organization-oriented digital signatures do >currently not, to the my knowledge, >have explicit support in any legal system. How to solve this? One >way (the current one) is to state >in separate agreements between the trading partners, that you will >stand by these signatures in court. > >I wonder if there could be a more general solution like: A company >officer digitally signs (using a personal >certificate), a document where he/she states that signatures >associated with a certain trading partner >certificate are to be considered as legally binding from the company's >point of view. >Such a document is preferably published on the company's home-page for >easy reference. > >How does this sound in the ears of lawyers? > >regards >Anders Rundgren > > > >-----BEGIN PGP SIGNATURE----- >Version: PGP Personal Edition 6.0.2 > >iQA/AwUBOY1FTJWt1NGjt4vzEQLdmACeJiR1FMKZ//6Mtfq+v5DfAGGo/q4AoJoM >bWjrz+F/Xll2zwotTzuligVm >=sEx7 >-----END PGP SIGNATURE----- Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 From owner-ietf-pkix@imc.org Mon Aug 7 14:50:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20446 for ; Mon, 7 Aug 2000 14:50:24 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA01619; Mon, 7 Aug 2000 11:45:27 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 7 Aug 2000 11:45:24 -0700 Received: from Newman.GSC.GTE.Com (SYSTEM@NS0.GDGSC.Com [192.160.62.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01589 for ; Mon, 7 Aug 2000 11:45:23 -0700 (PDT) Received: from gscex01.gsc.gte.com ("port 4418"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #38015) with SMTP id <01JSOXRFXJBI002RP8@Newman.GSC.GTE.Com> for ietf-pkix@imc.org; Mon, 7 Aug 2000 14:49:26 -0400 (EDT) Received: from 127.0.0.1 by gscex01.gsc.gte.com (InterScan E-Mail VirusWall NT) ; Mon, 07 Aug 2000 14:46:05 -0400 (Eastern Daylight Time) Received: by GSCEX01.gsc.gte.com with Internet Mail Service (5.5.2650.21) id ; Mon, 07 Aug 2000 14:43:32 -0400 Date: Mon, 07 Aug 2000 14:43:26 -0400 From: "Heimberg, Jim" Subject: RE: Digital Signatures - Legal Advice Wanted To: "'Tony Bartoletti'" , Adrian McCullagh , "'Anders Rundgren'" , PKIX-List Message-id: <2575327B6755D211A0E100805F9FF954050805C4@ndhmex02.ndhm.gsc.gte.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="ISO-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Just to add to the confusion, is there no allowance for designating the personality as the role that person fills? For instance, if you wanted as a CA to grant a signature and encryption key and the requisite authority to the Chief Financial Officer of a small company (e.g., Acme Electrical Supply) for purchasing as required, why can you not issue a certificate to cfo@acmeelectric.com (and if you need to personalize it, you could add the person's name or initials after the CFO designation)? -----Original Message----- From: Tony Bartoletti [mailto:azb@llnl.gov] Sent: Monday, August 07, 2000 2:21 PM To: Adrian McCullagh; 'Anders Rundgren'; PKIX-List Subject: RE: Digital Signatures - Legal Advice Wanted At 07:00 AM 8/7/00 +1000, Adrian McCullagh wrote: >In Common law countries like the USA, Australia, UK and Canada, there >is a doctrine known as ostensible authority. This provides that if a >person signs a document on behalf of another legal entity (the >principal) and the signer has some external reasonably perceived >authority such that a reasonable person looking at the transaction >objectively would believe that such person through his/her position >had such authority to bind the principal then the principal is bound >by the signers action. > >So as I see it, a director could digitally sign the digital document >using the directors own personal private key and as part of the text >of the document state the following word "signed for and on behalf of >Company XXXX". This would indicate to the world that the signer is >NOT signing the digital document so as to be personally bound but is >signing as an agent and as such is attempting to bind the principal >(company). (Please correct me, Anders, if I am mistaken, but) I believe the issue is a little different than Adrian supposes. Rather than have a (company) individual sign on behalf of "the company", I believe that the issue is whether a company (ok, an individual acting on behalf of the company if you must) can hold "customer's keys" and apply "customer's signatures", given some trail of evidence that the customer, on a case-by- case basis, has authorized that their signature be affixed to a given transaction. The primary goal being to keep the customer's "secret keys" in an environment more secure than the customer may be expected to maintain. (The legal precedent for this might be "power of attorney"?) If I'm wrong ... nevermind :) ___tony___ >The recipient would on receipt verify the digital signature using the >signer's personal certificate that has the public key embodied in it. >If the recipient is concerned about the authority then the recipient >can check the company records to determine if the signer has the >necessary implied/ostensible authority. To accelerate the process of >verification of authority there may be some solution in the use of >role based certificates or attribute certificates but I have not >really give this issue sufficient thought. > >If there is still some doubt then the recipient can always check with >the Company secretary or the Managing director as to such authority. > >The Uniform Electronic Transactions Act that is forming part of the >Uniform Commercial Code of various US States does anticipate software >agents and thus server based organisation digital signatures. > >But there are no cases that specifically deal with your issue. > >The simple solution is for a company officer to digitally sign the >digital document and affix the words noted above in the text prior to >digitally signing. > >I hope this is helpful. > > >Adrian McCullagh >Director of Electronic CommerceTel: 617 3231 1522 >Gadens Lawyers Fax: 617 3229 5850 >level 39 >Central Plaza 1 >345 Queen Street >Brisbane Australia 4000 > >Ph. D. Candidate >Thesis "The Incorporation of Trust Strategies in Digital Signature >Regimes for Elec. Comm." >Information Security Research Centre >Queensland University of Technology > > > >- -----Original Message----- >From: Anders Rundgren [ mailto:anders.rundgren@telia.com] >Sent: Monday, August 07, 2000 6:58 AM >To: PKIX-List >Subject: Digital Signatures - Legal Advice Wanted > > >Hi, >I am working with an e-commerce standard that features server-based, >organization-signed orders. > >However, server-based, organization-oriented digital signatures do >currently not, to the my knowledge, >have explicit support in any legal system. How to solve this? One >way (the current one) is to state >in separate agreements between the trading partners, that you will >stand by these signatures in court. > >I wonder if there could be a more general solution like: A company >officer digitally signs (using a personal >certificate), a document where he/she states that signatures >associated with a certain trading partner >certificate are to be considered as legally binding from the company's >point of view. >Such a document is preferably published on the company's home-page for >easy reference. > >How does this sound in the ears of lawyers? > >regards >Anders Rundgren > > > >-----BEGIN PGP SIGNATURE----- >Version: PGP Personal Edition 6.0.2 > >iQA/AwUBOY1FTJWt1NGjt4vzEQLdmACeJiR1FMKZ//6Mtfq+v5DfAGGo/q4AoJoM >bWjrz+F/Xll2zwotTzuligVm >=sEx7 >-----END PGP SIGNATURE----- Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 From owner-ietf-pkix@imc.org Mon Aug 7 15:39:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20960 for ; Mon, 7 Aug 2000 15:39:27 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA02633; Mon, 7 Aug 2000 12:34:52 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 7 Aug 2000 12:34:45 -0700 Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02603 for ; Mon, 7 Aug 2000 12:34:44 -0700 (PDT) Received: from mega (t2o69p5.telia.com [62.20.144.125]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id VAA26450; Mon, 7 Aug 2000 21:38:47 +0200 (CEST) Message-ID: <001901c000af$5a84e6f0$0201a8c0@mega.vincent.se> From: "Anders Rundgren" To: "'Tony Bartoletti'" , "PKIX-List" Subject: Re: Digital Signatures - Legal Advice Wanted Date: Mon, 7 Aug 2000 22:37:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA02604 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Tony, >The primary goal being to keep the customer's "secret keys" >in an environment more secure than the customer may be expected >to maintain. More or less. Actually all authorized intranet users could then indirectly use the "company cert/key" for things like orders and payments. This simplifies CA trust-issues considerably as company certs (unlike "employee/role/attribute" certs) are suitable for TTP issuing which IMO is required for global e-commerce. Anders From owner-ietf-pkix@imc.org Mon Aug 7 15:44:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23555 for ; Mon, 7 Aug 2000 15:44:34 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA02942; Mon, 7 Aug 2000 12:39:56 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 7 Aug 2000 12:39:55 -0700 Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02912 for ; Mon, 7 Aug 2000 12:39:53 -0700 (PDT) Received: from mega (t4o69p96.telia.com [62.20.145.216]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id VAA00695; Mon, 7 Aug 2000 21:43:59 +0200 (CEST) Message-ID: <002801c000b0$13f8a400$0201a8c0@mega.vincent.se> From: "Anders Rundgren" To: "Bob Jueneman" , Subject: Re: Digital Signatures - Legal Advice Wanted Date: Mon, 7 Aug 2000 22:43:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA02913 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Bob, >I suspect that your server-based organizational orders would fall into the same situation. >And in particular, once the first such transaction has been accepted without complaint, >it is all downhill from there, since the commercial practice would then be increasingly >well-established. To me this is not downhill, this is just great and I believe that you are completely correct in your pragmatic view on how things actually work! In spite of signature laws... Regards Anders From owner-ietf-pkix@imc.org Mon Aug 7 16:22:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12485 for ; Mon, 7 Aug 2000 16:22:39 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA03902; Mon, 7 Aug 2000 13:17:45 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 7 Aug 2000 13:17:05 -0700 Received: from hamster.gadens.com.au (root@dns.gadens.com.au [203.32.220.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03803 for ; Mon, 7 Aug 2000 13:16:44 -0700 (PDT) Received: from exchange.gadens.com.au ([10.1.8.3]) by hamster.gadens.com.au (8.9.3/8.9.3) with ESMTP id GAA21075; Tue, 8 Aug 2000 06:20:40 +1000 (EST) (envelope-from AMcCullagh@exchange.gadens.com.au) Received: by exchange.gadens.com.au with Internet Mail Service (5.5.2650.21) id <3YWS6818>; Tue, 8 Aug 2000 06:24:54 +1000 Message-ID: From: Adrian McCullagh To: "'Bob Jueneman'" , ietf-pkix@imc.org, anders.rundgren@telia.com Subject: RE: Digital Signatures - Legal Advice Wanted Date: Tue, 8 Aug 2000 06:24:50 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear All I agree with Bob's analysis. For a non lawyer Bob usually hits the legal target with accurate precision. My previous comments were generally conservative but as I am lawyer practising in this area I view things with from the position of: - "what can go wrong in a legal sense". I agree with Bob that through a course of trade such communications will certainly have a strong evidential bearing upon any case and thus the issues may be "downhill" from there. But one transaction without complaint may not be sufficient. It may take a number of transactions without complaint before a course of trade can be established. If the transaction is not insubstantial then my conservative approach is from a risk management point of view probably the safest position to take. Adrian McCullagh Director of Electronic CommerceTel: 617 3231 1522 Gadens Lawyers Fax: 617 3229 5850 level 39 Central Plaza 1 345 Queen Street Brisbane Australia 4000 Ph. D. Candidate Thesis "The Incorporation of Trust Strategies in Digital Signature Regimes for Elec. Comm." Information Security Research Centre Queensland University of Technology - -----Original Message----- From: Bob Jueneman [mailto:bjueneman@novell.com] Sent: Tuesday, August 08, 2000 1:29 AM To: AMcCullagh@exchange.gadens.com.au; ietf-pkix@imc.org; anders.rundgren@telia.com Subject: RE: Digital Signatures - Legal Advice Wanted Anders, I am not an attorney (IANA), but I would suggest that Adrian has expressed a generally conservative view that would constitute good defensive legal practice, but may leave the impression that without going through all of these steps, the transaction would presumably not be valid. But there is a different danger, and that is that transactions that are digitally signed using a key that is apparently under the control of the corporation or organization, might very well be held to be binding even without an explicit confirmation. In other words, I would suggest that Adrian's recommendations would almost certainly be sufficient, but they may not be necessary. Even though both the US and Australia are Common Law countries, there may be differences in the degree to which what Adrian refers to as ostensible authority is accepted. My understanding is that in the US, the concept is fairly widely applied, in order to facilitate commerce. The closest analog I can think of to the corporate digital signature is the mechanical signature plate that is used to sign corporate checks. Yes, because of the paper world precedents, the signature is a facsimile of the treasurer's manual signature, and the words on the paper indicate that he is causing his signature to be affixed to that check as a agent of the corporation. But do you think that any recipient of such a check actually bothers to verify that the signature really is that of the treasurer, or that the treasurer has been authorized to sign checks by the Board of Directors? No way! In simple language, apply the duck test: If something looks like a duck, walks like a duck, and quacks like a duck, it probably is a duck. In the case of a check, it was preprinted with the name of the corporation, it was presumably tendered as a result of some consideration, debt, or other obligation (it didn't just fall out of the sky), and to all intents and purposes it appears to be in order. Reliance on that treasurer's ostensible authority would certainly be quite reasonable. (Note that there is no claim being made that the check was a forgery, which would be a different matter.) So if I launch my browser to www.amazon.com, I see all sorts of stuff appear on my screen that would be consistent with the fact that I was connected to amazon, and the lock icon confirms that an SSL session has been established with a server, on which a private key has apparently been installed that corresponds to a public key certificate issued by a reputable CA (one whose root I have accepted), then I have every right to believe that I am communicating with a server that is controlled by amazon. Granted, an SSL connection does not provide nonrepudiation for a particular transaction. But supposing that I enter my credit card number or other personal information over that session, and later I can establish that that information was not handled properly. Could I sue amazon for not protecting my information adequately, and be successful? Almost certainly, even without the www.amazon.com certificate. Certainly no judge in the US would dismiss such a suite because I failed to provide satisfactory evidence that the Board of Directors of amazon had in fact properly authorized the IT department to acquire a certificate, set up a server to conduct business, etc. In this case, it sure sounds like a duck. I suspect that your server-based organizational orders would fall into the same situation. And in particular, once the first such transaction has been accepted without complaint, it is all downhill from there, since the commercial practice would then be increasingly well-established. Regards, Bob >>> Adrian McCullagh 08/06/00 03:00PM >>> - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Anders In the paper based environment a company does not have its own signature. Companies are artificial legal entities and as such can only act through human agents. (Now this may change through the use of software agents but that is another issue). Hence for a company to be bound to a commercial transaction the human agent must have some authority either implied or express. A person digitally signing a digital document that attempts to bind a company should use their own private key for such action. The issue then revolves around the concept of authority. If the signer does not have the appropriate authority then the signer may be liable for "Breach of Warranty of Authority". If the signer has express authority to sign the document and thus bind the principal then the issue is simple. In Common law countries like the USA, Australia, UK and Canada, there is a doctrine known as ostensible authority. This provides that if a person signs a document on behalf of another legal entity (the principal) and the signer has some external reasonably perceived authority such that a reasonable person looking at the transaction objectively would believe that such person through his/her position had such authority to bind the principal then the principal is bound by the signers action. So as I see it, a director could digitally sign the digital document using the directors own personal private key and as part of the text of the document state the following word "signed for and on behalf of Company XXXX". This would indicate to the world that the signer is NOT signing the digital document so as to be personally bound but is signing as an agent and as such is attempting to bind the principal (company). The recipient would on receipt verify the digital signature using the signer's personal certificate that has the public key embodied in it. If the recipient is concerned about the authority then the recipient can check the company records to determine if the signer has the necessary implied/ostensible authority. To accelerate the process of verification of authority there may be some solution in the use of role based certificates or attribute certificates but I have not really give this issue sufficient thought. If there is still some doubt then the recipient can always check with the Company secretary or the Managing director as to such authority. The Uniform Electronic Transactions Act that is forming part of the Uniform Commercial Code of various US States does anticipate software agents and thus server based organisation digital signatures. But there are no cases that specifically deal with your issue. The simple solution is for a company officer to digitally sign the digital document and affix the words noted above in the text prior to digitally signing. I hope this is helpful. Adrian McCullagh Director of Electronic CommerceTel: 617 3231 1522 Gadens Lawyers Fax: 617 3229 5850 level 39 Central Plaza 1 345 Queen Street Brisbane Australia 4000 Ph. D. Candidate Thesis "The Incorporation of Trust Strategies in Digital Signature Regimes for Elec. Comm." Information Security Research Centre Queensland University of Technology - - -----Original Message----- From: Anders Rundgren [ mailto:anders.rundgren@telia.com] Sent: Monday, August 07, 2000 6:58 AM To: PKIX-List Subject: Digital Signatures - Legal Advice Wanted Hi, I am working with an e-commerce standard that features server-based, organization-signed orders. However, server-based, organization-oriented digital signatures do currently not, to the my knowledge, have explicit support in any legal system. How to solve this? One way (the current one) is to state in separate agreements between the trading partners, that you will stand by these signatures in court. I wonder if there could be a more general solution like: A company officer digitally signs (using a personal certificate), a document where he/she states that signatures associated with a certain trading partner certificate are to be considered as legally binding from the company's point of view. Such a document is preferably published on the company's home-page for easy reference. How does this sound in the ears of lawyers? regards Anders Rundgren - -----BEGIN PGP SIGNATURE----- Version: PGP Personal Edition 6.0.2 iQA/AwUBOY1FTJWt1NGjt4vzEQLdmACeJiR1FMKZ//6Mtfq+v5DfAGGo/q4AoJoM bWjrz+F/Xll2zwotTzuligVm =sEx7 - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: PGP Personal Edition 6.0.2 iQA/AwUBOY6Oc5Wt1NGjt4vzEQIjpgCfZQpuuUxCJZwQbXJ0qxTBiV78qBkAoLpy ZH9cgCYkemF3Ca4D4nYjLNMF =XCG7 -----END PGP SIGNATURE----- From owner-ietf-pkix@imc.org Mon Aug 7 16:37:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20131 for ; Mon, 7 Aug 2000 16:37:46 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA04689; Mon, 7 Aug 2000 13:33:06 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 7 Aug 2000 13:33:04 -0700 Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA04659 for ; Mon, 7 Aug 2000 13:33:03 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id NAA07790; Mon, 7 Aug 2000 13:36:35 -0700 (PDT) Message-Id: <4.2.2.20000807134117.00aea580@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 07 Aug 2000 13:45:01 -0700 To: "Anders Rundgren" , "Bob Jueneman" , From: Tony Bartoletti Subject: Re: Digital Signatures - Legal Advice Wanted In-Reply-To: <002801c000b0$13f8a400$0201a8c0@mega.vincent.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 10:43 PM 8/7/00 +0200, you wrote: >Bob, > > > >I suspect that your server-based organizational orders would fall into > the same situation. > >And in particular, once the first such transaction has been accepted > without complaint, > >it is all downhill from there, since the commercial practice would then > be increasingly > >well-established. > >To me this is not downhill, this is just great and I believe that you are >completely correct in your >pragmatic view on how things actually work! In spite of signature laws... :) I think Bob used "downhill" in the sense of "easy" rather than "retrograde". The term can be used in both positive and negative ways... ___tony___ Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 From owner-ietf-pkix@imc.org Mon Aug 7 17:17:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09843 for ; Mon, 7 Aug 2000 17:17:36 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA05515; Mon, 7 Aug 2000 14:13:00 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 7 Aug 2000 14:12:51 -0700 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA05479 for ; Mon, 7 Aug 2000 14:12:43 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 07 Aug 2000 15:16:17 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 07 Aug 2000 15:16:12 -0600 From: "Bob Jueneman" To: , , Subject: RE: Digital Signatures - Legal Advice Wanted Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA05483 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit And I completely agree with Adrian's comments, at least from the perspective of what I would do if I wanted to be sure that a given transaction WOULD be binding. But as an attorney once told me when I proposed using PKI some 7 or 8 years ago, "I only have two concerns with respect to this new technology. The first is that it won't be binding when I want it to be. And the second is that it will be binding when I don't want it to be!" So if you want to be sure that a signed transaction will almost surely be binding, do what Adrian suggests. On the other hand, if you are concerned that one of your employees might set up a server, create or go get a certificate, and start signing code or who knows what, and that his actions MIGHT be held to be binding against your company without your CFO or General Counsel even being aware of an obligation, then you might well have reason to worry, and you might want take positive steps to bring that situation under control. Murphy's law hasn't been repealed, and the one time that something will be found to be binding is when you least want it to be! Bob >>> Adrian McCullagh 08/07/00 02:24PM >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear All I agree with Bob's analysis. For a non lawyer Bob usually hits the legal target with accurate precision. My previous comments were generally conservative but as I am lawyer practising in this area I view things with from the position of: - "what can go wrong in a legal sense". I agree with Bob that through a course of trade such communications will certainly have a strong evidential bearing upon any case and thus the issues may be "downhill" from there. But one transaction without complaint may not be sufficient. It may take a number of transactions without complaint before a course of trade can be established. If the transaction is not insubstantial then my conservative approach is from a risk management point of view probably the safest position to take. Adrian McCullagh Director of Electronic CommerceTel: 617 3231 1522 Gadens Lawyers Fax: 617 3229 5850 level 39 Central Plaza 1 345 Queen Street Brisbane Australia 4000 Ph. D. Candidate Thesis "The Incorporation of Trust Strategies in Digital Signature Regimes for Elec. Comm." Information Security Research Centre Queensland University of Technology - -----Original Message----- From: Bob Jueneman [mailto:bjueneman@novell.com] Sent: Tuesday, August 08, 2000 1:29 AM To: AMcCullagh@exchange.gadens.com.au; ietf-pkix@imc.org; anders.rundgren@telia.com Subject: RE: Digital Signatures - Legal Advice Wanted Anders, I am not an attorney (IANA), but I would suggest that Adrian has expressed a generally conservative view that would constitute good defensive legal practice, but may leave the impression that without going through all of these steps, the transaction would presumably not be valid. But there is a different danger, and that is that transactions that are digitally signed using a key that is apparently under the control of the corporation or organization, might very well be held to be binding even without an explicit confirmation. In other words, I would suggest that Adrian's recommendations would almost certainly be sufficient, but they may not be necessary. Even though both the US and Australia are Common Law countries, there may be differences in the degree to which what Adrian refers to as ostensible authority is accepted. My understanding is that in the US, the concept is fairly widely applied, in order to facilitate commerce. The closest analog I can think of to the corporate digital signature is the mechanical signature plate that is used to sign corporate checks. Yes, because of the paper world precedents, the signature is a facsimile of the treasurer's manual signature, and the words on the paper indicate that he is causing his signature to be affixed to that check as a agent of the corporation. But do you think that any recipient of such a check actually bothers to verify that the signature really is that of the treasurer, or that the treasurer has been authorized to sign checks by the Board of Directors? No way! In simple language, apply the duck test: If something looks like a duck, walks like a duck, and quacks like a duck, it probably is a duck. In the case of a check, it was preprinted with the name of the corporation, it was presumably tendered as a result of some consideration, debt, or other obligation (it didn't just fall out of the sky), and to all intents and purposes it appears to be in order. Reliance on that treasurer's ostensible authority would certainly be quite reasonable. (Note that there is no claim being made that the check was a forgery, which would be a different matter.) So if I launch my browser to www.amazon.com, I see all sorts of stuff appear on my screen that would be consistent with the fact that I was connected to amazon, and the lock icon confirms that an SSL session has been established with a server, on which a private key has apparently been installed that corresponds to a public key certificate issued by a reputable CA (one whose root I have accepted), then I have every right to believe that I am communicating with a server that is controlled by amazon. Granted, an SSL connection does not provide nonrepudiation for a particular transaction. But supposing that I enter my credit card number or other personal information over that session, and later I can establish that that information was not handled properly. Could I sue amazon for not protecting my information adequately, and be successful? Almost certainly, even without the www.amazon.com certificate. Certainly no judge in the US would dismiss such a suite because I failed to provide satisfactory evidence that the Board of Directors of amazon had in fact properly authorized the IT department to acquire a certificate, set up a server to conduct business, etc. In this case, it sure sounds like a duck. I suspect that your server-based organizational orders would fall into the same situation. And in particular, once the first such transaction has been accepted without complaint, it is all downhill from there, since the commercial practice would then be increasingly well-established. Regards, Bob >>> Adrian McCullagh 08/06/00 03:00PM >>> - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Anders In the paper based environment a company does not have its own signature. Companies are artificial legal entities and as such can only act through human agents. (Now this may change through the use of software agents but that is another issue). Hence for a company to be bound to a commercial transaction the human agent must have some authority either implied or express. A person digitally signing a digital document that attempts to bind a company should use their own private key for such action. The issue then revolves around the concept of authority. If the signer does not have the appropriate authority then the signer may be liable for "Breach of Warranty of Authority". If the signer has express authority to sign the document and thus bind the principal then the issue is simple. In Common law countries like the USA, Australia, UK and Canada, there is a doctrine known as ostensible authority. This provides that if a person signs a document on behalf of another legal entity (the principal) and the signer has some external reasonably perceived authority such that a reasonable person looking at the transaction objectively would believe that such person through his/her position had such authority to bind the principal then the principal is bound by the signers action. So as I see it, a director could digitally sign the digital document using the directors own personal private key and as part of the text of the document state the following word "signed for and on behalf of Company XXXX". This would indicate to the world that the signer is NOT signing the digital document so as to be personally bound but is signing as an agent and as such is attempting to bind the principal (company). The recipient would on receipt verify the digital signature using the signer's personal certificate that has the public key embodied in it. If the recipient is concerned about the authority then the recipient can check the company records to determine if the signer has the necessary implied/ostensible authority. To accelerate the process of verification of authority there may be some solution in the use of role based certificates or attribute certificates but I have not really give this issue sufficient thought. If there is still some doubt then the recipient can always check with the Company secretary or the Managing director as to such authority. The Uniform Electronic Transactions Act that is forming part of the Uniform Commercial Code of various US States does anticipate software agents and thus server based organisation digital signatures. But there are no cases that specifically deal with your issue. The simple solution is for a company officer to digitally sign the digital document and affix the words noted above in the text prior to digitally signing. I hope this is helpful. Adrian McCullagh Director of Electronic CommerceTel: 617 3231 1522 Gadens Lawyers Fax: 617 3229 5850 level 39 Central Plaza 1 345 Queen Street Brisbane Australia 4000 Ph. D. Candidate Thesis "The Incorporation of Trust Strategies in Digital Signature Regimes for Elec. Comm." Information Security Research Centre Queensland University of Technology - - -----Original Message----- From: Anders Rundgren [ mailto:anders.rundgren@telia.com] Sent: Monday, August 07, 2000 6:58 AM To: PKIX-List Subject: Digital Signatures - Legal Advice Wanted Hi, I am working with an e-commerce standard that features server-based, organization-signed orders. However, server-based, organization-oriented digital signatures do currently not, to the my knowledge, have explicit support in any legal system. How to solve this? One way (the current one) is to state in separate agreements between the trading partners, that you will stand by these signatures in court. I wonder if there could be a more general solution like: A company officer digitally signs (using a personal certificate), a document where he/she states that signatures associated with a certain trading partner certificate are to be considered as legally binding from the company's point of view. Such a document is preferably published on the company's home-page for easy reference. How does this sound in the ears of lawyers? regards Anders Rundgren - -----BEGIN PGP SIGNATURE----- Version: PGP Personal Edition 6.0.2 iQA/AwUBOY1FTJWt1NGjt4vzEQLdmACeJiR1FMKZ//6Mtfq+v5DfAGGo/q4AoJoM bWjrz+F/Xll2zwotTzuligVm =sEx7 - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: PGP Personal Edition 6.0.2 iQA/AwUBOY6Oc5Wt1NGjt4vzEQIjpgCfZQpuuUxCJZwQbXJ0qxTBiV78qBkAoLpy ZH9cgCYkemF3Ca4D4nYjLNMF =XCG7 -----END PGP SIGNATURE----- From owner-ietf-pkix@imc.org Tue Aug 8 08:20:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07559 for ; Tue, 8 Aug 2000 08:20:12 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA20683; Tue, 8 Aug 2000 05:15:22 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 8 Aug 2000 05:15:06 -0700 Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA20620 for ; Tue, 8 Aug 2000 05:15:05 -0700 (PDT) Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA20608 for ; Tue, 8 Aug 2000 08:19:17 -0400 (EDT) Received: from anuxc.mv.lucent.com (h135-13-160-12.lucent.com [135.13.160.12]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA20544; Tue, 8 Aug 2000 08:19:13 -0400 (EDT) Received: from irene by anuxc.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA00470; Tue, 8 Aug 2000 08:16:31 -0400 (EDT) Message-Id: <4.1.20000808073706.0365aeb0@anuxc.mv.lucent.com> X-Sender: irg@anuxc.mv.lucent.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 08 Aug 2000 08:19:29 -0400 To: Al Arsenault From: Irene Gassko Subject: RE: OCSP request Cc: "ietf-pkix@imc.org" In-Reply-To: <01C0005C.A43805A0.aarsenault@dvnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 10:45 AM 08/07/2000 -0400, Al Arsenault wrote: >The problem with this scheme is that, even if it does help with archiving >and recovery in the case of CA key compromise, it doesn't help in the >normal certificate processing operations. > >With a certificate signed by a CA, I know that "the CA has vouched for the >correctness of each of the data items in this certificate", subject to the >normal discussions on how thoroughly the CA has verified them, yada, yada, >yada. > >With a certificate not being signed, or being signed by the originator, I >just know that I have a data structure, and I'm not sure about the CA's >willingness to vouch for those items, until such time as I go fetch the >signed Merkle tree that pertains and verify it, recursively to where I get >to a trusted root. That is, I don't know if I have a complete spoof >attempt, a corrupted cert, or anything else, until such time as I do the >"revocation check". > >So it seems to me that in the normal processing mode, this proposal is >actually somewhat *less* efficient than the current scheme, where I can do >some checks on the cert BEFORE I fetch the CRL or ping the OCSP responder, >and thus not even bother with revocation checking on things that have >already failed. > This is absolutely correct if you only want to check one individual certificate, do not care about the possibility of revocation much and are not worried about potential CA key compromise. Yes, and also if you trust directories to tell you truthfully whether they have a particular certificate you are looking for. If you are checking a number of certificates from the same CA (say, Visa cards) then you only need to check one signature and a few hashes, which is much more efficient then checking a signature from every certificate. You can even check that signature in advance, for example a vendor can do it outside of rush hours and then only a few hashes need to be computed: this is more efficient than verifying a signature each time. If your certificate is your credit card and today is your shopping day, you can prefetch verification path to speed up approval for your purchases (in this case I assume it to be a smartcard, as is common in Europe). Besides efficiency issues there are other properties that a current scheme does not possess. For example, if a CA key gets silently compromised, and a certificate is forged quietly, with the current technology there is no way to discover that a certificate is fake. However, in our scheme, in order to fabricate a certificate, the root value of the Merkle tree has to be altered, which will be too conspicuous to miss. And another property. Even though directories are supposed to be untrusted (or we would not need a CA signature at all), if we are looking for a certificate, we are willing to believe that a particular certificate is not in the directory, on the directory's say so. Our approach allows you get a get a proof that this directory really does not possess a cert you are looking for. No more trust needed for untrusted directories. So, it looks like efficiency really depends on how those certificates are used. Irene > Al Arsenault > Chief Security Architect > Diversinet Corp. > > >-----Original Message----- >From: Irene Gassko [SMTP:gassko@lucent.com] >Sent: Monday, August 07, 2000 10:20 AM >To: Stephen Kent >Cc: ietf-pkix@imc.org >Subject: RE: OCSP request > >Steve, > >You are right and I know that currently signatures are mandatory. >But making changes in order to solve serious problems is a part >of the standards process, isn't it? A lot of discussion in this >group is devoted to suggested improvements in the standard. If >making signatures optional can help with CA key change and cert >archiving, would not it be a good idea to allow such usage (as in >MAY)? > >Irene > >At 05:55 PM 08/06/2000 -0400, Stephen Kent wrote: >>Irene, >> >> >> >> >>>The main idea is to eliminate signatures in certificates and have CA >>>sign a Merkle tree of certificates instead. Then CA key compromise >>>requires the change in that signature (which can be downloaded >separately) >>>but leaves cards and certificates unperturbed. You can use multiple >>>signatures with different signature algorithms and keep keys on different >>>continents if you wish. This scheme also helps with archiving. And you do >not >>>need a CRL. It can be used with X.509 certificates, making the signature >>>on a certificate optional, rather than mandatory. Or you can make it >>>an owner's signature instead of a CA's signature. >> >>Irrespective of the merit of the approach to which you allude, the >>result would not be an X.509 cert. Signatures are mandatory, not >>optional, in the format that is the basis of this WG's activity. >> >>Steve > >------------------------------------------------------------------------ >---- >------------------------------------------------------- >Irene Gassko Bell Laboratories http://www.lucent.com >Lucent Technologies Secure Technologies Dept. >1600 Osgood Street phone: (978) 960-5767 >Room 30-2-A31 e-mail: gassko@lucent.com >N. Andover, MA 01845 fax: (978) 960-3240 ---------------------------------------------------------------------------- ------------------------------------------------------- Irene Gassko Bell Laboratories http://www.lucent.com Lucent Technologies Secure Technologies Dept. 1600 Osgood Street phone: (978) 960-5767 Room 30-2-A31 e-mail: gassko@lucent.com N. Andover, MA 01845 fax: (978) 960-3240 From owner-ietf-pkix@imc.org Tue Aug 8 08:31:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14715 for ; Tue, 8 Aug 2000 08:31:25 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA09921; Mon, 7 Aug 2000 18:06:40 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 7 Aug 2000 18:06:32 -0700 Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA09884 for ; Mon, 7 Aug 2000 18:06:31 -0700 (PDT) Received: from [128.33.238.46] (TC046.BBN.COM [128.33.238.46]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id VAA21255; Mon, 7 Aug 2000 21:10:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4.1.20000807101230.03173400@anuxc.mv.lucent.com> References: <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> <4.1.20000807101230.03173400@anuxc.mv.lucent.com> Date: Mon, 7 Aug 2000 21:07:19 -0400 To: Irene Gassko From: Stephen Kent Subject: RE: OCSP request Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Irene, >Steve, > >You are right and I know that currently signatures are mandatory. >But making changes in order to solve serious problems is a part >of the standards process, isn't it? A lot of discussion in this >group is devoted to suggested improvements in the standard. If >making signatures optional can help with CA key change and cert >archiving, would not it be a good idea to allow such usage (as in >MAY)? The charter of this WG is to profile X.509, which includes the syntax, processing, and underlying models for PKI. Interoperability is a primary thrust of the work. The change you suggest would not be backward compatible with X.509, or with any of the previous PKIX syntax, so it's hard to imagine making such a change. Even a MAY would break existing implementations. Steve From owner-ietf-pkix@imc.org Tue Aug 8 08:32:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15514 for ; Tue, 8 Aug 2000 08:32:42 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA22249; Tue, 8 Aug 2000 05:28:02 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 8 Aug 2000 05:28:01 -0700 Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA22217 for ; Tue, 8 Aug 2000 05:28:00 -0700 (PDT) Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA00192 for ; Tue, 8 Aug 2000 08:32:12 -0400 (EDT) Received: from anuxc.mv.lucent.com (h135-13-160-12.lucent.com [135.13.160.12]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA00176; Tue, 8 Aug 2000 08:32:11 -0400 (EDT) Received: from irene by anuxc.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA00777; Tue, 8 Aug 2000 08:29:30 -0400 (EDT) Message-Id: <4.1.20000808082030.03559e48@anuxc.mv.lucent.com> X-Sender: irg@anuxc.mv.lucent.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 08 Aug 2000 08:32:29 -0400 To: Stephen Kent From: Irene Gassko Subject: RE: OCSP request Cc: ietf-pkix@imc.org In-Reply-To: References: <4.1.20000807101230.03173400@anuxc.mv.lucent.com> <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> <4.1.20000807101230.03173400@anuxc.mv.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Steve, Thanks a lot for this clarification. In fact, making signatures optional is not needed for our scheme to work, I only mentioned it for efficiency reason. Like Richard and Tony suggested it may work independently without disturbing current implementations. It can provide a fallback support for CA key change, for example, especially if this change is a result of a private key compromise. Actually, I mentioned our solution in the course of an archiving discussion, as a way to protect against keys being discovered and signature schemes being broken in the future. Irene At 09:07 PM 08/07/2000 -0400, Stephen Kent wrote: >Irene, > >>Steve, >> >>You are right and I know that currently signatures are mandatory. >>But making changes in order to solve serious problems is a part >>of the standards process, isn't it? A lot of discussion in this >>group is devoted to suggested improvements in the standard. If >>making signatures optional can help with CA key change and cert >>archiving, would not it be a good idea to allow such usage (as in >>MAY)? > >The charter of this WG is to profile X.509, which includes the >syntax, processing, and underlying models for PKI. Interoperability >is a primary thrust of the work. The change you suggest would not be >backward compatible with X.509, or with any of the previous PKIX >syntax, so it's hard to imagine making such a change. Even a MAY >would break existing implementations. > >Steve ---------------------------------------------------------------------------- ------------------------------------------------------- Irene Gassko Bell Laboratories http://www.lucent.com Lucent Technologies Secure Technologies Dept. 1600 Osgood Street phone: (978) 960-5767 Room 30-2-A31 e-mail: gassko@lucent.com N. Andover, MA 01845 fax: (978) 960-3240 From owner-ietf-pkix@imc.org Tue Aug 8 08:49:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25742 for ; Tue, 8 Aug 2000 08:49:05 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA23497; Tue, 8 Aug 2000 05:44:24 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 8 Aug 2000 05:44:18 -0700 Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA23464 for ; Tue, 8 Aug 2000 05:44:16 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA15706; Tue, 8 Aug 2000 14:52:34 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA16070; Tue, 8 Aug 2000 14:47:53 +0200 Message-ID: <3990017A.8C0A578A@bull.net> Date: Tue, 08 Aug 2000 14:47:54 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Irene Gassko CC: ietf-pkix@imc.org Subject: Re: OCSP request References: <4.1.20000807101230.03173400@anuxc.mv.lucent.com> <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> <4.1.20000807101230.03173400@anuxc.mv.lucent.com> <4.1.20000808082030.03559e48@anuxc.mv.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Irene, > Steve, > > Thanks a lot for this clarification. > > In fact, making signatures optional is not needed for our scheme > to work, I only mentioned it for efficiency reason. Like Richard > and Tony suggested it may work independently without disturbing > current implementations. It can provide a fallback support for CA > key change, for example, especially if this change is a result of > a private key compromise. Actually, I mentioned our solution in Simple non-technical question. Is -to your own best knowledge- this scheme patented ? Thanks, Denis > the course of an archiving discussion, as a way to protect against > keys being discovered and signature schemes being broken in > the future. > > Irene > > At 09:07 PM 08/07/2000 -0400, Stephen Kent wrote: > >Irene, > > > >>Steve, > >> > >>You are right and I know that currently signatures are mandatory. > >>But making changes in order to solve serious problems is a part > >>of the standards process, isn't it? A lot of discussion in this > >>group is devoted to suggested improvements in the standard. If > >>making signatures optional can help with CA key change and cert > >>archiving, would not it be a good idea to allow such usage (as in > >>MAY)? > > > >The charter of this WG is to profile X.509, which includes the > >syntax, processing, and underlying models for PKI. Interoperability > >is a primary thrust of the work. The change you suggest would not be > >backward compatible with X.509, or with any of the previous PKIX > >syntax, so it's hard to imagine making such a change. Even a MAY > >would break existing implementations. > > > >Steve > > ---------------------------------------------------------------------------- > ------------------------------------------------------- > Irene Gassko Bell Laboratories http://www.lucent.com > Lucent Technologies Secure Technologies Dept. > 1600 Osgood Street phone: (978) 960-5767 > Room 30-2-A31 e-mail: gassko@lucent.com > N. Andover, MA 01845 fax: (978) 960-3240 From owner-ietf-pkix@imc.org Tue Aug 8 09:16:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12714 for ; Tue, 8 Aug 2000 09:16:30 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA24577; Tue, 8 Aug 2000 06:11:46 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 8 Aug 2000 06:11:42 -0700 Received: from dvnet8.dvnet.com ([209.121.31.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24547 for ; Tue, 8 Aug 2000 06:11:40 -0700 (PDT) Received: from CC787228-A (cc787228-a.hwrd1.md.home.com [24.180.131.6]) by dvnet8.dvnet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QK5F0JA5; Tue, 8 Aug 2000 09:18:36 -0400 Received: by localhost with Microsoft MAPI; Tue, 8 Aug 2000 09:16:35 -0400 Message-ID: <01C00119.59D0CC00.aarsenault@dvnet.com> From: Al Arsenault To: "'Irene Gassko'" Cc: "ietf-pkix@imc.org" Subject: RE: OCSP request Date: Tue, 8 Aug 2000 09:16:34 -0400 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 207 TEXT Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Irene Gassko wrote: So, it looks like efficiency really depends on how those certificates are used. This part I'll agree with completely! As experience has shown repeatedly, there's no "one best way" that always gives best performance from a PKI implementation. It's a function of what application(s) you're trying to support, what risks you're willing to take, what your constraints are in terms of time, money, and technology, and a lot of other things, besides. I guess I started this by using the term "normal processing mode", so I'll attempt to clarify - in some environments - e.g., where certificates are being used to sign, encrypt, and verify e-mail messages - the approach suggested by Irene seems to me to be less efficient than the approaches currently defined in PKIX today, and in more-or-less common use. In other environments, the approach she suggested MAY be more efficient, depending on a lot of the factors identified above. Some specific comments in-line: -----Original Message----- From: Irene Gassko [SMTP:gassko@lucent.com] Sent: Tuesday, August 08, 2000 8:19 AM To: Al Arsenault Cc: ietf-pkix@imc.org Subject: RE: OCSP request At 10:45 AM 08/07/2000 -0400, Al Arsenault wrote: >The problem with this scheme is that, even if it does help with archiving >and recovery in the case of CA key compromise, it doesn't help in the >normal certificate processing operations. > >With a certificate signed by a CA, I know that "the CA has vouched for the >correctness of each of the data items in this certificate", subject to the >normal discussions on how thoroughly the CA has verified them, yada, yada, >yada. > >With a certificate not being signed, or being signed by the originator, I >just know that I have a data structure, and I'm not sure about the CA's >willingness to vouch for those items, until such time as I go fetch the >signed Merkle tree that pertains and verify it, recursively to where I get >to a trusted root. That is, I don't know if I have a complete spoof >attempt, a corrupted cert, or anything else, until such time as I do the >"revocation check". > >So it seems to me that in the normal processing mode, this proposal is >actually somewhat *less* efficient than the current scheme, where I can do >some checks on the cert BEFORE I fetch the CRL or ping the OCSP responder, >and thus not even bother with revocation checking on things that have >already failed. > This is absolutely correct if you only want to check one individual certificate, do not care about the possibility of revocation much and are not worried about potential CA key compromise. Yes, and also if you trust directories to tell you truthfully whether they have a particular certificate you are looking for. AWA: I disagree to a greater or lesser extent with every clause in this paragraph. The number of certificates does not have to be one; "small" for appropriate values of that word will suffice. "Do not care about the possibility of revocation much" - huh? Where did that come from? I pointed out that sometimes you're going to reject a putative cert even BEFORE you check revocation status; e.g., because it got garbled in transit and thus the signature fails. Why does "reject because the signature failed before I ever bothered to check revocation" equal "don't care about revocation"? "Are not worried about potential CA key compromise" - bear in mind that there are a lot of factors that come into play if a CA key has been compromised. Thus, making a decision to accept a certificate originally signed with a key known to have been compromised requires a lot of consideration. If you are checking a number of certificates from the same CA (say, Visa cards) then you only need to check one signature and a few hashes, which is much more efficient then checking a signature from every certificate. You can even check that signature in advance, for example a vendor can do it outside of rush hours and then only a few hashes need to be computed: this is more efficient than verifying a signature each time. If your certificate is your credit card and today is your shopping day, you can prefetch verification path to speed up approval for your purchases (in this case I assume it to be a smartcard, as is common in Europe). AWA: yes, for this environment, the approach you suggest may be more efficient than the traditional one. Besides efficiency issues there are other properties that a current scheme does not possess. For example, if a CA key gets silently compromised, and a certificate is forged quietly, with the current technology there is no way to discover that a certificate is fake. However, in our scheme, in order to fabricate a certificate, the root value of the Merkle tree has to be altered, which will be too conspicuous to miss. AWA: forgive me if I get the technology wrong - I have some familiarity with Merkle trees, but I'm certainly no expert on them. However, as I understand the technology proposed, every time the CA issues a new legitimate certificate, the root value has to be altered. In any kind of dynamic environment - e.g., certificates issued every few (seconds, minutes, hours,...), new certs are issued and thus the root value has to change regularly. Thus, the event "root value altered because of a fake cert signed by a compromised key" is very difficult to distinguish from "root value altered because of legitimate cert signed by the real CA", EXCEPT to the CA itself. Yes, if the CA is "eternally vigilant", you might catch this happening, but then again you might not. And another property. Even though directories are supposed to be untrusted (or we would not need a CA signature at all), if we are looking for a certificate, we are willing to believe that a particular certificate is not in the directory, on the directory's say so. Our approach allows you get a get a proof that this directory really does not possess a cert you are looking for. No more trust needed for untrusted directories. AWA: If the directory tries to say "I have some certs, but not the one for which you're looking", your approach works. If the directory says "I have no certs at all", your approach provides the same results as the previous approach. About which "attack" do you care? So, it looks like efficiency really depends on how those certificates are used. Irene > Al Arsenault > Chief Security Architect > Diversinet Corp. > > >-----Original Message----- >From: Irene Gassko [SMTP:gassko@lucent.com] >Sent: Monday, August 07, 2000 10:20 AM >To: Stephen Kent >Cc: ietf-pkix@imc.org >Subject: RE: OCSP request > >Steve, > >You are right and I know that currently signatures are mandatory. >But making changes in order to solve serious problems is a part >of the standards process, isn't it? A lot of discussion in this >group is devoted to suggested improvements in the standard. If >making signatures optional can help with CA key change and cert >archiving, would not it be a good idea to allow such usage (as in >MAY)? > >Irene > >At 05:55 PM 08/06/2000 -0400, Stephen Kent wrote: >>Irene, >> >> >> >> >>>The main idea is to eliminate signatures in certificates and have CA >>>sign a Merkle tree of certificates instead. Then CA key compromise >>>requires the change in that signature (which can be downloaded >separately) >>>but leaves cards and certificates unperturbed. You can use multiple >>>signatures with different signature algorithms and keep keys on different >>>continents if you wish. This scheme also helps with archiving. And you do >not >>>need a CRL. It can be used with X.509 certificates, making the signature >>>on a certificate optional, rather than mandatory. Or you can make it >>>an owner's signature instead of a CA's signature. >> >>Irrespective of the merit of the approach to which you allude, the >>result would not be an X.509 cert. Signatures are mandatory, not >>optional, in the format that is the basis of this WG's activity. >> >>Steve > >------------------------------------------------------------------------ >---- >------------------------------------------------------- >Irene Gassko Bell Laboratories http://www.lucent.com >Lucent Technologies Secure Technologies Dept. >1600 Osgood Street phone: (978) 960-5767 >Room 30-2-A31 e-mail: gassko@lucent.com >N. Andover, MA 01845 fax: (978) 960-3240 ------------------------------------------------------------------------ ---- ------------------------------------------------------- Irene Gassko Bell Laboratories http://www.lucent.com Lucent Technologies Secure Technologies Dept. 1600 Osgood Street phone: (978) 960-5767 Room 30-2-A31 e-mail: gassko@lucent.com N. Andover, MA 01845 fax: (978) 960-3240 From owner-ietf-pkix@imc.org Tue Aug 8 10:35:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13734 for ; Tue, 8 Aug 2000 10:35:49 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA00150; Tue, 8 Aug 2000 07:31:03 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 8 Aug 2000 07:30:55 -0700 Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA00116 for ; Tue, 8 Aug 2000 07:30:55 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Tue, 8 Aug 2000 07:25:49 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2B417E4@seine.valicert.com> From: Ambarish Malpani To: "'Denis Pinkas'" , Irene Gassko Cc: ietf-pkix@imc.org Subject: The real topic has nothing to do with: Re: OCSP request Date: Tue, 8 Aug 2000 07:25:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Denis, It isn't to one's "best" knowledge, but to one's "actual" knowledge, if I remember Radia's presentation at the SACRED/SAAG groups correctly :-) Ambarish P.S. I wonder what people think about having a lawyer come and address us at IETF to explain "true English" to us! --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: Tuesday, August 08, 2000 5:48 AM > To: Irene Gassko > Cc: ietf-pkix@imc.org > Subject: Re: OCSP request > > > Irene, > > > Steve, > > > > Thanks a lot for this clarification. > > > > In fact, making signatures optional is not needed for our scheme > > to work, I only mentioned it for efficiency reason. Like Richard > > and Tony suggested it may work independently without disturbing > > current implementations. It can provide a fallback support for CA > > key change, for example, especially if this change is a result of > > a private key compromise. Actually, I mentioned our solution in > > Simple non-technical question. Is -to your own best knowledge- this > scheme patented ? > > Thanks, > > Denis From owner-ietf-pkix@imc.org Tue Aug 8 11:20:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14018 for ; Tue, 8 Aug 2000 11:20:34 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA04921; Tue, 8 Aug 2000 08:15:56 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 8 Aug 2000 08:15:52 -0700 Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA04873 for ; Tue, 8 Aug 2000 08:15:51 -0700 (PDT) Received: by mystic1.trustcenter.de; id RAA19583; Tue, 8 Aug 2000 17:17:37 +0200 Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma019581; Tue, 8 Aug 00 17:17:10 +0200 Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id RAA09410; Tue, 8 Aug 2000 17:18:53 +0200 (MET DST) Message-Id: <3.0.5.32.20000808171854.04523b20@localhost> X-Sender: jbr@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 08 Aug 2000 17:18:54 +0200 To: Ambarish Malpani From: Juergen Brauckmann Subject: RE: OCSP request Cc: ietf-pkix@imc.org In-Reply-To: <27FF4FAEA8CDD211B97E00902745CBE2B4175A@seine.valicert.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Sorry for the late reply... . At 07:44 27.07.00 -0700, Ambarish Malpani wrote: >Hi Juergen, > Originally, OCSP had the following states (I do this from >memory, so I might be a little off): Thank you. >P.S. What is the status of the ISIS solution? Is it already a >"rule/law"? Is it open to review/comments/suggestions? ISIS is an interop specification by 9 German CAs (no, we currently don't make laws;-). I can send you a .pdf... . Regards, Juergen From owner-ietf-pkix@imc.org Tue Aug 8 23:15:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20851 for ; Tue, 8 Aug 2000 23:15:05 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA04580; Tue, 8 Aug 2000 20:10:05 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 8 Aug 2000 20:09:09 -0700 Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA04463 for ; Tue, 8 Aug 2000 20:09:07 -0700 (PDT) Received: from m3.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0006-Fujitsu Gateway) id MAA06225 for ; Wed, 9 Aug 2000 12:12:41 +0900 (JST) (envelope-from takiguti@fjh.se.fujitsu.co.jp) Received: from nic10.fjh.se.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.9.3/3.7W-0008-Fujitsu Domain Master) id MAA02775; Wed, 9 Aug 2000 12:12:40 +0900 (JST) Received: from anakin (anakin.fjh.se.fujitsu.co.jp [10.131.201.130]) by nic10.fjh.se.fujitsu.co.jp (8.9.3+3.2W/3.7W) with ESMTP id MAA15687 for ; Wed, 9 Aug 2000 12:12:38 +0900 (JST) Date: Wed, 09 Aug 2000 12:12:38 +0900 From: TAKIGUCHI Naruhito To: ietf-pkix@imc.org Subject: CRL number in CRL and ARL Message-Id: <20000809113001.6155.TAKIGUTI@fjh.se.fujitsu.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00 (beta 25) Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi, all. I have a question about the cRLNumber extension. For example, a CA issues CRL(end-entity certificate revocation list) and ARL(CA certificate revocation list). Which is correct (a) or (b) ? (a) In first CRL and ARL, the CRL number is 0. In next CRL and ARL, the CRL number is 1. In other words, CRL and ARL have same value of the CRL number. The CRL number is a monotonically increasing sequence number for each CRL scope. (b) In first CRL, the CRL Number is 0. In first ARL, the CRL Number is 1. In next CRL, the CRL number is 2. In next ARL, the CRL number is 3. In other words, the CRL number is monotonically increasing sequence number for each CA. Could anyone advice me? Thanks in advance. ----- Naruhito TAKIGUCHI FUJITSU HOKURIKU SYSTEMS LTD. From owner-ietf-pkix@imc.org Wed Aug 9 08:00:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10256 for ; Wed, 9 Aug 2000 08:00:17 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA28684; Wed, 9 Aug 2000 02:34:58 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 9 Aug 2000 02:34:40 -0700 Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA28649 for ; Wed, 9 Aug 2000 02:34:39 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA13486; Wed, 9 Aug 2000 11:43:04 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA37880; Wed, 9 Aug 2000 11:38:21 +0200 Message-ID: <3991268E.7AEA413D@bull.net> Date: Wed, 09 Aug 2000 11:38:22 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Simon Tardell CC: ietf-pkix@imc.org Subject: Re: OCSP request References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Simon, > All, > > we have gone quite far from my original question, whether it is possible to > clarify RFC2560 in such a way that ISIS semantics (and others) can be > expressed in a clean way, adding to, not altering, the base semantics. I do no think that any "clarification" is needed for RFC 2560 to this respect. The text is crystal clear and does not need to be changed. The text says for the "good status": " The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval. Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate such as positive statement about issuance, validity, etc. It is thus clear that extensions may carry any additional semantics or fields. Such extensions may be defined using: requestExtensions [2] EXPLICIT Extensions OPTIONAL in an OCSPRequest, or using: responseExtensions [1] EXPLICIT Extensions OPTIONAL in an OCSPResponse (more exactly in ResponseData). If someone has some interest for some extension, it should be defined in a *separate* document and then proposed to the PKIX working group either to be on the standard track, being informational or being experimental. Denis > The > purpose being that OCSP clients should be able to be clients to both > "ordinary" PKIs and ISIS model PKIs. > > The discussion about whether there are other ways of meeting the design > goals of the ISIS model is of course interesting, but I'm not sure how much > that can be done about the model at this stage. Much of this model is set > already in the underlying laws and regulations, and I suppose those are not > going to change much in this respect. > > Simon. > > Simon Tardell, Software Architect, iD2 Technologies > voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 > simon.tardell@iD2tech.com, http://www.iD2tech.com > Securing the Internet economy From owner-ietf-pkix@imc.org Wed Aug 9 08:00:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10267 for ; Wed, 9 Aug 2000 08:00:18 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA26237; Wed, 9 Aug 2000 02:08:14 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 9 Aug 2000 02:08:10 -0700 Received: from getafix.fcpl.co.in (getafix.fcpl.co.in [196.1.104.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA26184 for ; Wed, 9 Aug 2000 02:07:57 -0700 (PDT) Received: from SHANTANU ([196.1.104.102]) by getafix.fcpl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QGR5LC7Y; Wed, 9 Aug 2000 14:44:33 +0530 Message-ID: <01e001c001e3$3e7f2da0$666801c4@fcpl.co.in> From: "Shantanu Bhattacharya" To: References: Subject: Keeping track of the history of secure operations Date: Wed, 9 Aug 2000 14:51:46 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit I was wondering if there is any way one can keep track of the history of secure operations done on a document in such a way as to be auditable at a later point in time. If anybody has any solution to this, please let me know. Regards Shantanu Bhattacharya Project Manager E-Lock Technologies Pvt. Ltd. From owner-ietf-pkix@imc.org Wed Aug 9 08:11:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13370 for ; Wed, 9 Aug 2000 08:11:45 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA09166; Wed, 9 Aug 2000 05:06:46 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 9 Aug 2000 05:06:28 -0700 Received: from irwell.zetnet.co.uk (root@irwell.zetnet.co.uk [194.247.47.48]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA09118 for ; Wed, 9 Aug 2000 05:06:26 -0700 (PDT) Received: from jeffdavis (man-a081.dialup.zetnet.co.uk [194.247.44.81]) by irwell.zetnet.co.uk (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA31966; Wed, 9 Aug 2000 13:09:53 +0100 X-Authentication-Warning: irwell.zetnet.co.uk: Host man-a081.dialup.zetnet.co.uk [194.247.44.81] claimed to be jeffdavis Message-ID: <00f001c001fa$91b3b7e0$512cf7c2@zetnet.co.uk> From: "Jeff Davis" To: "Heimberg, Jim" , "PKIX-List" References: <2575327B6755D211A0E100805F9FF954050805C4@ndhmex02.ndhm.gsc.gte.com> Subject: Re: Digital Signatures - Legal Advice Wanted Date: Wed, 9 Aug 2000 11:52:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Jim, I agree with your point here. If a person is given a certificate and set of keys which can then be used to sign for and on behalf of the company then that should be binding against the company and not the individual. The DN should reflect the position of authority within the company, including the individuals name for accountability etc. When the person leaves the company the certificate gets revoked, probably better than chopping off the hands of the person leaving! some people continue to recognise hand written signatures long after their authority has expired ). Cheers Jeff Davis ----- Original Message ----- From: Heimberg, Jim To: 'Tony Bartoletti' ; Adrian McCullagh ; 'Anders Rundgren' ; PKIX-List Sent: Monday, August 07, 2000 7:43 PM Subject: RE: Digital Signatures - Legal Advice Wanted > Just to add to the confusion, is there no allowance for designating the > personality as the role that person fills? For instance, if you wanted as a > CA to grant a signature and encryption key and the requisite authority to > the Chief Financial Officer of a small company (e.g., Acme Electrical > Supply) for purchasing as required, why can you not issue a certificate to > cfo@acmeelectric.com (and if you need to personalize it, you could add the > person's name or initials after the CFO designation)? > > -----Original Message----- > From: Tony Bartoletti [mailto:azb@llnl.gov] > Sent: Monday, August 07, 2000 2:21 PM > To: Adrian McCullagh; 'Anders Rundgren'; PKIX-List > Subject: RE: Digital Signatures - Legal Advice Wanted > > > At 07:00 AM 8/7/00 +1000, Adrian McCullagh wrote: > > >In Common law countries like the USA, Australia, UK and Canada, there > >is a doctrine known as ostensible authority. This provides that if a > >person signs a document on behalf of another legal entity (the > >principal) and the signer has some external reasonably perceived > >authority such that a reasonable person looking at the transaction > >objectively would believe that such person through his/her position > >had such authority to bind the principal then the principal is bound > >by the signers action. > > > >So as I see it, a director could digitally sign the digital document > >using the directors own personal private key and as part of the text > >of the document state the following word "signed for and on behalf of > >Company XXXX". This would indicate to the world that the signer is > >NOT signing the digital document so as to be personally bound but is > >signing as an agent and as such is attempting to bind the principal > >(company). > > (Please correct me, Anders, if I am mistaken, but) I believe the > issue is a little different than Adrian supposes. > > Rather than have a (company) individual sign on behalf of > "the company", I believe that the issue is whether a company > (ok, an individual acting on behalf of the company if you must) > can hold "customer's keys" and apply "customer's signatures", > given some trail of evidence that the customer, on a case-by- > case basis, has authorized that their signature be affixed to > a given transaction. > > The primary goal being to keep the customer's "secret keys" > in an environment more secure than the customer may be expected > to maintain. > > (The legal precedent for this might be "power of attorney"?) > > If I'm wrong ... nevermind :) > > ___tony___ > > >The recipient would on receipt verify the digital signature using the > >signer's personal certificate that has the public key embodied in it. > >If the recipient is concerned about the authority then the recipient > >can check the company records to determine if the signer has the > >necessary implied/ostensible authority. To accelerate the process of > >verification of authority there may be some solution in the use of > >role based certificates or attribute certificates but I have not > >really give this issue sufficient thought. > > > >If there is still some doubt then the recipient can always check with > >the Company secretary or the Managing director as to such authority. > > > >The Uniform Electronic Transactions Act that is forming part of the > >Uniform Commercial Code of various US States does anticipate software > >agents and thus server based organisation digital signatures. > > > >But there are no cases that specifically deal with your issue. > > > >The simple solution is for a company officer to digitally sign the > >digital document and affix the words noted above in the text prior to > >digitally signing. > > > >I hope this is helpful. > > > > > >Adrian McCullagh > >Director of Electronic CommerceTel: 617 3231 1522 > >Gadens Lawyers Fax: 617 3229 5850 > >level 39 > >Central Plaza 1 > >345 Queen Street > >Brisbane Australia 4000 > > > >Ph. D. Candidate > >Thesis "The Incorporation of Trust Strategies in Digital Signature > >Regimes for Elec. Comm." > >Information Security Research Centre > >Queensland University of Technology > > > > > > > >- -----Original Message----- > >From: Anders Rundgren [ mailto:anders.rundgren@telia.com] > >Sent: Monday, August 07, 2000 6:58 AM > >To: PKIX-List > >Subject: Digital Signatures - Legal Advice Wanted > > > > > >Hi, > >I am working with an e-commerce standard that features server-based, > >organization-signed orders. > > > >However, server-based, organization-oriented digital signatures do > >currently not, to the my knowledge, > >have explicit support in any legal system. How to solve this? One > >way (the current one) is to state > >in separate agreements between the trading partners, that you will > >stand by these signatures in court. > > > >I wonder if there could be a more general solution like: A company > >officer digitally signs (using a personal > >certificate), a document where he/she states that signatures > >associated with a certain trading partner > >certificate are to be considered as legally binding from the company's > >point of view. > >Such a document is preferably published on the company's home-page for > >easy reference. > > > >How does this sound in the ears of lawyers? > > > >regards > >Anders Rundgren > > > > > > > >-----BEGIN PGP SIGNATURE----- > >Version: PGP Personal Edition 6.0.2 > > > >iQA/AwUBOY1FTJWt1NGjt4vzEQLdmACeJiR1FMKZ//6Mtfq+v5DfAGGo/q4AoJoM > >bWjrz+F/Xll2zwotTzuligVm > >=sEx7 > >-----END PGP SIGNATURE----- > > Tony Bartoletti 925-422-3881 > Information Operations, Warfare and Assurance Center > Lawrence Livermore National Laboratory > Livermore, CA 94551-9900 > From owner-ietf-pkix@imc.org Wed Aug 9 09:22:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10288 for ; Wed, 9 Aug 2000 08:00:19 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA22256; Wed, 9 Aug 2000 01:15:44 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 9 Aug 2000 01:15:26 -0700 Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA22206 for ; Wed, 9 Aug 2000 01:15:24 -0700 (PDT) Received: FROM aunt15.ausys.se BY naigwy ; Wed Aug 09 10:17:20 2000 +0200 Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 10:19:00 +0200 Message-ID: From: Simon Tardell To: "'Juergen Brauckmann'" , Ambarish Malpani Cc: ietf-pkix@imc.org Subject: RE: OCSP request Date: Wed, 9 Aug 2000 10:18:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > >P.S. What is the status of the ISIS solution? Is it already a > >"rule/law"? Is it open to review/comments/suggestions? > > ISIS is an interop specification by 9 German CAs (no, we > currently don't > make laws;-). All, we have gone quite far from my original question, whether it is possible to clarify RFC2560 in such a way that ISIS semantics (and others) can be expressed in a clean way, adding to, not altering, the base semantics. The purpose being that OCSP clients should be able to be clients to both "ordinary" PKIs and ISIS model PKIs. The discussion about whether there are other ways of meeting the design goals of the ISIS model is of course interesting, but I'm not sure how much that can be done about the model at this stage. Much of this model is set already in the underlying laws and regulations, and I suppose those are not going to change much in this respect. Simon. Simon Tardell, Software Architect, iD2 Technologies voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 simon.tardell@iD2tech.com, http://www.iD2tech.com Securing the Internet economy From owner-ietf-pkix@imc.org Wed Aug 9 10:34:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03704 for ; Wed, 9 Aug 2000 10:34:39 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA16993; Wed, 9 Aug 2000 06:58:12 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 9 Aug 2000 06:57:57 -0700 Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA16935 for ; Wed, 9 Aug 2000 06:57:50 -0700 (PDT) Received: FROM aunt15.ausys.se BY naigwy ; Wed Aug 09 15:59:48 2000 +0200 Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 16:01:28 +0200 Message-ID: From: Simon Tardell To: "'Denis Pinkas'" , Simon Tardell Cc: ietf-pkix@imc.org Subject: RE: OCSP request Date: Wed, 9 Aug 2000 16:01:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > I do no think that any "clarification" is needed for RFC 2560 to > this respect. The text is crystal clear and does not need to be > changed. With the risk or reiterating myself, I must insist that the wording of RFC2560 is not clear. There are two problems. One is that the ternary certificate status (good, revoked, unknown) is not orthogonal, i.e. good is not equivalent to !revoked. To dissect it: 'The "good" state indicates a positive response to the status inquiry.' -- so if the status inquiry was "is this certificate not revoked and issued" and the certificate was not revoked and not issued, "good" would not be correct. But clearly, "revoked" would not either. Note that it does not say "to the revocation inquiry". 'At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval.' -- yes, but the "minimum" answer is only reasonable if you don't ask (by request extensions or by convention) for any further assertions. To put it in other words, the responder is required by the protocol to make an assertion on the revocation status. 'Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate such as positive statement about issuance, validity, etc.' -- what about negative assertions on the same properties? Lack of the same extension in the response? How would you suggest to signal "this certificate is not revoked, but it has never been issued"? The other is the unclear wording of unknown. "doesn't know about the certificate requested" is in ISIS an assertion that the responder knows the certificate was never issued. Clearly, there seems to be differences in this group about this. And the different interpretation of "unknown" makes difference for the behaviour of the OCSP client. If "unknown" means that some property of the certificate is bad (like in ISIS the issuance) processing stops there. But if it means that this responder is unable or unwilling to answer your question about this specific certificate (for whatever reason) maybe you can try another responder, or the same responder later. I am not primarily after defining any extensions for extra assertions in the base protocol. I want to push out any assertions about other properties than revocation status from CertStatus into extensions. CertStatus should, in my mind, take one of "not revoked", "revoked" and "don't know". However, it does seem to me that many things you'd want to ask an OCSP responder have the same response structure as revocation ("good", "bad", "don't know"), so it could be beneficiary to define a common type for representing that kind of assertions. Simon. Simon Tardell, Software Architect, iD2 Technologies voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 simon.tardell@iD2tech.com, http://www.iD2tech.com Securing the Internet economy From owner-ietf-pkix@imc.org Wed Aug 9 10:49:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05692 for ; Wed, 9 Aug 2000 10:49:35 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA20228; Wed, 9 Aug 2000 07:44:44 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 9 Aug 2000 07:44:35 -0700 Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20176 for ; Wed, 9 Aug 2000 07:44:33 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA33836; Wed, 9 Aug 2000 16:52:59 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA41842; Wed, 9 Aug 2000 16:48:16 +0200 Message-ID: <39916F2D.8DFF9FAA@bull.net> Date: Wed, 09 Aug 2000 16:48:13 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Simon Tardell CC: ietf-pkix@imc.org Subject: Re: OCSP request References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Simon, > > I do no think that any "clarification" is needed for RFC 2560 to > > this respect. The text is crystal clear and does not need to be > > changed. > > With the risk or reiterating myself, I must insist that the wording of > RFC2560 is not clear. With the risk of repeating myself, I must insist that the wording of RFC2560 is crystal clear. > There are two problems. One is that the ternary > certificate status (good, revoked, unknown) is not orthogonal, i.e. good is > not equivalent to !revoked. To dissect it: > > 'The "good" state indicates a positive response to the status inquiry.' -- > so if the status inquiry was "is this certificate not revoked and issued" THIS IS NOT A CORRECT INQUIRY. The protocol overview says: "The Online Certificate Status Protocol (OCSP) enables applications to determine the (revocation) state of an identified certificate". Good means "not revoked", no less no more. Nothing about "issued" or "not issued". > and the certificate was not revoked and not issued, "good" would not be > correct. But clearly, "revoked" would not either. Note that it does not say > "to the revocation inquiry". > > 'At a minimum, this positive response indicates that the certificate is not > revoked, but does not necessarily mean that the certificate was ever issued > or that the time at which the response was produced is within the > certificate's validity interval.' -- yes, but the "minimum" answer is only > reasonable if you don't ask (by request extensions or by convention) for any > further assertions. To put it in other words, the responder is required by > the protocol to make an assertion on the revocation status. > > 'Response extensions may be used to convey additional information on > assertions made by the responder regarding the status of the certificate > such as positive statement about issuance, validity, etc.' -- what about > negative assertions on the same properties? Lack of the same extension in > the response? > > How would you suggest to signal "this certificate is not revoked, but it has > never been issued"? Very easy answer: The current status means "this certificate is not revoked". In an extension you can say whatever ADDITIONAL other information you want (including "issued, never issued"). > The other is the unclear wording of unknown. This is perfectly clear. If the server says "does not know", do not ask for what reasons it does not know. > "doesn't know about the > certificate requested" is in ISIS an assertion that the responder knows the > certificate was never issued. Clearly, there seems to be differences in this > group about this. And the different interpretation of "unknown" makes > difference for the behaviour of the OCSP client. If "unknown" means that > some property of the certificate is bad (like in ISIS the issuance) > processing stops there. But if it means that this responder is unable or > unwilling to answer your question about this specific certificate (for > whatever reason) maybe you can try another responder, or the same responder > later. > > I am not primarily after defining any extensions for extra assertions in the > base protocol. > I want to push out any assertions about other properties than > revocation status from CertStatus into extensions. CertStatus should, in my > mind, take one of "not revoked", "revoked" and "don't know". Good. So we strongly agree on this. > However, it does seem to me that many things you'd want to ask an OCSP > responder have the same response structure as revocation ("good", "bad", > "don't know"), so it could be beneficiary to define a common type for > representing that kind of assertions. Forget the "However, ..." and the rest of the text, since as indicated above, we strongly agree. Regards, Denis > Simon. > > Simon Tardell, Software Architect, iD2 Technologies > voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 > simon.tardell@iD2tech.com, http://www.iD2tech.com > Securing the Internet economy From owner-ietf-pkix@imc.org Wed Aug 9 11:09:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08105 for ; Wed, 9 Aug 2000 11:09:36 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA22171; Wed, 9 Aug 2000 08:04:21 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 9 Aug 2000 08:04:14 -0700 Received: from kevin.feste.es ([194.143.203.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22129 for ; Wed, 9 Aug 2000 08:04:12 -0700 (PDT) Received: from oficina (ladra.feste.es [194.143.203.155]) by kevin.feste.es (8.9.3/8.9.3) with SMTP id RAA18222 for ; Wed, 9 Aug 2000 17:10:08 +0200 Message-ID: <002f01c00214$9a79d110$0a02a8c0@interno> From: "Oscar Conesa" To: Subject: CP & CPS in CertificatePolicies Extension Date: Wed, 9 Aug 2000 17:15:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi, We are creating templates to certificates and we have some questions about the CertificatePolicies Extension. We have a general CPS and several particular Certificate Policy, one CP for every type of certificate. CPS -> http://www.feste.com/rep/cps.html (Not published yet) OID: 1.3.6.1.4.1.5239.1 CP1, Personal Certificates http://www.feste.com/rep/cp1.html (Not published yet) OID: 1.3.6.1.4.1.5239.2.1 (Why not?) CP2, Web Certificates http://www.feste.com/rep/cp2.html (Not published yet) OID: 1.3.6.1.4.1.5239.2.2 And others CPs ..... We have a hierarchy with a Root CA (version 1) and one Subordinate CA for every type of certificate. What is the best implementation of CertificatePolicies Extension? This is a good solution?: --------------------------- Subordinate CA --------------------------- certificatePolicies PolicyInformation policyIdentifier 1.3.6.1.4.1.5239.2.1 policyQualifiers PolicyQualifierInfo policyQualifierId id-qt-cps; qualifier cPSuri http://www.feste.com/rep/cps.html PolicyQualifierInfo policyQualifierId id-qt-cps; qualifier cPSuri http://www.feste.com/rep/cp1.html ------------------------- User ------------------------- certificatePolicies PolicyInformation policyIdentifier 1.3.6.1.4.1.5239.1 policyQualifiers PolicyQualifierInfo policyQualifierId id-qt-unotice; qualifier userNotice "Certificado Reconocido segun el Real Decreto Ley de Firma Electronica 14/1999 ...... " PolicyQualifierInfo policyQualifierId id-qt-cps; qualifier cPSuri http://www.feste.com/rep/cps.html PolicyQualifierInfo policyQualifierId id-qt-cps; qualifier cPSuri http://www.feste.com/rep/cp1.html Thank you very much for your help Oscar Conesa Dtor Tecnico de FESTE From owner-ietf-pkix@imc.org Wed Aug 9 11:33:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09162 for ; Wed, 9 Aug 2000 11:33:16 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA28000; Wed, 9 Aug 2000 08:28:18 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 9 Aug 2000 08:28:08 -0700 Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA27919 for ; Wed, 9 Aug 2000 08:28:07 -0700 (PDT) Received: by mystic1.trustcenter.de; id RAA27766; Wed, 9 Aug 2000 17:29:36 +0200 Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma027758; Wed, 9 Aug 00 17:28:53 +0200 Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id RAA05330; Wed, 9 Aug 2000 17:30:35 +0200 (MET DST) Message-Id: <3.0.5.32.20000809173037.04582580@localhost> X-Sender: jbr@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Aug 2000 17:30:37 +0200 To: Denis Pinkas , Simon Tardell From: Juergen Brauckmann Subject: Re: OCSP request Cc: ietf-pkix@imc.org In-Reply-To: <39916F2D.8DFF9FAA@bull.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 16:48 09.08.00 +0200, Denis Pinkas wrote: >THIS IS NOT A CORRECT INQUIRY. The protocol overview says: "The >Online Certificate Status Protocol (OCSP) enables applications to >determine the (revocation) state of an identified certificate". Good >means "not revoked", no less no more. Nothing about "issued" or "not >issued". Well, chapter 2.2 says The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued... If good never means "issued", than it should not say "At a minimum" and "not necessarily". The text may be correct, but it is possible to misinterpret it. >> The other is the unclear wording of unknown. > >This is perfectly clear. If the server says "does not know", do not >ask for what reasons it does not know. It is not described in rfc2560 what the client should do if it receives "unknown" (try later? try another responder? Tell the user that it got "unknown"?). It is not described when or why a server might give "unknown". "Don't ask" may be adequate for a client programm, but is definitely not adequate for people developing an OCSP responder. Regards, Juergen From owner-ietf-pkix@imc.org Wed Aug 9 11:41:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09610 for ; Wed, 9 Aug 2000 11:41:28 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA29756; Wed, 9 Aug 2000 08:36:33 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 9 Aug 2000 08:36:31 -0700 Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29725 for ; Wed, 9 Aug 2000 08:36:30 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 08:31:29 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2B417FB@seine.valicert.com> From: Ambarish Malpani To: "'Denis Pinkas'" , Simon Tardell Cc: ietf-pkix@imc.org Subject: RE: OCSP request Date: Wed, 9 Aug 2000 08:31:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I agree completely. Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: Wednesday, August 09, 2000 7:48 AM > To: Simon Tardell > Cc: ietf-pkix@imc.org > Subject: Re: OCSP request > > > Simon, > > > > I do no think that any "clarification" is needed for RFC 2560 to > > > this respect. The text is crystal clear and does not need to be > > > changed. > > > > With the risk or reiterating myself, I must insist that the > wording of > > RFC2560 is not clear. > > With the risk of repeating myself, I must insist that the wording of > RFC2560 is crystal clear. > > > There are two problems. One is that the ternary > > certificate status (good, revoked, unknown) is not > orthogonal, i.e. good is > > not equivalent to !revoked. To dissect it: > > > > 'The "good" state indicates a positive response to the > status inquiry.' -- > > so if the status inquiry was "is this certificate not > revoked and issued" > > THIS IS NOT A CORRECT INQUIRY. The protocol overview says: "The > Online Certificate Status Protocol (OCSP) enables applications to > determine the (revocation) state of an identified certificate". Good > means "not revoked", no less no more. Nothing about "issued" or "not > issued". > > > and the certificate was not revoked and not issued, "good" > would not be > > correct. But clearly, "revoked" would not either. Note that > it does not say > > "to the revocation inquiry". > > > > 'At a minimum, this positive response indicates that the > certificate is not > > revoked, but does not necessarily mean that the certificate > was ever issued > > or that the time at which the response was produced is within the > > certificate's validity interval.' -- yes, but the "minimum" > answer is only > > reasonable if you don't ask (by request extensions or by > convention) for any > > further assertions. To put it in other words, the responder > is required by > > the protocol to make an assertion on the revocation status. > > > > 'Response extensions may be used to convey additional information on > > assertions made by the responder regarding the status of > the certificate > > such as positive statement about issuance, validity, etc.' > -- what about > > negative assertions on the same properties? Lack of the > same extension in > > the response? > > > > How would you suggest to signal "this certificate is not > revoked, but it has > > never been issued"? > > Very easy answer: > The current status means "this certificate is not revoked". > In an extension you can say whatever ADDITIONAL other information > you want (including "issued, never issued"). > > > The other is the unclear wording of unknown. > > This is perfectly clear. If the server says "does not know", do not > ask for what reasons it does not know. > > > "doesn't know about the > > certificate requested" is in ISIS an assertion that the > responder knows the > > certificate was never issued. Clearly, there seems to be > differences in this > > group about this. And the different interpretation of > "unknown" makes > > difference for the behaviour of the OCSP client. If > "unknown" means that > > some property of the certificate is bad (like in ISIS the issuance) > > processing stops there. But if it means that this responder > is unable or > > unwilling to answer your question about this specific > certificate (for > > whatever reason) maybe you can try another responder, or > the same responder > > later. > > > > I am not primarily after defining any extensions for extra > assertions in the > > base protocol. > > > > I want to push out any assertions about other properties than > > revocation status from CertStatus into extensions. > CertStatus should, in my > > mind, take one of "not revoked", "revoked" and "don't know". > > Good. So we strongly agree on this. > > > However, it does seem to me that many things you'd want to > ask an OCSP > > responder have the same response structure as revocation > ("good", "bad", > > "don't know"), so it could be beneficiary to define a > common type for > > representing that kind of assertions. > > Forget the "However, ..." and the rest of the text, since as > indicated above, we strongly agree. > > Regards, > > Denis > > > Simon. > > > > Simon Tardell, Software Architect, iD2 Technologies > > voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 > > simon.tardell@iD2tech.com, http://www.iD2tech.com > > Securing the Internet economy > From owner-ietf-pkix@imc.org Wed Aug 9 11:51:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10157 for ; Wed, 9 Aug 2000 11:51:27 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA00443; Wed, 9 Aug 2000 08:45:16 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 9 Aug 2000 08:45:14 -0700 Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA00409 for ; Wed, 9 Aug 2000 08:45:13 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 08:40:11 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2B417FC@seine.valicert.com> From: Ambarish Malpani To: "'Juergen Brauckmann'" , Denis Pinkas , Simon Tardell Cc: ietf-pkix@imc.org Subject: RE: OCSP request Date: Wed, 9 Aug 2000 08:40:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C00218.19C39976" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C00218.19C39976 Content-Type: text/plain; charset="iso-8859-1" Juergen, We did have a discussion about what kinds of questions OCSP should answer when we were writing the RFC and the concensus was that we were only providing the status of the certificate. I am including most of the mails and different points of view about this topic when the discussion was going on. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Juergen Brauckmann [mailto:brauckmann@trustcenter.de] > Sent: Wednesday, August 09, 2000 8:31 AM > To: Denis Pinkas; Simon Tardell > Cc: ietf-pkix@imc.org > Subject: Re: OCSP request > > > At 16:48 09.08.00 +0200, Denis Pinkas wrote: > >THIS IS NOT A CORRECT INQUIRY. The protocol overview says: "The > >Online Certificate Status Protocol (OCSP) enables applications to > >determine the (revocation) state of an identified certificate". Good > >means "not revoked", no less no more. Nothing about "issued" or "not > >issued". > > Well, chapter 2.2 says > The "good" state indicates a positive response to the > status inquiry. > At a minimum, this positive response indicates that the certificate > is not revoked, but does not necessarily mean that the certificate > was ever issued... > > If good never means "issued", than it should not say "At a > minimum" and > "not necessarily". > > The text may be correct, but it is possible to misinterpret it. > > >> The other is the unclear wording of unknown. > > > >This is perfectly clear. If the server says "does not know", do not > >ask for what reasons it does not know. > > It is not described in rfc2560 what the client should do if > it receives > "unknown" (try later? try another responder? Tell the user that it got > "unknown"?). It is not described when or why a server might > give "unknown". > "Don't ask" may be adequate for a client programm, but is > definitely not > adequate for people developing an OCSP responder. > > Regards, > Juergen > ------_=_NextPart_000_01C00218.19C39976 Content-Type: message/rfc822 Content-Description: Re: [IETF-PKIX] OCSP Status Information on a Certificate Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2331DD0@seine.valicert.com> From: "David P. Kemp" Sender: owner-ietf-pkix@imc.org To: "'ietf-pkix@imc.org'" Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate Date: Tue, 28 Apr 1998 12:32:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mozilla-Status: 2013 X-Sun-Charset: US-ASCII X-POP3-Rcpt: ambarish@arctic Content-Type: text/plain; charset="iso-8859-1" > From: Marc Branchaud > > So I guess (unless I've forgotten someone) that the tally now stands at: > > Issued / Revoked / Expired == 1 > Revoked only == 0 > Abstain == 1 > Add one for Revoked only, or add a new category Revoked / Expired. As before, I don't see any rationale for Issued. Expired could be useful if one assumes that the client does not have a reliable clock, that the responder does have access to a trusted time source, and that the RP uses OCSP for every verification. Last month my wife's PC started dating files sometime in 2003 for no apparent reason. The lithium battery was fine, the clock has been fine since we reset it, and the machine doesn't have a modem installed so it's never been exposed to hackers on the net. Gamma rays, I guess. Anyway, OCSP Expired status may be useful. ------_=_NextPart_000_01C00218.19C39976 Content-Type: message/rfc822 Content-Description: Re: [IETF-PKIX] OCSP Status Information on a Certificate Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2331DBD@seine.valicert.com> From: Paul Hoffman / IMC Sender: "IETF X.509-based public key infrastructure mailing list" Reply-To: "IETF X.509-based public key infrastructure mailing list" To: "'IETF-PKIX@LISTS.TANDEM.COM'" Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate Date: Fri, 17 Apr 1998 14:01:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mozilla-Status: 2011 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.327 (Beta) X-POP3-Rcpt: ambarish@arctic X-Sender: paulh@mail.imc.org Content-Type: text/plain; charset="iso-8859-1" I agree with David Kemp's analysis and take back my suggestion that wasIssued be mandatory. --Paul Hoffman, Director --Internet Mail Consortium ------_=_NextPart_000_01C00218.19C39976 Content-Type: message/rfc822 Content-Description: Re: [IETF-PKIX] OCSP Status Information on a Certificate Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2331DBC@seine.valicert.com> From: SGalperin Sender: "IETF X.509-based public key infrastructure mailing list" Reply-To: "IETF X.509-based public key infrastructure mailing list" To: "'IETF-PKIX@LISTS.TANDEM.COM'" Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate Date: Fri, 17 Apr 1998 10:54:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mozilla-Status: 2011 X-Mailer: AOL 3.0 16-bit for Windows sub 38 X-POP3-Rcpt: ambarish@arctic Content-Type: text/plain; charset="iso-8859-1" In a message dated 98-04-17 12:31:04 EDT, you write: > > At 08:48 AM 4/17/98 -0700, you wrote: > >And in the event a client receives {is revoked, not issued}, which > >dominates? Similarly, {not revoked, not issued}. I remain unconvinced > this > >is no problem. > > To the client, "not issued" is always more important than revoked or not > revoked. We can put that in the OCSP spec. > > >As soon as OCSP clients are out there in any volume, there > >are those who will seek to determine the client's behavior in fringe cases. > > I fully agree. That's why I'm I don't think that issued/not issued should > be a MAY: I think it has to be a MUST. We can be sure that some clients > will blow the comparison unless they are always told whether or not the > cert was even issued. > Are we talking about fat OCSP client here ? Does the OCSP client in this case have full certificate chain ? Can we safely assume that fat OCSP client will need to verify signatures on the chain first, validity and other X509v3 constraints and only then submit OCSP request for status of every certificate in the chain ? If this is so then, essentially, OCSP client is already in the possession of the well-formed certificate signed by the (indirectly or directly) trusted CA key. In these circumstances receiving an anwer "not issued" may only mean that CA key is compromised and "unathorized" certificate has been signed. But if someone has the CA key and can sign anything with it (including "unathorized" certificates) then that someone can also make sure that "unathorized" certificate has the same serial number as one of "authorized" and as long as we only send serial number to identify a certificate in OCSP request the substitution of the "authorized" cert with "unathorized" one will be unnoticed. This makes "never issued" somewhat useless for fat OCSP clients. Is this reasoning wrong ? Also since CA archiving capacity is always finiteand we also talking about allowing "historical" OCSP queries "never issued" will have to be replaced with "info unavailable" at least in some cases. This further redices the value of "never issued" status. --Slava Galperin ------_=_NextPart_000_01C00218.19C39976 Content-Type: message/rfc822 Content-Description: Re: [IETF-PKIX] OCSP Status Information on a Certificate Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2331DBA@seine.valicert.com> From: "David P. Kemp" Sender: "IETF X.509-based public key infrastructure mailing list" Reply-To: "IETF X.509-based public key infrastructure mailing list" To: "'IETF-PKIX@LISTS.TANDEM.COM'" Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate Date: Fri, 17 Apr 1998 10:31:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mozilla-Status: 2011 X-Sun-Charset: US-ASCII X-POP3-Rcpt: ambarish@arctic Content-Type: text/plain; charset="iso-8859-1" > From: Paul Hoffman / IMC > > To the client, "not issued" is always more important than revoked or not > revoked. We can put that in the OCSP spec. > > >As soon as OCSP clients are out there in any volume, there > >are those who will seek to determine the client's behavior in fringe cases. > > I fully agree. That's why I'm I don't think that issued/not issued should > be a MAY: I think it has to be a MUST. We can be sure that some clients > will blow the comparison unless they are always told whether or not the > cert was even issued. I disagree that an Issued bit should be a MUST. For that matter, I don't see that it even needs to be a MAY in OCSP, but others seem to want it for some reason. If you have a certificate for which the signature verifies, you have prima facie evidence that: 1) the certificate was issued, or 2) the CA's private key was compromised, or 3) the signature algorithm is broken. In the latter two cases, all bets are off and OCSP isn't going to help -- why would you trust a signed OCSP response any more than a signed certificate? In the first case, you know the answer before you even ask the question. If you have a certificate for which the signature does not verify, what are you going to do with it, regardless of OCSP's claim that it has or has not been issued? And if you don't have a certificate and are just trolling the OCSP server by issuer/serial, subject name, or some other search criteria, why should it feel obliged to disclose which guesses are valid? Dave Kemp ------_=_NextPart_000_01C00218.19C39976 Content-Type: message/rfc822 Content-Description: Re: [IETF-PKIX] OCSP Status Information on a Certificate Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2331DB9@seine.valicert.com> From: Marc Branchaud Sender: "IETF X.509-based public key infrastructure mailing list" Reply-To: "IETF X.509-based public key infrastructure mailing list" To: "'IETF-PKIX@LISTS.TANDEM.COM'" Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate Date: Fri, 17 Apr 1998 09:52:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mozilla-Status: 2011 X-Mailer: exmh version 2.0gamma 1/27/96 X-POP3-Rcpt: ambarish@arctic Content-Type: text/plain; charset="iso-8859-1" -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii Michael Myers scrawled: > > And in the event a client receives {is revoked, not issued}, which I think you mean {is revoked, issued} here... > dominates? Similarly, {not revoked, not issued}. I remain unconvinced this > is no problem. As soon as OCSP clients are out there in any volume, there > are those who will seek to determine the client's behavior in fringe cases. > I agree that the implications are not trivial. For one thing, as I've said, a responder working solely with CRL information can not determine a certificate's existance if the cert has not been revoked. One bit is not enough to capture the semantics. Marc +------------------------------------------------------------------------+ Marc Branchaud \/ Chief PKI Architect /\CERT INTERNATIONAL INC. marcnarc@xcert.com PKI References page: www.xcert.com 604-640-6227 www.xcert.com/~marcnarc/PKI/ +------------------------------------------------------------------------+ PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBNTeI3lrdFXNdDxPlAQFnJQL8Cnti/rIncZp1o3IFfy2XeZPHQXluc8FO 8+KNr2FzAJQPeXWGovrZpp+6LoMRSJ1b+TWqLMdNSqlGin/CJtx2iHg6RkWgik40 b5gADHFKTv1BratoNpS4ZB07C9rp8/3d =Rxae -----END PGP SIGNATURE----- ------_=_NextPart_000_01C00218.19C39976 Content-Type: message/rfc822 Content-Description: Re: [IETF-PKIX] OCSP Status Information on a Certificate Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2331DC3@seine.valicert.com> From: Andreas Berger Sender: owner-ietf-pkix@imc.org To: 'pkix' Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate Date: Tue, 21 Apr 1998 02:40:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mozilla-Status: 2011 X-Mailer: Mozilla 4.04 [en] (X11; U; Linux 2.0.30 i586) X-POP3-Rcpt: ambarish@arctic Content-Type: text/plain; charset="iso-8859-1" Paul Hoffman / IMC wrote: > > At 08:48 AM 4/17/98 -0700, you wrote: > >And in the event a client receives {is revoked, not issued}, which > >dominates? Similarly, {not revoked, not issued}. I remain unconvinced this > >is no problem. > > To the client, "not issued" is always more important than revoked or not > revoked. We can put that in the OCSP spec. > > >As soon as OCSP clients are out there in any volume, there > >are those who will seek to determine the client's behavior in fringe cases. > > I fully agree. That's why I'm I don't think that issued/not issued should > be a MAY: I think it has to be a MUST. We can be sure that some clients > will blow the comparison unless they are always told whether or not the > cert was even issued. > > --Paul Hoffman, Director > --Internet Mail Consortium Paul, I disagree. The issued/not issued flag can only be answered by a small set of OCSP responders. Let's take - for example - a company that operates an OCSP responder of some of the most frequently used CAs in the world. It load their CRLs to reduce communication cost and offers these "CRLs on-line" to the internal client software (thus lowering the maintainance cost to distribute CRLs to all clients). Given a specific certificate, such an OCSP responder can only answer the question of revocation (revoked/not revoked) on the basis of the CRL (so revoked is: on the list, not revoked is: not on the list). So probably we need some kind of "don't know" of the OCSP responder. Regarding the question above: when a certificate was "not issued" this is a no-go for the verification process. I think that we could drop any other answers if the certificate was never issued. This is different for "issued: don't know" and "issued: yes". Andreas -- Erst kommt das Fressen, dann kommt die Moral -- Bertolt Brecht ------_=_NextPart_000_01C00218.19C39976 Content-Type: message/rfc822 Content-Description: Re: [IETF-PKIX] OCSP Status Information on a Certificate Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2331DB2@seine.valicert.com> From: Denis Pinkas Sender: "IETF X.509-based public key infrastructure mailing list" Reply-To: Denis.Pinkas@bull.net To: "'IETF-PKIX@LISTS.TANDEM.COM'" Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate Date: Fri, 17 Apr 1998 14:26:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mozilla-Status: 2011 X-Mailer: Mozilla 3.01 [fr] (Win16; I) X-POP3-Rcpt: ambarish@arctic Content-Type: text/plain; charset="iso-8859-1" Andreas, Your conclusion is: " I think we should not restrict OCSP in its semantics to CRL like semantics." I may agree with this. However, I think we should not mandate more than what is available by access to CRL information only. This means that we have to distinguish between a set of mandatory status and a set of optional status. > > Ambarish Malpani wrote: > > > > > Here is a list of the different kinds of status information that an OCSP > > > responder may want to return: > > > > > > 1. Revocation status of a certificate > > > - revoked > > > - on hold > > > - not revoked > > > - don't know about this CA > > > - know about this CA, but not about this cert (??? I am not sure I > > > think this state should ever be returned, but this corresponds > > > to the state where the responder is looking up the CA's database > > > and can't find this entry in the database. Mike, I believe you > > > think this is an important state - is that correct?) > > > > The later would mean that the OCSP responder has access to more > > information than just the CRL. I do not think that this response > > usefull for the client. If there were good arguments for keeping it (I > > have not been convinced by the arguments from Paul), then this status > > should be optional (no guarantee to get it back at any time). > > Sorry that I bring that up again: the answer about knowing about a CA > but not about the referenced certificate would be a good one for use of > OCSP in the German Signature Law, where such a service is required. As long as this is optional. > Short overview: When asking a CA for the status of a certificate, it > answer with two booleans: certificate was issued / was not issued and > certifcate is revoked / is not revoked (the latter only when the > certificate was issued). The signature key is related to the CA but is > not the CAs certifcate signing key. More exactly: it MUST issue one booolean : certificate is revoked / is not revoked it MAY issue another boolean: certificate was issued / was not issued > What we then need is a clarification between "not revoked": Let us > assume that an OCSP responder answers with "not revoked" based on a > decision of a CRLs where the certificate is NOT listed. This is a > different answer from "not revoked and I know about the certificate", > perhaps looked up on a CA database (see 3). > > > > 2. Expiration status of a certificate > > > - not yet valid (will be valid in the future) > > > - valid (in its validity period) > > > - expired > > > - don't know about the expiration status > > I think we have to rephrase that: not yet valid - certificate validity > period begins after the designated point in time. We will have to support some date as originally requested by Stephen. > > > 3. Issued status of the certificate > > > - never issued (no cert with this serial number was ever issued by > > > this CA) > > > - issued > > > - don't know if it was ever issued > > > > > My take on this issue: I believe OCSP is just a revocation status > > > protocol, so we should restrict the return status to just revoked, > > > onHold, notRevoked, and dontKnowAboutThisCA. This would leave the > > > syntax of the protocol simple and the semantics very clear - OCSP > > > basically returns the same information that you would get if you > > > had a CRL from the CA at the instant of the response (NOTE: I am > > > NOT implying that a CRL is ever issued). > > > > Agreed. Let us keep it simple. > > I think we should not restrict OCSP in its semantics to CRL like > semantics. > > Andreas See above. Regards, Denis -- Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net 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 ------_=_NextPart_000_01C00218.19C39976 Content-Type: message/rfc822 Content-Description: Re: [IETF-PKIX] OCSP Status Information on a Certificate Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2331DA4@seine.valicert.com> From: Marc Branchaud Sender: "IETF X.509-based public key infrastructure mailing list" Reply-To: "IETF X.509-based public key infrastructure mailing list" To: "'IETF-PKIX@LISTS.TANDEM.COM'" Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate Date: Tue, 14 Apr 1998 15:29:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mozilla-Status: 2011 X-Mailer: exmh version 2.0gamma 1/27/96 X-POP3-Rcpt: ambarish@arctic Content-Type: text/plain; charset="iso-8859-1" -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii Michael Myers scrawled: > > A related question: > > Given Marc's proposal for separate fields, should we provide guidance > towards the uniform resolution of ambiguous states in a multi-valued > response? I'm concerned about this protocol otherwise introducing into > clients exploitable behavior caused by less than full coverage of error > cases. > That's a valid concern, and I believe some guidance is required. As a start, it might help to list those combinations which should be considerd as malformed. First, recall the three status vectors: Revocation Status Expiration Status Issued Status ----------------- ----------------- ------------- revoked not yet valid issued on hold valid never issued not revoked expired unknown unknown CA unknown unknown cert - If Issued Status is "never issued" then the revocation status MUST be "unknown cert" and the expiration status MUST be "unknown", otherwise the response is malformed. If the responder knows that the cert was never issued, then the other values are indeterminable. Note that a responder can't determine if a certificate was never issued using only CRLs, so a responder working with CRLs only will never create a "never issued" response. - If Issued Status is "unknown" then the response is well-formed only if the revocation status is either "not revoked" or "unknown CA". This is because if the cert is "revoked" or "on hold" then it is listed in a CRL, and so the responder knows the cert was issued regardless of whether it is using CRLs or has direct access to the CA's database. Also, if Issued Status is "unknown" then "unknown cert" implies "unknown CA". Either the responder couldn't find a CRL or database for the cert's CA, or the responder has a CRL from the CA but the cert isn't listed (so it's really "not revoked"). - If Issued Status is "issued" then use the following table to determine if the response is malformed ("bad") or acceptable ("OK"). Revocation ||----------------- Expiration status --------------- status || not yet valid | valid | expired | unknown =============||=================|=========|===========|=========== revoked || OK | OK | OK | OK on hold || bad | OK | OK | OK not revoked || OK | OK | OK | OK unknown CA || bad | bad | bad | bad unknown cert || bad | bad | bad | bad The only way for a responder to know with any certainty that a cert has been issued is if it has direct access to the CA's database or if the cert is listed on a CRL. In either case, responding with "unknown CA" or "unknown cert" would be wrong. "Unknown cert" would really mean "never issued" (if the responder had direct access to a CA's database) or "not revoked" (if the responder were using CRLs). Also, I don't believe that a cert would be marked "on hold" before it became valid. Either it wouldn't appear on a CRL, or it wouldn't be marked as "on hold" in the CA's database. Hence the single "bad" entry in the "on hold" row. I'm willing to admit I'm wrong, though. "On hold" has always been a semantic riddle to me... All of this is only to determine if the client should reject a response out of hand. The behaviour of a client upon accepting a response -- whether or not it should accept the cert -- is a matter for the client's local policies. One thing this exercise has showed me is that "unknown cert" is really a useless response value, since it is either bogus or subsumed by other values (like "unknown CA"). Marc +------------------------------------------------------------------------+ Marc Branchaud \/ Chief PKI Architect /\CERT INTERNATIONAL INC. marcnarc@xcert.com PKI References page: www.xcert.com 604-640-6227 www.xcert.com/~marcnarc/PKI/ +------------------------------------------------------------------------+ PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBNTPjPlrdFXNdDxPlAQFtiQL/RRrfIPdX245xSp8YfQXWrj3s7bI4TuYA oyjziEucd8gRIUPPs10xro4WqFgbxBNNQs5B1L1JE2KIyc4DRBitIaTP32pjBDBg qrvistWEbGn8/SkpUtVswVaEVpRavpJh =TIKb -----END PGP SIGNATURE----- ------_=_NextPart_000_01C00218.19C39976 Content-Type: message/rfc822 Content-Description: [IETF-PKIX] OCSP Status Information on a Certificate Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2331D8E@seine.valicert.com> From: Ambarish Malpani Sender: "IETF X.509-based public key infrastructure mailing list" Reply-To: "IETF X.509-based public key infrastructure mailing list" To: "'IETF-PKIX@LISTS.TANDEM.COM'" Subject: [IETF-PKIX] OCSP Status Information on a Certificate Date: Mon, 13 Apr 1998 18:04:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mozilla-Status: 8001 X-Mailer: Mozilla 4.01 [en] (WinNT; U) X-POP3-Rcpt: ambarish@arctic Content-Type: text/plain; charset="iso-8859-1" Here is a list of the different kinds of status information that an OCSP responder may want to return: 1. Revocation status of a certificate - revoked - on hold - not revoked - don't know about this CA - know about this CA, but not about this cert (??? I am not sure I think this state should ever be returned, but this corresponds to the state where the responder is looking up the CA's database and can't find this entry in the database. Mike, I believe you think this is an important state - is that correct?) 2. Expiration status of a certificate - not yet valid (will be valid in the future) - valid (in its validity period) - expired - don't know about the expiration status 3. Issued status of the certificate - never issued (no cert with this serial number was ever issued by this CA) - issued - don't know if it was ever issued My take on this issue: I believe OCSP is just a revocation status protocol, so we should restrict the return status to just revoked, onHold, notRevoked and dontKnowAboutThisCA. This would leave the syntax of the protocol simple and the semantics very clear - OCSP basically returns the same information that you would get if you had a CRL from the CA at the instant of the response (NOTE: I am NOT implying that a CRL is ever issued). However, if the consensus of the group is that it is important that all three types of states be returned, I would prefer there to be 3 separate state fields, one for each of the different statii. This would allow us to add more states in the future (e.g. whether this certificate can be used for a specific kind of operation, or maybe some information about the CA of this cert) without affecting these basic status fields. What do the rest of you on the list feel about this issue: - Should OCSP support one or more of these statuses? - If we support multiple of these states, should we define separate fields, or should we merge all states into one field? Ambarish -- --------------------------------------------------------------------- Ambarish Malpani Architect (650) 849-9880 ValiCert, Inc. ambarish@valicert.com 3160 W. Bayshore Road http://www.valicert.com Palo Alto, CA 94303 ------_=_NextPart_000_01C00218.19C39976-- From owner-ietf-pkix@imc.org Wed Aug 9 12:00:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10627 for ; Wed, 9 Aug 2000 12:00:02 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA00930; Wed, 9 Aug 2000 09:00:19 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 9 Aug 2000 09:00:15 -0700 Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00900 for ; Wed, 9 Aug 2000 09:00:14 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 08:50:12 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2B417FE@seine.valicert.com> From: Ambarish Malpani To: "'TAKIGUCHI Naruhito'" , ietf-pkix@imc.org Subject: RE: CRL number in CRL and ARL Date: Wed, 9 Aug 2000 08:50:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hi Naruhito, If you are creating CRLs and ARLs that are not complete (i.e. don't contain all the entries the other does), it is very important that you use the CRLDP method of doing it. Put in CRLDP extensions in the certificates and IDP (Issuing Distribution Point) extensions in your CRLs/ARLs. If you don't use the CRLDP mechanism, you run the risk of having a bunch of applications misbehave with your CRLs. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: TAKIGUCHI Naruhito [mailto:takiguti@fjh.se.fujitsu.co.jp] > Sent: Tuesday, August 08, 2000 8:13 PM > To: ietf-pkix@imc.org > Subject: CRL number in CRL and ARL > > > Hi, all. > > I have a question about the cRLNumber extension. > > For example, a CA issues CRL(end-entity certificate revocation list) > and ARL(CA certificate revocation list). > Which is correct (a) or (b) ? > > (a) In first CRL and ARL, the CRL number is 0. > In next CRL and ARL, the CRL number is 1. > > In other words, CRL and ARL have same value of the CRL number. > The CRL number is a monotonically increasing sequence number > for each CRL scope. > > (b) In first CRL, the CRL Number is 0. > In first ARL, the CRL Number is 1. > In next CRL, the CRL number is 2. > In next ARL, the CRL number is 3. > > In other words, the CRL number is monotonically increasing > sequence number for each CA. > > Could anyone advice me? > > Thanks in advance. > > ----- > Naruhito TAKIGUCHI > FUJITSU HOKURIKU SYSTEMS LTD. > From owner-ietf-pkix@imc.org Wed Aug 9 23:03:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27085 for ; Wed, 9 Aug 2000 23:03:55 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA27702; Wed, 9 Aug 2000 20:01:02 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 9 Aug 2000 20:00:45 -0700 Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA27636 for ; Wed, 9 Aug 2000 20:00:44 -0700 (PDT) Received: from m3.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0006-Fujitsu Gateway) id LAA28304 for ; Thu, 10 Aug 2000 11:59:28 +0900 (JST) (envelope-from takiguti@fjh.se.fujitsu.co.jp) Received: from nic10.fjh.se.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.9.3/3.7W-0008-Fujitsu Domain Master) id LAA08788; Thu, 10 Aug 2000 11:59:27 +0900 (JST) Received: from anakin (anakin.fjh.se.fujitsu.co.jp [10.131.201.130]) by nic10.fjh.se.fujitsu.co.jp (8.9.3+3.2W/3.7W) with ESMTP id LAA22520 for ; Thu, 10 Aug 2000 11:59:25 +0900 (JST) Date: Thu, 10 Aug 2000 11:59:24 +0900 From: TAKIGUCHI Naruhito To: ietf-pkix@imc.org Subject: Re: CRL number in CRL and ARL In-Reply-To: <27FF4FAEA8CDD211B97E00902745CBE2B417FE@seine.valicert.com> References: <27FF4FAEA8CDD211B97E00902745CBE2B417FE@seine.valicert.com> Message-Id: <20000810111811.6BBF.TAKIGUTI@fjh.se.fujitsu.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00 (beta 25) Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Ambarish, > If you are creating CRLs and ARLs that are not complete (i.e. > don't contain all the entries the other does), it is very > important that you use the CRLDP method of doing it. Put in > CRLDP extensions in the certificates and IDP (Issuing Distribution > Point) extensions in your CRLs/ARLs. > > If you don't use the CRLDP mechanism, you run the risk of having > a bunch of applications misbehave with your CRLs. Thank you. I agree with your advice. But, I'm going to discussion about the CRL number. I think that the method (a)(the CRL number is a sequece number for each CRL scope) is better than the method (b) for a relying party. RFC2459 and son of RFC2459 describe following : The CRL number is a non-critical CRL extension which conveys a mono- tonically increasing sequence number for each CRL issued by a CA. Does "for each CRL issued by a CA" sentence mean the method (b) ? Thanks in advance. > Regards, > Ambarish > > --------------------------------------------------------------------- > Ambarish Malpani > Architect 650.567.5457 > ValiCert, Inc. ambarish@valicert.com > 339 N. Bernardo Ave. http://www.valicert.com > Mountain View, CA 94043 > > > > -----Original Message----- > > From: TAKIGUCHI Naruhito [mailto:takiguti@fjh.se.fujitsu.co.jp] > > Sent: Tuesday, August 08, 2000 8:13 PM > > To: ietf-pkix@imc.org > > Subject: CRL number in CRL and ARL > > > > > > Hi, all. > > > > I have a question about the cRLNumber extension. > > > > For example, a CA issues CRL(end-entity certificate revocation list) > > and ARL(CA certificate revocation list). > > Which is correct (a) or (b) ? > > > > (a) In first CRL and ARL, the CRL number is 0. > > In next CRL and ARL, the CRL number is 1. > > > > In other words, CRL and ARL have same value of the CRL number. > > The CRL number is a monotonically increasing sequence number > > for each CRL scope. > > > > (b) In first CRL, the CRL Number is 0. > > In first ARL, the CRL Number is 1. > > In next CRL, the CRL number is 2. > > In next ARL, the CRL number is 3. > > > > In other words, the CRL number is monotonically increasing > > sequence number for each CA. > > > > Could anyone advice me? > > > > Thanks in advance. > > > > ----- > > Naruhito TAKIGUCHI > > FUJITSU HOKURIKU SYSTEMS LTD. > > ----- Naruhito TAKIGUCHI FUJITSU HOKURIKU SYSTEMS LTD. From owner-ietf-pkix@imc.org Wed Aug 9 23:11:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27120 for ; Wed, 9 Aug 2000 23:11:38 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA28696; Wed, 9 Aug 2000 20:11:53 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 9 Aug 2000 20:11:25 -0700 Received: from bird (sero.mf.ejf.hu [193.225.84.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA28140; Wed, 9 Aug 2000 20:05:54 -0700 (PDT) From: nan@quotepool.com Received: from mxspr.mail.accesscomp1.net (host10.4ua.com) by bird with SMTP (1.39.111.2/16.2) id AA067490053; Thu, 10 Aug 2000 03:14:13 +0200 Date: Thu, 10 Aug 2000 03:14:13 +0200 Message-Id: <965875852.cqcoqcngetrm@cqcoqcngetrm.mail.accesscomp1.net> To: cqcoqcngetrm@accesscomp1.net Reply-To: nan@quotepool.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en Content-Type: text/html; Charset=us-ascii Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Are you looking for a J.O.B. or Financial Freedom? vyjxg Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit

93% WHO RESPOND TO MY AD DON'T MAKE THE CUT!
(Only highly motivated people should call)

I'm dead serious! Now let me tell you why...

Most people don't have drive! They sit around waiting for something to happen.
They see that other people have nice homes, new cars, and MONEY, but why can't they?
They basically feel sorry for themselves, and I can't help these people!

Another reason people are not qualified...

They are skeptical. BUT, the truth is, they are skeptical of themselves!
They don't have the courage to break their routine.
They are comfortable with their set hours, their set pay, and their set future.
I was not comfortable with someone controlling my future,
and I'm not comfortable working with people who are!

STOP
If you are anything like the above, we won't be able to work together!

WHAT DO THE 7% WHO DO MAKE THE CUT DISCOVER?!

People I select through an "interview like" process are forever changed!
They are opened to a world around them that they didn't know existed.
In fact, it's a world that has existed around them their whole lives,
but was purposely hidden from them!


How would you like to...

- Drastically reduce personal, business and capital gains taxes?
- Protect all assets from any form of seizure, liens, or judgments?
- Create a six figure income every 4 months?

How about...

Restoring and preserving complete personal and financial privacy?
Amassing personal wealth, multiplying it and protecting it?
Realizing a 3 to 6 times greater return on your money?
Legally making yourself and your assets completely judgment-proof,
lien-proof, divorce-proof, attorney-proof, IRS-proof?
I could go on...

TAKE A SERIOUS LOOK AT YOUR LIFE

Do you think you are paid what you are worth?
Will you be set to retire in the next few years?
Do you control the course of your day? ...your life?

The fact is we have many people in our enterprise that earn over 50K per month
from the privacy of their own homes, and are retiring in 2 to 3 years (wealthy)
and have total freedom - both personal and financial!

Many have been conditioned to believe it must be illegal, immoral or unethical
to ever earn any real profits from our efforts.

The sad truth is, it's been designed that way by the ultra-rich
and ultra-powerful since before any of us were born!

Who am I?

I'm a BIG thinker, a BIG dreamer, and I believe that I deserve the best that life has to offer.
I answered an ad much like the one you are reading now,
and was eager to hear what it was about.

I knew that I couldn't invest only a few bucks and spend an hour or two
per week to achieve the results I was looking for. I found the right information
and now I control my own destiny!

If you are interested in radically changing your thoughts and your financial future,
I invite you to call TOLL FREE:

1 800 707 4817

My name is Krystina, and I look forward to working with some of you!

* REMEMBER *

I can't do it for you, but I can show you exactly how I do it.
It's as simple as that!

From owner-ietf-pkix@imc.org Thu Aug 10 01:43:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04807 for ; Thu, 10 Aug 2000 01:43:24 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA10097; Wed, 9 Aug 2000 22:43:36 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 9 Aug 2000 22:43:29 -0700 Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA10056 for ; Wed, 9 Aug 2000 22:43:27 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 22:33:20 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2B41816@seine.valicert.com> From: Ambarish Malpani To: "'TAKIGUCHI Naruhito'" , ietf-pkix@imc.org Subject: RE: CRL number in CRL and ARL Date: Wed, 9 Aug 2000 22:33:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe If you are using CRLDPs, the numbering for each DP is independent. It is okay to number them in the following way: Time DP1 DP2 1 10 5 2 12 17 3 15 18 4 99 201 5 202 202 Or any other interesting scheme you would prefer, as long as the numbers for DP1 are monotonically increasing and the numbers for DP2 are monotoncally increasing. Note: This example is *not* meant to imply that you even need to issue both DPs at all the times specified. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: TAKIGUCHI Naruhito [mailto:takiguti@fjh.se.fujitsu.co.jp] > Sent: Wednesday, August 09, 2000 7:59 PM > To: ietf-pkix@imc.org > Subject: Re: CRL number in CRL and ARL > > > Ambarish, > > > If you are creating CRLs and ARLs that are not complete (i.e. > > don't contain all the entries the other does), it is very > > important that you use the CRLDP method of doing it. Put in > > CRLDP extensions in the certificates and IDP (Issuing Distribution > > Point) extensions in your CRLs/ARLs. > > > > If you don't use the CRLDP mechanism, you run the risk of having > > a bunch of applications misbehave with your CRLs. > > Thank you. I agree with your advice. > But, I'm going to discussion about the CRL number. > > I think that the method (a)(the CRL number is a sequece > number for each > CRL scope) is better than the method (b) for a relying party. > RFC2459 and son of RFC2459 describe following : > > The CRL number is a non-critical CRL extension which > conveys a mono- > tonically increasing sequence number for each CRL issued by a CA. > > Does "for each CRL issued by a CA" sentence mean the method (b) ? > > Thanks in advance. > > > Regards, > > Ambarish > > > > > --------------------------------------------------------------------- > > Ambarish Malpani > > Architect > 650.567.5457 > > ValiCert, Inc. > ambarish@valicert.com > > 339 N. Bernardo Ave. > http://www.valicert.com > > Mountain View, CA 94043 > > > > > > > -----Original Message----- > > > From: TAKIGUCHI Naruhito [mailto:takiguti@fjh.se.fujitsu.co.jp] > > > Sent: Tuesday, August 08, 2000 8:13 PM > > > To: ietf-pkix@imc.org > > > Subject: CRL number in CRL and ARL > > > > > > > > > Hi, all. > > > > > > I have a question about the cRLNumber extension. > > > > > > For example, a CA issues CRL(end-entity certificate > revocation list) > > > and ARL(CA certificate revocation list). > > > Which is correct (a) or (b) ? > > > > > > (a) In first CRL and ARL, the CRL number is 0. > > > In next CRL and ARL, the CRL number is 1. > > > > > > In other words, CRL and ARL have same value of > the CRL number. > > > The CRL number is a monotonically increasing > sequence number > > > for each CRL scope. > > > > > > (b) In first CRL, the CRL Number is 0. > > > In first ARL, the CRL Number is 1. > > > In next CRL, the CRL number is 2. > > > In next ARL, the CRL number is 3. > > > > > > In other words, the CRL number is monotonically increasing > > > sequence number for each CA. > > > > > > Could anyone advice me? > > > > > > Thanks in advance. > > > > > > ----- > > > Naruhito TAKIGUCHI > > > FUJITSU HOKURIKU SYSTEMS LTD. > > > > > ----- > Naruhito TAKIGUCHI > FUJITSU HOKURIKU SYSTEMS LTD. > From owner-ietf-pkix@imc.org Thu Aug 10 02:14:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11642 for ; Thu, 10 Aug 2000 02:14:56 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA13227; Wed, 9 Aug 2000 23:15:14 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 9 Aug 2000 23:15:10 -0700 Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA13189 for ; Wed, 9 Aug 2000 23:15:09 -0700 (PDT) Received: by mystic1.trustcenter.de; id IAA02118; Thu, 10 Aug 2000 08:12:00 +0200 Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma002116; Thu, 10 Aug 00 08:11:26 +0200 Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id IAA02650; Thu, 10 Aug 2000 08:13:08 +0200 (MET DST) Message-Id: <3.0.5.32.20000810081311.038e0690@localhost> X-Sender: jbr@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 10 Aug 2000 08:13:11 +0200 To: Ambarish Malpani From: Juergen Brauckmann Subject: RE: OCSP request Cc: ietf-pkix@imc.org In-Reply-To: <27FF4FAEA8CDD211B97E00902745CBE2B417FC@seine.valicert.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 08:40 09.08.00 -0700, Ambarish Malpani wrote: > >Juergen, > We did have a discussion about what kinds of questions OCSP >should answer when we were writing the RFC and the concensus was >that we were only providing the status of the certificate. I think you misunderstood me. I did definitely not want to start another discussion what OCSP is. I said: >> The text may be correct, but it is possible to misinterpret it. Juergen From owner-ietf-pkix@imc.org Thu Aug 10 07:53:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16589 for ; Thu, 10 Aug 2000 07:53:23 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA07259; Thu, 10 Aug 2000 04:53:14 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 10 Aug 2000 04:53:01 -0700 Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA07221 for ; Thu, 10 Aug 2000 04:53:00 -0700 (PDT) Received: from m3.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0006-Fujitsu Gateway) id UAA07447 for ; Thu, 10 Aug 2000 20:51:49 +0900 (JST) (envelope-from takiguti@fjh.se.fujitsu.co.jp) Received: from nic10.fjh.se.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.9.3/3.7W-0008-Fujitsu Domain Master) id UAA09811; Thu, 10 Aug 2000 20:51:48 +0900 (JST) Received: from anakin (anakin.fjh.se.fujitsu.co.jp [10.131.201.130]) by nic10.fjh.se.fujitsu.co.jp (8.9.3+3.2W/3.7W) with ESMTP id UAA07243 for ; Thu, 10 Aug 2000 20:51:48 +0900 (JST) Date: Thu, 10 Aug 2000 20:51:48 +0900 From: TAKIGUCHI Naruhito To: ietf-pkix@imc.org Subject: Re: CRL number in CRL and ARL In-Reply-To: <27FF4FAEA8CDD211B97E00902745CBE2B41816@seine.valicert.com> References: <27FF4FAEA8CDD211B97E00902745CBE2B41816@seine.valicert.com> Message-Id: <20000810151820.6BDC.TAKIGUTI@fjh.se.fujitsu.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00 (beta 25) Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Ambarish, > If you are using CRLDPs, the numbering for each DP is independent. > > It is okay to number them in the following way: > > Time DP1 DP2 > 1 10 5 > 2 12 17 > 3 15 18 > 4 99 201 > 5 202 202 > > Or any other interesting scheme you would prefer, as long as > the numbers for DP1 are monotonically increasing and the > numbers for DP2 are monotoncally increasing. > > Note: This example is *not* meant to imply that you even need to > issue both DPs at all the times specified. Thank you very much. I see that the CRL number is a monotonically increasing number for each CRL scope. But, in your example, the CRL number is not a sequence number. Is this right? ----- Naruhito TAKIGUCHI FUJITSU HOKURIKU SYSTEMS LTD. From owner-ietf-pkix@imc.org Thu Aug 10 09:04:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19880 for ; Thu, 10 Aug 2000 09:04:31 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA12683; Thu, 10 Aug 2000 06:04:40 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 10 Aug 2000 06:04:30 -0700 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12644 for ; Thu, 10 Aug 2000 06:04:29 -0700 (PDT) From: fred@cisco.com Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.69.25.24]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA12151; Thu, 10 Aug 2000 06:03:04 -0700 (PDT) Received: (fred@localhost) by irp-view7.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA29980; Thu, 10 Aug 2000 06:02:48 -0700 (PDT) Date: Thu, 10 Aug 2000 06:02:48 -0700 (PDT) Message-Id: <200008101302.GAA29980@irp-view7.cisco.com> To: bob@example.test, ietf-pkix@imc.org, pbaker@verisign.com, sharon.boeyen@entrust.com Subject: draft-ietf-pkix-pkixrep-00.txt Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I notice that you recently posted a new internet draft. A document that might be worth reading is http://www.ietf.org/ID-nits.html This document was put together by members of the IESG to help the community know what are the most common problems that we see in documents, whether from working groups or individual submissions, and pro-actively avoid them. This is an automatic email; please don't conclude that I have discovered something awful about your draft, as I haven't even read it yet. Rather, I'm just letting you know that there is a list of common issues that get raised over and over again in IESG reviews, and I'd like to save you the hassle by letting you see for yourself whether any of them apply. Let me know if you have any questions I can answer. From owner-ietf-pkix@imc.org Thu Aug 10 10:15:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24031 for ; Thu, 10 Aug 2000 10:15:05 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA15757; Thu, 10 Aug 2000 07:12:23 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 10 Aug 2000 07:12:12 -0700 Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA15715 for ; Thu, 10 Aug 2000 07:12:05 -0700 (PDT) Received: (qmail 21825 invoked from network); 10 Aug 2000 14:02:32 -0000 Received: from unknown (HELO mail.sibs.pt) (172.17.0.2) by 172.16.0.3 with SMTP; 10 Aug 2000 14:02:32 -0000 Received: from edi.van ([194.117.48.12]) by mail.sibs.pt (Netscape Mail Server v2.02) with ESMTP id AAA9174 for ; Thu, 10 Aug 2000 15:10:30 +0100 Received: from SIBSEX.sibs ([192.168.250.26]) by edi.van (8.8.2/8.8.2) with ESMTP id PAA08044 for ; Thu, 10 Aug 2000 15:08:32 +0100 (PST) Received: by sibsex.sibs with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 15:16:45 +0100 Message-ID: <63DA964A0E78D211B53E0008C7A4F56D014DC1AC@sibsex.sibs> From: Renato Portela To: "'ietf-pkix@imc.org'" Subject: OCSP and XML Date: Thu, 10 Aug 2000 15:16:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe The syntax of SCVP is being specified with XML. Is any chance do the same to OCSP? Thanks Renato Portela From owner-ietf-pkix@imc.org Thu Aug 10 10:30:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24842 for ; Thu, 10 Aug 2000 10:30:20 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA17117; Thu, 10 Aug 2000 07:30:24 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 10 Aug 2000 07:30:17 -0700 Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17067 for ; Thu, 10 Aug 2000 07:30:09 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA19368; Thu, 10 Aug 2000 16:33:39 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA37718; Thu, 10 Aug 2000 16:28:53 +0200 Message-ID: <3992BC27.F565F259@bull.net> Date: Thu, 10 Aug 2000 16:28:55 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Renato Portela CC: "'ietf-pkix@imc.org'" Subject: Re: OCSP and XML References: <63DA964A0E78D211B53E0008C7A4F56D014DC1AC@sibsex.sibs> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit > The syntax of SCVP is being specified with XML. ... and ASN.1. At this time, there is no decision to support SCVP or an equivalent, as well as no decision to have XML in addition to ASN.1. > Is any chance do the same to OCSP? I hope there is not such a "chance". We already have too many protocols for the same purpose. :-) Denis > > Thanks > Renato Portela From owner-ietf-pkix@imc.org Thu Aug 10 10:41:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25485 for ; Thu, 10 Aug 2000 10:41:54 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA17837; Thu, 10 Aug 2000 07:41:51 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 10 Aug 2000 07:41:49 -0700 Received: from rom.antech.de (dns.antech.de [194.45.12.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17806 for ; Thu, 10 Aug 2000 07:41:47 -0700 (PDT) Received: from scherbius.secorvo.de (scherbius.secorvo.de [194.45.12.219]) by rom.antech.de (8.9.3/8.9.3) with ESMTP id QAA25728 for ; Thu, 10 Aug 2000 16:25:12 +0200 Message-Id: <200008101425.QAA25728@rom.antech.de> From: "Stefan Kelm" Organization: Secorvo Security Consulting GmbH To: "'ietf-pkix@imc.org'" Date: Thu, 10 Aug 2000 16:40:14 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: X9.79? Reply-to: kelm@secorvo.de Priority: normal In-reply-to: <3992BC27.F565F259@bull.net> X-mailer: Pegasus Mail for Win32 (v3.12b) Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7BIT I apologize for sending this question to the PKIX list but I wasn't able to find the ANSI draft X9.79 anywhere, not even on www.ansi.org. Does anyone out there know how to get a copy? Is it available to the public at all? Any feedback is highly appreciated! Cheers, Stefan. -------------------------------------------------------- PKI-Symposium, 10.-11.Oktober 2000, www.pki-symposium.de -------------------------------------------------------- Dipl.-Inform. Stefan Kelm Security Consultant Secorvo Security Consulting GmbH Albert-Nestler-Strasse 9, D-76131 Karlsruhe Tel. +49 721 6105-461, Fax +49 721 6105-455 E-Mail kelm@secorvo.de, http://www.secorvo.de ------------------------------------------------------- PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B From owner-ietf-pkix@imc.org Thu Aug 10 11:17:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27392 for ; Thu, 10 Aug 2000 11:17:57 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA21936; Thu, 10 Aug 2000 08:18:01 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 10 Aug 2000 08:17:52 -0700 Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21858 for ; Thu, 10 Aug 2000 08:17:51 -0700 (PDT) Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA22352 for ; Thu, 10 Aug 2000 11:17:11 -0400 (EDT) Received: from anuxc.mv.lucent.com (h135-13-160-12.lucent.com [135.13.160.12]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA22152; Thu, 10 Aug 2000 11:17:04 -0400 (EDT) Received: from irene by anuxc.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA19146; Thu, 10 Aug 2000 11:14:06 -0400 (EDT) Message-Id: <4.1.20000810095846.00a209e0@anuxc.mv.lucent.com> X-Sender: irg@anuxc.mv.lucent.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 10 Aug 2000 11:17:21 -0400 To: Al Arsenault From: Irene Gassko Subject: RE: OCSP request Cc: "ietf-pkix@imc.org" In-Reply-To: <01C00119.59D0CC00.aarsenault@dvnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Al, Thanks for your analysis. My replies are inline. At 09:16 AM 08/08/2000 -0400, Al Arsenault wrote: >Irene Gassko wrote: > >So, it looks like efficiency really depends on how those certificates are >used. > >This part I'll agree with completely! As experience has shown repeatedly, >there's no "one best way" that always gives best performance from a PKI >implementation. It's a function of what application(s) you're trying to >support, what risks you're willing to take, what your constraints are in >terms of time, money, and technology, and a lot of other things, besides. > >I guess I started this by using the term "normal processing mode", so I'll >attempt to clarify - in some environments - e.g., where certificates are >being used to sign, encrypt, and verify e-mail messages - the approach >suggested by Irene seems to me to be less efficient than the approaches >currently defined in PKIX today, and in more-or-less common use. In other >environments, the approach she suggested MAY be more efficient, depending >on a lot of the factors identified above. > Now I understand what you mean by normal processing mode. You are right that we have different examples in mind when talking about certificates. I do not see why efficiency in cert processing is so important for email, when our speed of reading is so slow. I suspect that the main bottleneck in efficient processing of email is us, not certificate verification. When I think of certificates, I think more of hardware tokens and credit cards and cases when these need to be verified in quantity, say, by a vendor. It is not the only model I consider, but this is the first one I will think of when certs are mentioned. >Some specific comments in-line: >> >This is absolutely correct if you only want to check one individual certificate, >do not care about the possibility of revocation much and are not worried >about potential CA key compromise. Yes, and also if you trust directories >to tell you truthfully whether they have a particular certificate you are >looking for. > >AWA: I disagree to a greater or lesser extent with every clause in this >paragraph. The number of certificates does not have to be one; "small" for >appropriate values of that word will suffice. > >"Do not care about the possibility of revocation much" - huh? Where did >that come from? I pointed out that sometimes you're going to reject a >putative cert even BEFORE you check revocation status; e.g., because it got >garbled in transit and thus the signature fails. Why does "reject because >the signature failed before I ever bothered to check revocation" equal >"don't care about revocation"? > You are right, I missed that part, sorry for the confusion. In our scheme you have 2 checks for the price of 1. And if half of your correspondents have Verisign certificates, you can schedule checking Verisign's signature anytime you want, say while you get your well-deserved rest, and then you will need to check only a few hashes for each of these guys. If efficiency of checking is important for some reason, the hashes you need may even be attached to the cert. >"Are not worried about potential CA key compromise" - bear in mind that >there are a lot of factors that come into play if a CA key has been >compromised. Thus, making a decision to accept a certificate originally >signed with a key known to have been compromised requires a lot of >consideration. > Absolutely. Still our scheme allows much better recovery in this case, and if we come back to archiving, then the original CA keys have a substantial probability of being compromised over a long period of time (say, 50 years). OTOH, if the CA's key is quietly compromised only our scheme helps to catch forgery fast. >If you are checking a number of certificates from the same CA (say, Visa >cards) then you only need to check one signature and a few hashes, >which is much more efficient then checking a signature from every >certificate. You can even check that signature in advance, >for example a vendor can do it outside of rush hours and then only >a few hashes need to be computed: this is more >efficient than verifying a signature each time. If your certificate is your >credit card and today is your shopping day, you can prefetch >verification path to speed up approval for your purchases (in this >case I assume it to be a smartcard, as is common in Europe). > >AWA: yes, for this environment, the approach you suggest may be more >efficient than the traditional one. > >Besides efficiency issues there are other properties that a current scheme >does not possess. For example, if a CA key gets silently compromised, >and a certificate is forged quietly, with the current technology there is no >way to discover that a certificate is fake. However, in our scheme, in order >to fabricate a certificate, the root value of the Merkle tree has to be >altered, which will be too conspicuous to miss. > >AWA: forgive me if I get the technology wrong - I have some familiarity >with Merkle trees, but I'm certainly no expert on them. However, as I >understand the technology proposed, every time the CA issues a new >legitimate certificate, the root value has to be altered. In any kind of >dynamic environment - e.g., certificates issued every few (seconds, >minutes, hours,...), new certs are issued and thus the root value has to >change regularly. Thus, the event "root value altered because of a fake >cert signed by a compromised key" is very difficult to distinguish from >"root value altered because of legitimate cert signed by the real CA", >EXCEPT to the CA itself. Yes, if the CA is "eternally vigilant", you might >catch this happening, but then again you might not. > Let us look at the current practice of credit card companies. If you get your card or cancel it, all changes are actually done once a day. If we do the same for Merkle tree, it will a be a root of the day, a forgery of which will be very visible. You can do it more often, but most probably it will be at scheduled intervals and any update at inappropriate time will be obviously suspicious. >And another property. Even though directories are supposed to be untrusted >(or we would not need a CA signature at all), if we are looking for a >certificate, we are willing to believe that a particular certificate is not in the >directory, on the directory's say so. Our approach allows you get a get >a proof that this directory really does not possess a cert you are looking for. >No more trust needed for untrusted directories. > >AWA: If the directory tries to say "I have some certs, but not the one for >which you're looking", your approach works. If the directory says "I have >no certs at all", your approach provides the same results as the previous >approach. About which "attack" do you care? > If the directory says, "I have no certs", you go to another directory. If the directory says "I have all the certs, but the one you are looking for does not exist", you have either to double your effort by checking another, independent directory each time, or risk the fact that you are being cheated. I think that this "attack" is worse. Irene ---------------------------------------------------------------------------- ------------------------------------------------------- Irene Gassko Bell Laboratories http://www.lucent.com Lucent Technologies Secure Technologies Dept. 1600 Osgood Street phone: (978) 960-5767 Room 30-2-A31 e-mail: gassko@lucent.com N. Andover, MA 01845 fax: (978) 960-3240 From owner-ietf-pkix@imc.org Thu Aug 10 12:03:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01412 for ; Thu, 10 Aug 2000 12:03:02 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA27567; Thu, 10 Aug 2000 09:01:32 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 10 Aug 2000 09:01:27 -0700 Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27536 for ; Thu, 10 Aug 2000 09:01:25 -0700 (PDT) Received: from asn-1.com (user-2ivf56f.dialup.mindspring.com [165.247.148.207]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id MAA17262; Thu, 10 Aug 2000 12:00:40 -0400 (EDT) Message-ID: <3992D240.4A623521@asn-1.com> Date: Thu, 10 Aug 2000 12:03:12 -0400 From: "Phillip H. Griffin" Reply-To: phil.griffin@asn-1.com Organization: Griffin Consulting X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: kelm@secorvo.de CC: "'ietf-pkix@imc.org'" Subject: Re: X9.79? References: <200008101425.QAA25728@rom.antech.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit In general, Accredited Standards Committee X9 is the national standards setting body for the financial services industry. ASC X9 is accredited by ANSI. All approved X9 Standards are available in electronic form at the ASC X9 Web site's Electronic Standards Store (ESS) at www.x9.org or through the ANSI Web store at www.ansi.org. Hard copies can be obtained from Global Engineering Documents at 1-800-854-7179. For more information about ASC X9 or its committees, contact Cynthia Fuller, managing director, at (202) 663-5284. It is my understanding that X9.79 is a proposed standard of the X9F5 working group that has been balloted but has not yet been approved. Once it is approved it will be available through the X9/ANSI electronic bookstore. Until it is approved and published you can obtain a copy of the draft by joining X9, X9F or the X9 WG. Joining can give you access to all documents, the right to contribute to the development of the standards, to attend meetings, and to comment and vote. X9 is also the TAG for ISO TC68 (www.tc68.org) and work is already underway on either a derivative of X9.79 or an ISO level version of X9.79. The X9.79 proposed standard is very likely to be an input document to a TC68 working group. You can contact the TC68 representative for your country and get more information. Phil Stefan Kelm wrote: > > I apologize for sending this question to the PKIX list but I wasn't able to > find the ANSI draft X9.79 anywhere, not even on www.ansi.org. > > Does anyone out there know how to get a copy? Is it available to the public > at all? > > Any feedback is highly appreciated! > > Cheers, > > Stefan. > > -------------------------------------------------------- > PKI-Symposium, 10.-11.Oktober 2000, www.pki-symposium.de > -------------------------------------------------------- > Dipl.-Inform. Stefan Kelm > Security Consultant > > Secorvo Security Consulting GmbH > Albert-Nestler-Strasse 9, D-76131 Karlsruhe > > Tel. +49 721 6105-461, Fax +49 721 6105-455 > E-Mail kelm@secorvo.de, http://www.secorvo.de > ------------------------------------------------------- > PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B Phillip H. Griffin Griffin Consulting http://asn-1.com Secure ASN.1 Design & Implementation +1-919-832-7008 1625 Glenwood Avenue, Five Points +1-919-832-7390 [fax] Raleigh, North Carolina 27608 USA ------------------------------------------------------------ From owner-ietf-pkix@imc.org Thu Aug 10 12:26:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03894 for ; Thu, 10 Aug 2000 12:26:52 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA29736; Thu, 10 Aug 2000 09:27:07 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 10 Aug 2000 09:27:02 -0700 Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA29694 for ; Thu, 10 Aug 2000 09:26:59 -0700 (PDT) Received: (qmail 31547 invoked from network); 10 Aug 2000 16:17:24 -0000 Received: from unknown (HELO mail.sibs.pt) (172.17.0.2) by 172.16.0.3 with SMTP; 10 Aug 2000 16:17:24 -0000 Received: from edi.van ([194.117.48.12]) by mail.sibs.pt (Netscape Mail Server v2.02) with ESMTP id AAA19863; Thu, 10 Aug 2000 17:25:22 +0100 Received: from SIBSEX.sibs ([192.168.250.26]) by edi.van (8.8.2/8.8.2) with ESMTP id RAA28745; Thu, 10 Aug 2000 17:23:22 +0100 (PST) Received: by sibsex.sibs with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 17:31:35 +0100 Message-ID: <63DA964A0E78D211B53E0008C7A4F56D014DC1AE@sibsex.sibs> From: Renato Portela To: "'Denis Pinkas'" Cc: "'ietf-pkix@imc.org'" Subject: RE: OCSP and XML Date: Thu, 10 Aug 2000 17:31:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe The idea is not have more protocols but have a transition from ASN.1 to XML. Work with XML is much simpler. Exists parsers everywhere and for almost every language, is interoperable and finally is human readable. You don't prefer XML to ASN.1? Renato -----Original Message----- From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] Sent: Thursday, August 10, 2000 3:29 PM To: Renato Portela Cc: 'ietf-pkix@imc.org' Subject: Re: OCSP and XML > The syntax of SCVP is being specified with XML. ... and ASN.1. At this time, there is no decision to support SCVP or an equivalent, as well as no decision to have XML in addition to ASN.1. > Is any chance do the same to OCSP? I hope there is not such a "chance". We already have too many protocols for the same purpose. :-) Denis > > Thanks > Renato Portela From owner-ietf-pkix@imc.org Thu Aug 10 12:38:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04305 for ; Thu, 10 Aug 2000 12:38:53 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA01044; Thu, 10 Aug 2000 09:38:55 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 10 Aug 2000 09:38:52 -0700 Received: from nxs_vyr_dns.sie.cl ([206.48.156.90]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01008 for ; Thu, 10 Aug 2000 09:38:49 -0700 (PDT) Received: from jperez ([192.168.4.178]) by nxs_vyr_dns.sie.cl (8.9.3/8.9.3) with SMTP id MAA29306 for ; Thu, 10 Aug 2000 12:43:07 -0400 Reply-To: From: =?iso-8859-1?Q?Juan_Carlos_P=E9rez_Aguayo?= To: "'Ietf-Pkix" Subject: Client-side revocation checking capability Date: Thu, 10 Aug 2000 12:36:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit I am in trouble about this: What is the real support that have the client-side software for certificate revocation checking now? i.e. (Internet Explorer, Netscape, etc.) I heard that, in fact, client-applications don`t do any revocation checking at all? It's that truly? What is the real capability of those client applications this time? By example, I know that Netscape define some certificate extensions for managing revocation, but I am not sure if realy work Can anyone give me some help? Thanks you Juan Carlos Pérez Aguayo Software Engineer Acepta.com juancarlos.perez@acepta.com From owner-ietf-pkix@imc.org Thu Aug 10 13:54:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06793 for ; Thu, 10 Aug 2000 13:54:55 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA05156; Thu, 10 Aug 2000 10:55:01 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 10 Aug 2000 10:54:53 -0700 Received: from htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA05114 for ; Thu, 10 Aug 2000 10:54:52 -0700 (PDT) Received: from rgm.htt-consult.com ([63.82.18.195]) by htt-consult.com ; Thu, 10 Aug 2000 13:54:13 -0400 Message-Id: <4.3.2.7.2.20000810135026.00aef890@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 10 Aug 2000 13:51:37 -0400 To: Renato Portela , "'Denis Pinkas'" From: Robert Moskowitz Subject: RE: OCSP and XML Cc: "'ietf-pkix@imc.org'" In-Reply-To: <63DA964A0E78D211B53E0008C7A4F56D014DC1AE@sibsex.sibs> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 05:31 PM 8/10/2000 +0100, Renato Portela wrote: >The idea is not have more protocols but have a transition from ASN.1 to XML. > >Work with XML is much simpler. Exists parsers everywhere and for almost >every language, is interoperable and finally is human readable. > >You don't prefer XML to ASN.1? You first get PKCS#7 and S/MIME to switch away from ASN.1 to XML. Then we will talk about doing it in PKIX.... Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ietf-pkix@imc.org Thu Aug 10 14:13:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08705 for ; Thu, 10 Aug 2000 14:13:43 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA06553; Thu, 10 Aug 2000 11:13:52 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 10 Aug 2000 11:13:50 -0700 Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06519 for ; Thu, 10 Aug 2000 11:13:49 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id LAA20174; Thu, 10 Aug 2000 11:13:28 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 11:12:01 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4F9353B@vhqpostal.verisign.com> From: Michael Myers To: Renato Portela , "'ietf-pkix@imc.org'" Subject: RE: OCSP and XML Date: Thu, 10 Aug 2000 11:11:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Not at this time. Mike > -----Original Message----- > From: Renato Portela [mailto:RPortela@sibs.mailcom.pt] > Sent: Thursday, August 10, 2000 7:17 AM > To: 'ietf-pkix@imc.org' > Subject: OCSP and XML > > > The syntax of SCVP is being specified with XML. > Is any chance do the same to OCSP? > > Thanks > Renato Portela > From owner-ietf-pkix@imc.org Thu Aug 10 16:23:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13099 for ; Thu, 10 Aug 2000 16:23:15 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA12651; Thu, 10 Aug 2000 13:22:18 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 10 Aug 2000 13:22:10 -0700 Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12620 for ; Thu, 10 Aug 2000 13:22:10 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 13:12:05 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE235E36D@seine.valicert.com> From: Peter Williams To: Renato Portela , "'ietf-pkix@imc.org'" Subject: RE: OCSP and XML Date: Thu, 10 Aug 2000 13:12:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Renato, you can specify an XML-format payload for OCSP at your leisure and at your will, and be entirely conforming to the draft standard in using the payload-format options. Talk to Ambarish, inside or outside IETF - as Steve directs. -----Original Message----- From: Michael Myers [mailto:MMyers@verisign.com] Sent: Thursday, August 10, 2000 11:12 AM To: Renato Portela; 'ietf-pkix@imc.org' Subject: RE: OCSP and XML Not at this time. Mike > -----Original Message----- > From: Renato Portela [mailto:RPortela@sibs.mailcom.pt] > Sent: Thursday, August 10, 2000 7:17 AM > To: 'ietf-pkix@imc.org' > Subject: OCSP and XML > > > The syntax of SCVP is being specified with XML. > Is any chance do the same to OCSP? > > Thanks > Renato Portela > From owner-ietf-pkix@imc.org Thu Aug 10 18:09:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14979 for ; Thu, 10 Aug 2000 18:09:02 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA16863; Thu, 10 Aug 2000 15:09:17 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 10 Aug 2000 15:09:11 -0700 Received: from c014.sfo.cp.net (c014-h022.c014.sfo.cp.net [209.228.12.86]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA16832 for ; Thu, 10 Aug 2000 15:09:11 -0700 (PDT) Received: (cpmta 23591 invoked from network); 10 Aug 2000 15:08:02 -0700 Received: from 3ff8359b.dsl.flashcom.net (HELO concord) (63.248.53.155) by smtp.flashcom.net with SMTP; 10 Aug 2000 15:08:02 -0700 X-Sent: 10 Aug 2000 22:08:02 GMT Reply-To: From: "Jeff Spinney" To: , "''Ietf-Pkix'" Subject: RE: Client-side revocation checking capability Date: Thu, 10 Aug 2000 18:04:34 -0400 Message-ID: <000701c00316$f8359980$6501010a@jeffshouse.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit OCSP server vendors such as CertCo (www.certco.com) or Valicert (www.valicert.com) have toolkits with which you can OCSP 'enable' an application. This is great for application vendors who wish to make their apps more robust and certificate enabled. Most applications at this point in the game are not OCSP enabled even if they can deal with certificates, they do the basic crypto checking *if* they have the issuer cert on hand, but do not do real time status checking to see whether or not the cert has been revoked since it was issued. in that regard, it seems as though the application market needs to be persuaded to make their software support real time certificate status checking. As for Netscape, they do have an OCSP client for their browser. I am unsure if it is publically available at this time. It loads into the security area, under 'advanced' and gives you the option to specify an OCSP responder. In my experiance, and it was in the early stages of this modules lifetime, it was very finicky. If i remember correctly, it wanted the OCSP response to be sgned by the same cert that signed the cert being checked. This may not always be the case. -j -----Original Message----- From: Juan Carlos Pérez Aguayo [mailto:juancarlos.perez@acepta.com] Sent: Thursday, August 10, 2000 12:36 PM To: 'Ietf-Pkix Subject: Client-side revocation checking capability I am in trouble about this: What is the real support that have the client-side software for certificate revocation checking now? i.e. (Internet Explorer, Netscape, etc.) I heard that, in fact, client-applications don`t do any revocation checking at all? It's that truly? What is the real capability of those client applications this time? By example, I know that Netscape define some certificate extensions for managing revocation, but I am not sure if realy work Can anyone give me some help? Thanks you Juan Carlos Pérez Aguayo Software Engineer Acepta.com juancarlos.perez@acepta.com From owner-ietf-pkix@imc.org Thu Aug 10 19:11:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15744 for ; Thu, 10 Aug 2000 19:11:48 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA19291; Thu, 10 Aug 2000 16:11:45 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 10 Aug 2000 16:11:39 -0700 Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA19258 for ; Thu, 10 Aug 2000 16:11:38 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <4.3.2.7.2.20000810135026.00aef890@homebase.htt-consult.com> References: <4.3.2.7.2.20000810135026.00aef890@homebase.htt-consult.com> Date: Thu, 10 Aug 2000 16:11:04 -0700 To: ietf-pkix@imc.org From: Paul Hoffman / IMC Subject: RE: OCSP and XML Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 1:51 PM -0400 8/10/00, Robert Moskowitz wrote: >>You don't prefer XML to ASN.1? > >You first get PKCS#7 and S/MIME to switch away from ASN.1 to XML. >Then we will talk about doing it in PKIX.... Bob, could you explain this a bit? Using XML as a message format for SCVP is completely unrelated to PKCS#7. It is a method for bundling the parts of the query about a certificate, and for bundling the parts of the answer. Why should that be tied to an unrelated protocol? --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-pkix@imc.org Thu Aug 10 19:44:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16402 for ; Thu, 10 Aug 2000 19:44:25 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA20513; Thu, 10 Aug 2000 16:41:24 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 10 Aug 2000 16:41:21 -0700 Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20481 for ; Thu, 10 Aug 2000 16:41:21 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 16:31:20 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2B4182A@seine.valicert.com> From: Ambarish Malpani To: "'jspinney@securify.com'" , juancarlos.perez@acepta.com, "''Ietf-Pkix'" Subject: RE: Client-side revocation checking capability Date: Thu, 10 Aug 2000 16:31:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA20482 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Hi Juan, I agree with Jeff that most client applications don't do revocation checking. To the best of my belief, some of the 3.0 versions of Netscape Navigator etc. could do CRL checking if the cert had some magic extensions in them. Communicator 4.7, with the PSM module does a pretty reasonable job of revocation checking with OCSP. We (ValiCert) do have a plugin for both IE 5.0 and Outlook that can also enable those applications to do revocation checking with OCSP. We also have plugins for Netscape Enterprise Server and IIS, but you don't seem to be interested in servers from your mail. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Jeff Spinney [mailto:spinneyj@flashcom.net] > Sent: Thursday, August 10, 2000 3:05 PM > To: juancarlos.perez@acepta.com; ''Ietf-Pkix' > Subject: RE: Client-side revocation checking capability > > > OCSP server vendors such as CertCo (www.certco.com) or Valicert > (www.valicert.com) have toolkits with which you can OCSP 'enable' an > application. This is great for application vendors who wish > to make their > apps more robust and certificate enabled. Most applications > at this point in > the game are not OCSP enabled even if they can deal with > certificates, they > do the basic crypto checking *if* they have the issuer cert > on hand, but do > not do real time status checking to see whether or not the > cert has been > revoked since it was issued. > > in that regard, it seems as though the application > market needs to be > persuaded to make their software support real time certificate status > checking. > > > As for Netscape, they do have an OCSP client for their > browser. I am unsure > if it is publically available at this time. It loads into the > security area, > under 'advanced' and gives you the option to specify an OCSP > responder. In > my experiance, and it was in the early stages of this modules > lifetime, it > was very finicky. If i remember correctly, it wanted the > OCSP response to > be sgned by the same cert that signed the cert being checked. > This may not > always be the case. > > > -j > > > > -----Original Message----- > From: Juan Carlos Pérez Aguayo [mailto:juancarlos.perez@acepta.com] > Sent: Thursday, August 10, 2000 12:36 PM > To: 'Ietf-Pkix > Subject: Client-side revocation checking capability > > > I am in trouble about this: What is the real support that have the > client-side software for certificate revocation checking now? > i.e. (Internet > Explorer, Netscape, etc.) > > I heard that, in fact, client-applications don`t do any > revocation checking > at all? It's that truly? > > What is the real capability of those client applications this time? > > By example, I know that Netscape define some certificate > extensions for > managing revocation, but I am not sure if realy work > > Can anyone give me some help? > > Thanks you > > > > Juan Carlos Pérez Aguayo > Software Engineer > Acepta.com > juancarlos.perez@acepta.com > > From owner-ietf-pkix@imc.org Thu Aug 10 19:46:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16482 for ; Thu, 10 Aug 2000 19:46:40 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA20711; Thu, 10 Aug 2000 16:42:34 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 10 Aug 2000 16:42:32 -0700 Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20680 for ; Thu, 10 Aug 2000 16:42:32 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 16:32:31 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2B4182B@seine.valicert.com> From: Ambarish Malpani To: "'TAKIGUCHI Naruhito'" , ietf-pkix@imc.org Subject: RE: CRL number in CRL and ARL Date: Thu, 10 Aug 2000 16:32:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe That is perfectly legal. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: TAKIGUCHI Naruhito [mailto:takiguti@fjh.se.fujitsu.co.jp] > Sent: Thursday, August 10, 2000 4:52 AM > To: ietf-pkix@imc.org > Subject: Re: CRL number in CRL and ARL > > > Ambarish, > > > If you are using CRLDPs, the numbering for each DP is independent. > > > > It is okay to number them in the following way: > > > > Time DP1 DP2 > > 1 10 5 > > 2 12 17 > > 3 15 18 > > 4 99 201 > > 5 202 202 > > > > Or any other interesting scheme you would prefer, as long as > > the numbers for DP1 are monotonically increasing and the > > numbers for DP2 are monotoncally increasing. > > > > Note: This example is *not* meant to imply that you even need to > > issue both DPs at all the times specified. > > Thank you very much. > I see that the CRL number is a monotonically increasing > number for each CRL scope. > > But, in your example, the CRL number is not a sequence number. > Is this right? > > ----- > Naruhito TAKIGUCHI > FUJITSU HOKURIKU SYSTEMS LTD. > > From owner-ietf-pkix@imc.org Thu Aug 10 19:52:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16663 for ; Thu, 10 Aug 2000 19:52:19 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA21256; Thu, 10 Aug 2000 16:48:53 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 10 Aug 2000 16:48:51 -0700 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA21222 for ; Thu, 10 Aug 2000 16:48:51 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 10 Aug 2000 17:41:40 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 10 Aug 2000 14:27:39 -0600 From: "Bob Jueneman" To: , , Cc: Subject: RE: OCSP and XML Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_5B03FCA4.36573A78" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_5B03FCA4.36573A78 Content-Type: multipart/alternative; boundary="=_5B03FCA4.37563B79" --=_5B03FCA4.37563B79 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable >You don't prefer XML to ASN.1? I most certainly don't for this purpose, and that has=20 nothing whatsoever to do with the language's=20 expressive power, efficiency, or whatever. By now, anyone who is processing directories, certificates, etc., has already climbed up the ladder of ASN.1 competence. In our case we wrote our own set of libraries in a very short=20 time, and have had no trouble using them. What I DON'T want to have to do is support two different ways of=20 doing the same thing. It adds to code bloat, significantly increases=20 the already too-high testing burden, etc. In addition, and a more subtle point, is the fact that it is almost=20 never possible to exactly translate between two languages -- there is always something in one specification that doesn't quite=20 have an exact analog in the other language. As a result, attempts to translate a specification in one language into=20 another will typically fail the first or even the second time, and as a result the specification becomes ambiguous. Rewriting, rethinking, and recoding all of the work that has already=20 been done would be an enormous undertaking, and certainly not worth doing. To quote Winston Churchill in a different context, "That is the sort of nonsense up with which I shall not put." Bob Robert R. Jueneman Consultant Engineer, PKI/Security Architect Novell, Inc. -- the leading provider of Net services software 1800 South Novell Place Provo, UT 84606 www.novell.com bjueneman@novell.com 1-801-861-7387 DISCLAIMER: If this message (with or without attached documents) is digitally = signed, and/or if certificates are attached, the intended purpose is to=20 (1) Ensure that e-mail came from the apparent sender (2) Protect e-mail from tampering (3) Ensure that the content of e-mail sent to me and encrypted in my = dual-use key cannot be viewed by others. It is explicitly NOT the intent of any such signed message or document = to represent any type or form of legally binding contract or other = representation, and any such interpretation should not be considered = commercially reasonable and will be repudiated, notwithstanding any = wording or implications to the opposite effect in the text of the message = itself. --=_5B03FCA4.37563B79 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>You don't prefer XML to ASN.1?
I most certainly don't for this purpose, and that has
nothing whatsoever to do with the language's
expressive power, efficiency, or whatever.
 
By now, anyone who is processing directories, certificates,
etc., has already climbed up the ladder of ASN.1 competence.
In our case we wrote our own set of libraries in a very short
time, and have had no trouble using them.
 
What I DON'T want to have to do is support two different ways of =
doing the same thing.  It adds to code bloat, significantly = increases=20
the already too-high testing burden, etc.
 
In addition, and a more subtle point, is the fact that it is almost =
never possible to exactly translate between two languages --
there is always something in one specification that doesn't quite =
have an exact analog in the other language.
 
As a result, attempts to translate a specification in one language = into=20
another will typically fail the first or even the second time, and = as
a result the specification becomes ambiguous.
 
Rewriting, rethinking, and recoding all of the work that has already =
been done would be an enormous undertaking, and certainly not
worth doing.
 
To quote Winston Churchill in a different context,
"That is the sort of nonsense up with which I shall not put."
 
Bob
 
 
 
Robert R. Jueneman
Consultant Engineer, PKI/Security Architect
 
Novell, Inc. -- the leading provider of Net services software
1800 = South=20 Novell Place
Provo, UT 84606
www.novell.com
 
bjueneman@novell.com
1-801-861-= 7387
 
DISCLAIMER:
  If this message (with or without attached = documents)=20 is digitally signed, and/or if certificates are attached, the intended = purpose=20 is to
   (1) Ensure that e-mail came from the apparent=20 sender
   (2) Protect e-mail from tampering
   = (3)=20 Ensure that the content of e-mail sent to me and encrypted in  my = dual-use=20 key cannot be viewed by others.
  It is explicitly NOT the intent = of any=20 such signed message or document to represent any type or form of legally = binding=20 contract or other representation, and any such interpretation should not = be=20 considered commercially reasonable and will be repudiated, notwithstanding = any=20 wording or implications to the opposite effect in the text of the = message=20 itself.
--=_5B03FCA4.37563B79-- --=_5B03FCA4.36573A78 Content-Type: text/plain Content-Disposition: attachment; filename="Bob Jueneman.vcf" BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Bob Jueneman TEL;WORK:801-861-7387 ORG:Novell Inc. -- the leading provider of Net services software;eBusiness Solutions TEL;PREF;FAX:801-861-2522 EMAIL;WORK;PREF;S/MIME:BJUENEMAN@novell.com N:Jueneman;Robert TITLE:consultant Engineer, PKI/Security Architect ADR;INTL;WORK;PARCEL;POSTAL:;;Novell, Inc.\n1800 South Novell Place\n;Provo;Utah;84606;USA LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Bob Jueneman=0A= Novell, Inc.=0A= 1800 South Novell Place=0A= =0A= Provo, Utah 84606=0A= USA LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Bob Jueneman=0A= Novell, Inc.=0A= 1800 South Novell Place=0A= =0A= Provo, Utah 84606 X-GWUSERID:BJUENEMAN END:VCARD BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Robert R. Jueneman TEL;WORK:801-861-7387 ORG:Novell, Inc.;Network Security Development TEL;PREF;FAX:801-861-2522 EMAIL;WORK;PREF;NGW:BJUENEMAN@novell.com N:Jueneman;Bob TITLE:Consultant Engineer ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;USA LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A= PRV-F331=0A= 122 E. 1700 South=0A= Provo, Utah 84606=0A= USA LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A= PRV-F331=0A= 122 E. 1700 South=0A= Provo, Utah 84606 TEL;HOME:1-801-765-4378 TEL;CELL:1-801-361-1410 TEL;PREF:1-801-861-7387, 1-800-453-1267 X-GWUSERID:BJUENEMAN END:VCARD --=_5B03FCA4.36573A78-- From owner-ietf-pkix@imc.org Fri Aug 11 00:49:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23013 for ; Fri, 11 Aug 2000 00:49:51 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA14155; Thu, 10 Aug 2000 21:50:03 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 10 Aug 2000 21:49:25 -0700 Received: from lafontaine.cybercable.fr (lafontaine.cybercable.fr [212.198.0.202]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA14088 for ; Thu, 10 Aug 2000 21:49:23 -0700 (PDT) Received: (qmail 758215 invoked from network); 11 Aug 2000 04:48:46 -0000 Received: from r209m73.cybercable.tm.fr (HELO aeg) ([195.132.209.73]) (envelope-sender ) by lafontaine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 11 Aug 2000 04:48:46 -0000 From: "Abdellah EL GARANI" To: Date: Fri, 11 Aug 2000 06:51:17 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <27FF4FAEA8CDD211B97E00902745CBE2B4182B@seine.valicert.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit unsuscribe From owner-ietf-pkix@imc.org Fri Aug 11 02:23:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05988 for ; Fri, 11 Aug 2000 02:23:01 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA20131; Thu, 10 Aug 2000 23:23:08 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 10 Aug 2000 23:22:57 -0700 Received: from acme.penta3.es ([195.171.34.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA20081 for ; Thu, 10 Aug 2000 23:22:55 -0700 (PDT) Received: from penta3.es (mazingerdmz.penta3.es [212.163.11.195]) by acme.penta3.es (8.9.3/8.9.3) with ESMTP id IAA22598 for ; Fri, 11 Aug 2000 08:19:47 +0200 Message-ID: <39939CCD.35D95A82@penta3.es> Date: Fri, 11 Aug 2000 08:27:26 +0200 From: Javier Torres Seco de Herrera X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-pkix@imc.org" Subject: Unsuscribe Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msA41F226F0ED820E39A6C1103" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a cryptographically signed message in MIME format. --------------msA41F226F0ED820E39A6C1103 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Unsuscribe --------------msA41F226F0ED820E39A6C1103 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIJoAYJKoZIhvcNAQcCoIIJkTCCCY0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B5EwggKEMIIB76ADAgECAgEkMAsGCSqGSIb3DQEBBDB4MQ8wDQYDVQQIFAZNYWRyaWQxDzAN BgNVBAcUBk1hZHJpZDEMMAoGA1UEAxQDU1RBMRMwEQYDVQQLFApEZW1vIFNJQk9TMSQwIgYD VQQKFBtHbG9iYWwgVHJ1c3QgQXV0aG9yaXR5KEdUQSkxCzAJBgNVBAYUAkVTMB4XDTAwMDgx MDEzMjYwMFoXDTAxMDcyNjAxMDAwMFowgZsxDzANBgNVBAgUBk1hZHJpZDEPMA0GA1UECxQG Q3J5cHRvMQ8wDQYDVQQKFAZQRU5UQTMxDzANBgNVBAcUBk1hZHJpZDEgMB4GCSqGSIb3DQEJ ARYRanRvcnJlc0BwZW50YTMuZXMxJjAkBgNVBAMUHUphdmllciBUb3JyZXMgU2VjbyBkZSBI ZXJyZXJhMQswCQYDVQQGFAJFUzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvURDBi7c gjNAQcKBOQWunKWfivGGCuQc6O0qW9O/YuJiqEdBDdbBQG9mDw1UUlEk1mThxKAz1oYDtF8K EmOU/88Xj0usxFzrgTUEP27ro320RWvRKvkwlyp4BoNBUiNupyhVFZCE7+H+lgpa4p+0iJWR FxSSdgojkju54zCmLzMCAwEAATALBgkqhkiG9w0BAQQDgYEAJZJOwEKuV63pOdwpo4rmkqde 16a/o1V/VR9aPHPPhZKOvktpMKxY+Uz5EcZA0nZ5CXEvbuceKtDaH/j/i20mXeBYvsWhie1P d6Ccw9E7xzJlNUP6yfEFPkinHEhhTpL6aoW9oXL6iRvVk54ZkoNpbMyVfaA8yohHGrbOqdxv ow4wggKQMIIB+6ADAgECAgEEMAsGCSqGSIb3DQEBBDBuMQ8wDQYDVQQIFAZNYWRyaWQxDzAN BgNVBAcUBk1hZHJpZDEMMAoGA1UEAxQDTVRBMQ4wDAYDVQQLFAVTSUJPUzEfMB0GA1UEChQW R2xvYmFsIFRydXN0IEF1dGhvcml0eTELMAkGA1UEBhQCRVMwHhcNMDAwNzMxMTE0NTAwWhcN MDEwNzIxMDEwMDAwWjB4MQ8wDQYDVQQIFAZNYWRyaWQxDzANBgNVBAcUBk1hZHJpZDEMMAoG A1UEAxQDU1RBMRMwEQYDVQQLFApEZW1vIFNJQk9TMSQwIgYDVQQKFBtHbG9iYWwgVHJ1c3Qg QXV0aG9yaXR5KEdUQSkxCzAJBgNVBAYUAkVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQC1c9Z3Ez08hWowDuAUWUhwBy92bHjmO1oRJzxkPpgDkJWKn9Q3pJtADUIs5JjjpASi8Yn7 bpaVqEzl/GV1krvt+pFFVgYbLzIpfYJaakh+opcnSRR9N3qY+mfJZ850Qlu6U5W6vYlPM3UR C6qzEWnBhZj8xHk1+d9TQzeCUGhYDQIDAQABozgwNjALBgNVHQ8EBAMCAZIwJwYDVR0lBCAw HgYIKwYBBQUHAwQGCCsGAQUFBwMCBggrBgEFBQcDATALBgkqhkiG9w0BAQQDgYEAeIRNqAJP GJfmqnexemupqxTVRGGp+vTWjResGHq41qUUiA2CC0WHoalW4HCjcPdIR1zngV+YUbENb888 Ooyg/IlSdQ6bX7YWXSS5NwCk6d4H6nAu8XTFRyRO/WsHu2CkBlUkfayEoK7tnhbW7dwYHyV2 vNVHWsUgVzUFnjhL+XEwggJxMIIB3KADAgECAgEFMA0GCSqGSIb3DQEBBAUAMIGQMQ8wDQYD VQQIFAZNYWRyaWQxDzANBgNVBAcUBk1hZHJpZDERMA8GA1UEAxQIR1RBIFJvb3QxJTAjBgNV BAsUHEdsb2JhbCBUcnVzdCBBdXRob3JpdHkgKEdUQSkxJTAjBgNVBAoUHEdsb2JhbCBUcnVz dCBBdXRob3JpdHkgKEdUQSkxCzAJBgNVBAYUAkVTMB4XDTAwMDczMTExMjIwMFoXDTAxMDcy OTAxMDAwMFowbjEPMA0GA1UECBQGTWFkcmlkMQ8wDQYDVQQHFAZNYWRyaWQxDDAKBgNVBAMU A01UQTEOMAwGA1UECxQFU0lCT1MxHzAdBgNVBAoUFkdsb2JhbCBUcnVzdCBBdXRob3JpdHkx CzAJBgNVBAYUAkVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7tjoug3J4iCmQP+A1 WEonWbuzvwfpoYff6VLi7ksljSkdyL7purgrvpx20WqVsZA7uE3WARfBYH5i14IzNeMnBljY P7lpAgQlWJWnIJa6PUFG8gbkeBw0QFgHUTCFY7jRztMzifyxnmmJuPe86gjJR5uuKm51ADw/ OX8PzGn/GwIDAQABMAsGCSqGSIb3DQEBBAOBgQBCO7t72Po02tkOVHlhpRFERP7M6eIle0ve 82XpkBcLvgtsAfyEi7RFv3rCorEyWHKoAsYNh42aWEyUpDk211NLNkVRgn5+ReM/hCGSgEfd RyTuAd3uRRTrcN2NjXQ5RG4qpFHXG+zRVE+iKOMK6ndJb9UWDvbmaw3t+EHljofvDDGCAdcw ggHTAgEBMH0weDEPMA0GA1UECBQGTWFkcmlkMQ8wDQYDVQQHFAZNYWRyaWQxDDAKBgNVBAMU A1NUQTETMBEGA1UECxQKRGVtbyBTSUJPUzEkMCIGA1UEChQbR2xvYmFsIFRydXN0IEF1dGhv cml0eShHVEEpMQswCQYDVQQGFAJFUwIBJDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDgxMTA2MjczMFowIwYJKoZIhvcNAQkE MRYEFElySmBQoPhOwvoFKfj0hn+ObaATMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MA0GCSqGSIb3DQEBAQUABIGAPE74Sm7DKq08HeCUf0l+8PDM0QHyS0EbHqlDHXVQAFP/yN6o u5U321hDZ+QVlvCpEeCHf6LrUAgMS1bJuS1vC4rza9OQsnrBZ62DOBHQnGNHSQQePFD0RRR9 zgGzCYJ6gc+F3YCe/vQEjUBHHbURDcR32UgK292lwGUpao7feYY= --------------msA41F226F0ED820E39A6C1103-- From owner-ietf-pkix@imc.org Fri Aug 11 05:10:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07573 for ; Fri, 11 Aug 2000 05:10:36 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA28509; Fri, 11 Aug 2000 02:10:15 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 11 Aug 2000 02:10:06 -0700 Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA28472 for ; Fri, 11 Aug 2000 02:10:04 -0700 (PDT) Received: by balinese.baltimore.ie; id KAA21979; Fri, 11 Aug 2000 10:09:26 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma021892; Fri, 11 Aug 00 10:08:49 +0100 Received: from dna (dna.ie.baltimore.com [192.168.21.111]) by bobcat.baltimore.ie (8.9.3/8.9.3) with SMTP id KAA04409 for ; Fri, 11 Aug 2000 10:08:49 +0100 Reply-To: From: "Dave Dineen" To: Subject: Unsuscribe Date: Fri, 11 Aug 2000 10:10:44 +0100 Message-ID: <005a01c00374$083059d0$6f15a8c0@dna.baltimore.ie> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit From owner-ietf-pkix@imc.org Fri Aug 11 05:54:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07943 for ; Fri, 11 Aug 2000 05:54:18 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA01917; Fri, 11 Aug 2000 02:54:32 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 11 Aug 2000 02:54:28 -0700 Received: from acme.penta3.es ([195.171.34.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01885 for ; Fri, 11 Aug 2000 02:54:27 -0700 (PDT) Received: from penta3.es (mazingerdmz.penta3.es [212.163.11.195]) by acme.penta3.es (8.9.3/8.9.3) with ESMTP id LAA24451 for ; Fri, 11 Aug 2000 11:51:19 +0200 Message-ID: <3993CE6C.59991CC7@penta3.es> Date: Fri, 11 Aug 2000 11:59:08 +0200 From: Javier Torres Seco de Herrera X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-pkix@imc.org" Subject: Unsuscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit From owner-ietf-pkix@imc.org Fri Aug 11 07:02:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09076 for ; Fri, 11 Aug 2000 07:02:36 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA07548; Fri, 11 Aug 2000 04:02:43 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 11 Aug 2000 04:02:32 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA07504 for ; Fri, 11 Aug 2000 04:02:31 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08870; Fri, 11 Aug 2000 07:01:55 -0400 (EDT) Message-Id: <200008111101.HAA08870@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ac509prof-05.txt Date: Fri, 11 Aug 2000 07:01:54 -0400 Sender: nsyracus@cnri.reston.va.us Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : An Internet Attribute Certificate Profile for Authorization Author(s) : S. Farrell, R. Housley Filename : draft-ietf-pkix-ac509prof-05.txt Pages : 37 Date : 10-Aug-00 This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ac509prof-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ac509prof-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000810140212.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ac509prof-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ac509prof-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000810140212.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@imc.org Fri Aug 11 08:30:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11837 for ; Fri, 11 Aug 2000 08:30:55 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA12350; Fri, 11 Aug 2000 05:31:01 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 11 Aug 2000 05:30:46 -0700 Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA12317 for ; Fri, 11 Aug 2000 05:30:44 -0700 (PDT) Received: from jade.hut.fi (jei@jade.hut.fi [130.233.249.69]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id PAA23398 for ; Fri, 11 Aug 2000 15:30:08 +0300 (EET DST) Date: Fri, 11 Aug 2000 15:30:06 +0300 (EET DST) From: Jukka E Isosaari Reply-To: Jukka.Isosaari@hut.fi To: ietf-pkix@imc.org Subject: Startup looking for PKI & XML experts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Please excuse if this is out of topic. // Jukka ---------- Forwarded message ---------- Startup looking for PKI and XML developers CRF Box is a technology start-up aiming at shortening pharmaceutical R&D time and improving the quality of clinical data collected in clinical studies. This is achieved via CRF Box transaction and information platform, which provides enhanced physician connectivity through the Internet towards physicians who participate in the clinical study. At the emerging global market, we aim at being among the top suppliers in two year CRF Box benefits pharmaceutical and biotech companies as well as physicians who are able to perform their professional duties more efficiently. CRF Box is currently developing the first release of its product in partnership with a global pharmaceutical company. The development is to be finalized and product piloted in Finland during fall 2000, after which international roll-out will commence. CRF Box operations are currently privately funded, and the company office is located in Helsinki, Finland. At the moment, CRF Box product is being developed by seventeen professionals. By the end of this year, we expect to have 30 people. Part of them will be working in our Boston office. CRF Box is continuously looking for new talent to share and execute the company vision of providing a de-facto standard transaction platform for global pharmaceutical and biotech in dustries. The company culture of CRF Box relies on openness of communication and freedom with respect to the choice and scope of individual tasks. A personal compensation package is tailored to meet your needs and to incentivize individual performance according to your preferences. As a rapidly growing company, different skills are valued. The things that we especially look for are the ability to bring ideas in to reality, and the tendency to have an opinion. Knowledge and experience in PKI programming area is appreciated, in specific. For more information, please visit: http://www.crfbox.com or contact directly by email: recruiting@crfbox.com From owner-ietf-pkix@imc.org Fri Aug 11 09:01:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13194 for ; Fri, 11 Aug 2000 09:01:33 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA14555; Fri, 11 Aug 2000 06:00:49 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 11 Aug 2000 06:00:47 -0700 Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14524 for ; Fri, 11 Aug 2000 06:00:46 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Fri, 11 Aug 2000 08:59:40 -0400 Message-ID: From: Sharon Boeyen To: "'Ambarish Malpani'" , "'TAKIGUCHI Naruhito'" , ietf-pkix@imc.org Subject: RE: CRL number in CRL and ARL Date: Fri, 11 Aug 2000 08:56:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe An additional point on the numbering of CRLs. In the 2000 edition of X.509, additional flexibility for CRLs was added. For example, a status referrals extension can indicate that an authority has changed its partitioning scheme, indirect delta CRL streams were added etc. To help reduce confusion over the CRL numbering, the new cRLStreamIdentifier extension was added. This new extension basically identifies a context (e.g. full crls, CRL DPs, delta for a given CRLDP,indirect delta for a given scope, etc) within which the cRLNumber must be unique. This is defined in 8.5.2.7 of the 2000 text of 509: ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/ Sharon > -----Original Message----- > From: Ambarish Malpani [mailto:ambarish@valicert.com] > Sent: Thursday, August 10, 2000 7:33 PM > To: 'TAKIGUCHI Naruhito'; ietf-pkix@imc.org > Subject: RE: CRL number in CRL and ARL > > > > That is perfectly legal. > > Regards, > Ambarish > > --------------------------------------------------------------------- > Ambarish Malpani > Architect 650.567.5457 > ValiCert, Inc. ambarish@valicert.com > 339 N. Bernardo Ave. http://www.valicert.com > Mountain View, CA 94043 > > > > -----Original Message----- > > From: TAKIGUCHI Naruhito [mailto:takiguti@fjh.se.fujitsu.co.jp] > > Sent: Thursday, August 10, 2000 4:52 AM > > To: ietf-pkix@imc.org > > Subject: Re: CRL number in CRL and ARL > > > > > > Ambarish, > > > > > If you are using CRLDPs, the numbering for each DP is independent. > > > > > > It is okay to number them in the following way: > > > > > > Time DP1 DP2 > > > 1 10 5 > > > 2 12 17 > > > 3 15 18 > > > 4 99 201 > > > 5 202 202 > > > > > > Or any other interesting scheme you would prefer, as long as > > > the numbers for DP1 are monotonically increasing and the > > > numbers for DP2 are monotoncally increasing. > > > > > > Note: This example is *not* meant to imply that you even need to > > > issue both DPs at all the times specified. > > > > Thank you very much. > > I see that the CRL number is a monotonically increasing > > number for each CRL scope. > > > > But, in your example, the CRL number is not a sequence number. > > Is this right? > > > > ----- > > Naruhito TAKIGUCHI > > FUJITSU HOKURIKU SYSTEMS LTD. > > > > > From owner-ietf-pkix@imc.org Fri Aug 11 09:11:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13545 for ; Fri, 11 Aug 2000 09:11:32 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA14957; Fri, 11 Aug 2000 06:10:09 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 11 Aug 2000 06:10:06 -0700 Received: from web109.yahoomail.com (web109.yahoomail.com [205.180.60.76]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA14923 for ; Fri, 11 Aug 2000 06:10:06 -0700 (PDT) Received: (qmail 5577 invoked by uid 60001); 11 Aug 2000 13:09:31 -0000 Message-ID: <20000811130931.5576.qmail@web109.yahoomail.com> Received: from [216.62.218.132] by web109.yahoomail.com; Fri, 11 Aug 2000 06:09:31 PDT Date: Fri, 11 Aug 2000 06:09:31 -0700 (PDT) From: Jarred Stover Subject: Unsubscribe To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe ===== "Consistency is the Hobgoblin of little minds." -Emerson __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ From owner-ietf-pkix@imc.org Fri Aug 11 09:39:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15183 for ; Fri, 11 Aug 2000 09:38:59 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA15605; Fri, 11 Aug 2000 06:37:50 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 11 Aug 2000 06:37:43 -0700 Received: from issmr5003.arthurandersen.com (ISSMR5003.awo.com [170.253.236.71]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15575 for ; Fri, 11 Aug 2000 06:37:42 -0700 (PDT) From: robert.c.boutell@us.arthurandersen.com Received: from us.arthurandersen.com (AMRHM3999.arthurandersen.com [10.0.60.29]) by issmr5003.arthurandersen.com (8.9.3/8.9.3) with SMTP id IAA23474 for ; Fri, 11 Aug 2000 08:25:09 -0500 (CDT) Received: by us.arthurandersen.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999)) id 06256938.00502CD9 ; Fri, 11 Aug 2000 08:35:43 -0600 X-Lotus-FromDomain: ANDERSEN WO To: ietf-pkix@imc.org Message-ID: <06256938.005026AA.00@us.arthurandersen.com> Date: Fri, 11 Aug 2000 08:32:22 -0600 Subject: Unsubscribe Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Unsubscribe *******************Internet Email Confidentiality Footer******************* Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it. From owner-ietf-pkix@imc.org Fri Aug 11 09:57:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16355 for ; Fri, 11 Aug 2000 09:57:37 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA16895; Fri, 11 Aug 2000 06:57:32 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 11 Aug 2000 06:57:29 -0700 Received: from picard.noroff.no ([212.20.204.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16861 for ; Fri, 11 Aug 2000 06:57:27 -0700 (PDT) Received: by picard.noroff.no (Postfix, from userid 815) id AA13C22002; Fri, 11 Aug 2000 16:41:11 +0200 (CEST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by picard.noroff.no (Postfix) with ESMTP id 048E7B3802 for ; Fri, 11 Aug 2000 16:41:09 +0200 (CEST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA11354 for ietf-123-outbound.09@ietf.org; Fri, 11 Aug 2000 09:15:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA10097 for ; Fri, 11 Aug 2000 07:01:55 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08870; Fri, 11 Aug 2000 07:01:55 -0400 (EDT) Message-Id: <200008111101.HAA08870@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ac509prof-05.txt Date: Fri, 11 Aug 2000 07:01:54 -0400 Sender: nsyracus@cnri.reston.va.us X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : An Internet Attribute Certificate Profile for Authorization Author(s) : S. Farrell, R. Housley Filename : draft-ietf-pkix-ac509prof-05.txt Pages : 37 Date : 10-Aug-00 This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ac509prof-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ac509prof-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000810140212.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ac509prof-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ac509prof-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000810140212.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@imc.org Fri Aug 11 10:24:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18864 for ; Fri, 11 Aug 2000 10:24:15 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA18586; Fri, 11 Aug 2000 07:23:55 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 11 Aug 2000 07:23:45 -0700 Received: from wafw.bear.com (wafw.bear.com [207.162.228.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18548 for ; Fri, 11 Aug 2000 07:23:44 -0700 (PDT) Received: from bear.com (localhost [127.0.0.1]) by wafw.bear.com (8.9.3/8.9.2) with SMTP id KAA24045 for ; Fri, 11 Aug 2000 10:19:01 -0400 (EDT) Received: from 147.107.147.19 by whmsxvs1.is.bear.com (InterScan E-Mail VirusWall NT); Fri, 11 Aug 2000 10:13:36 -0400 (Eastern Daylight Time) Received: by whmsx2.is.bear.com with Internet Mail Service (5.5.2448.0) id ; Fri, 11 Aug 2000 10:17:41 -0400 Message-ID: <991708270E97D211998300A0C99B237602EA24E6@whmsx19.is.bear.com> From: "Luo, Feng (Exchange)" To: "'ietf-pkix@imc.org'" Date: Fri, 11 Aug 2000 10:17:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Unsubscribe *********************************************************************** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *********************************************************************** From owner-ietf-pkix@imc.org Fri Aug 11 17:12:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05357 for ; Fri, 11 Aug 2000 17:12:29 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA12604; Fri, 11 Aug 2000 14:11:00 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 11 Aug 2000 14:09:35 -0700 Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA12534 for ; Fri, 11 Aug 2000 14:09:34 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <39939CCD.35D95A82@penta3.es> References: <39939CCD.35D95A82@penta3.es> Date: Fri, 11 Aug 2000 14:09:00 -0700 To: ietf-pkix@imc.org From: Paul Hoffman / IMC Subject: Re: Unsuscribe Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe To everyone who is trying to unsubscribe: Send a message to ietf-pkix-request@imc.org, with the single word "unsubscribe" in the body of the message. (Yes, this is identical to the instructions that you received when you subscribed to the mailing list...) If you have problems, send a message to me. Please do not send messages to the whole mailing list. It is a waste of everyone's time to read your request, and it does not get you unsubscribed from the list. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-pkix@imc.org Fri Aug 11 17:18:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05461 for ; Fri, 11 Aug 2000 17:18:29 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA12914; Fri, 11 Aug 2000 14:18:29 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 11 Aug 2000 14:18:26 -0700 Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA12879 for ; Fri, 11 Aug 2000 14:18:25 -0700 (PDT) From: Lynn.Wheeler@firstdata.com Received: from mailgw.firstdata.com ([204.48.27.156]) by mail01-ewr.pilot.net with ESMTP id RAA23532; Fri, 11 Aug 2000 17:17:52 -0400 (EDT) Received: from lnsunr02.firstdata.com (localhost [127.0.0.1]) by mailgw.firstdata.com with SMTP id RAA02591; Fri, 11 Aug 2000 17:17:51 -0400 (EDT) Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256938.007463EA ; Fri, 11 Aug 2000 17:11:17 -0400 X-Lotus-FromDomain: FDC To: kelm@secorvo.de cc: "'ietf-pkix@imc.org'" Message-ID: <85256938.007461E6.00@lnsunr02.firstdata.com> Date: Fri, 11 Aug 2000 14:06:39 -0700 Subject: STANDARDS WHICH SUPPORT DIGITAL SIGNATURES AVAILABLE Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=PuERWxyshKgIejOeIJKeAOqBsWgZ1j9rTIhS1rDD9bLDWgkZmA55tjH3" Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --0__=PuERWxyshKgIejOeIJKeAOqBsWgZ1j9rTIhS1rDD9bLDWgkZmA55tjH3 Content-type: text/plain; charset=us-ascii Content-Disposition: inline possibly of some interest ... ---------------------- Forwarded by Lynn Wheeler/CA/FDMS/FDC on 08/11/2000 12:38 PM --------------------------- dbarnes@aba.com on 08/10/2000 08:51:10 AM To: Distribution@www.Autometricweb.COM Subject: STANDARDS WHICH SUPPORT DIGITAL SIGNATURES AVAILABLE http://www.x9.org/altavista/x9/dispatch.cgi/_T_X9F_docshare/showFolder/100119C ONTACT: John Hall (202) 663-5473 STANDARDS WHICH SUPPORT DIGITAL SIGNATURES AVAILABLE WASHINGTON, Aug. 10 -- Standards for adopting digital signatures -- the latest financial tool for validating e-commerce transactions -- are availaable through the Accredited Standards Committee X9, the national standards setting body for the financial services industry. ASC X9 is accredited by the American National Standards Institute (ANSI). These standards are the cornerstone for the new federal law governing digital signatures, which goes into effect in October of this year. Assuring wide usage, the ASC X9 digital signature standards listed below have all been adopted in the Federal Information Processing Standard (FIPS) FIPS 186-2, Digital Signature Standard (DSS), as the only signature algorithms approved for use by the U.S. government. ASC X9 and the National Institute for Standards and Technology (NIST), an agency of the federal government, are developing procedures for testing and validating products designed to use these standards. Once established, institutions will be able to purchase products validated by a laboratory accredited by both the U.S. and Canadian governments. The standards define procedures for generating, verifying and securing digital signatures. They include: Public Key Cryptography Using Irreversible Algorithms (X9.30-1), Part 1: The Digital Signature Algorithm (DSA). This standard defines a method for digital signature generation and verification of financial messages and data using the DSA. In addition, the standard provides criteria for generation of public and private keys required by DSA and the procedural controls needed for the secure use of the algorithm. Public Key Cryptography Using Irreversible Algorithms (X9.30-2), Part 2: The Secure Hash Algorithm (SHA-1). This standard defines a technique for computing a shortened representation of a message digest, which is computed during the digital signature generation and verification process. Any subsequent change to the message will, with a very high probability, result in a different message digest, and the signature will fail to verify. Digital Signatures Using Reversible Public Key Cryptography for the Financial Services Industry (X9.31) This standard defines a method for digital signature generation and verification to protect financial messages and data using reversible public key cryptography systems with message recovery. The standard also provides the criteria for the generation of public and private keys required by the algorithm and the procedural controls required for algorithm security. The standard guards against more modern factoring attacks such as the Elliptic Curve Method, the Quadratic Sieve and the Number Field Sieve by requiring that the key be sufficiently large to make attacks infeasible. Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA) (X9.62) This standard defines methods for digital signature generation and verification for the protection of messages and data using the ECDSA. ECDSA is the elliptic curve analogue of the Digital Signature Algorithm (DSA). In addition, this ECDSA standard provides the criteria for the generation of public and private keys that are required by the algorithm and the procedural controls required for the secure use of the algorithm. Priced from $40 - $80 each, they are available electronically at the ASC X9 Web site's Electronic Standards Store (ESS) at www.x9.org or through the ANSI Web store at www.ansi.org. To order hard copies of these standards and more, call Global Engineering Documents at 1-800-854-7179. For more information about ASC X9 or its committees, contact Cynthia Fuller, managing director, at (202) 663-5284 Accredited Standards Committee X9 is the only industry-wide forum that brings together bankers, securities professionals, manufacturers, regulators, associations, consultants and others in the financial services arena to address technical problems, find the best solutions and codify them as nationally accepted standards. The American National Standards Institute (ANSI) accredited ASC X9 in 1984. The American Bankers Association serves as ASC X9 secretariat, providing administrative support. The ABA brings together all categories of banking institutions to best represent the interests of this rapidly changing industry. Its membership --0__=PuERWxyshKgIejOeIJKeAOqBsWgZ1j9rTIhS1rDD9bLDWgkZmA55tjH3 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =F9 which includes community, regional and money center banks and holding companies, as we= ll as savings associations, trust companies and savings banks makes ABA the l= argest banking trade association in the country. ABA can be found on the Inter= net at www.aba.com. # # # Hector Cruz ABA, Public Relations hcruz@aba.com (202) 663-5315 Forum: X9F - Data & Information Security Discussions and Documents Entry: STANDARDS WHICH SUPPORT DIGITAL SIGNATURES AVAILABLE From: David Barnes Date: 08/10/00 09:46 AM = --0__=PuERWxyshKgIejOeIJKeAOqBsWgZ1j9rTIhS1rDD9bLDWgkZmA55tjH3-- From owner-ietf-pkix@imc.org Fri Aug 11 18:11:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06625 for ; Fri, 11 Aug 2000 18:11:36 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA14028; Fri, 11 Aug 2000 15:11:47 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 11 Aug 2000 15:11:42 -0700 Received: from nxs_vyr_dns.sie.cl ([206.48.156.90]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA13998 for ; Fri, 11 Aug 2000 15:11:38 -0700 (PDT) Received: from jperez ([192.168.4.178]) by nxs_vyr_dns.sie.cl (8.9.3/8.9.3) with SMTP id SAA05524; Fri, 11 Aug 2000 18:15:48 -0400 Reply-To: From: =?iso-8859-1?Q?Juan_Carlos_P=E9rez_Aguayo?= To: "'Ietf-Pkix" , Subject: RE: Client-side revocation checking capability Date: Fri, 11 Aug 2000 18:09:59 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Ambarish: I have been the "magic extensions" in Netscape and I belive that's ok, but only Netscape Server does those checking... If clients applications don't have native on-line checking support, then the options like the check-box in the Advanced\Options\Security in IE5.x, when say "Chek for publisher's certificate revocation" and "Chek for server certificate revocation" does not do anything at all , Ok ? I think that only check if a server certificate, on a SSL connection, belong to the "trusted certificate store" defined for IE. Those type of messages seem communicate erroneus propose... Regards Juan Carlos > -----Original Message----- >De: "Ambarish Malpani" >Para: ; ; "''Ietf-Pkix'" >Asunto: RE: Client-side revocation checking capability >Fecha: Jueves, 10 de Agosto de 2000 19:46 >Hi Juan, > I agree with Jeff that most client applications don't do >revocation checking. To the best of my belief, some of the 3.0 >versions of Netscape Navigator etc. could do CRL checking if the >cert had some magic extensions in them. > >Communicator 4.7, with the PSM module does a pretty reasonable >job of revocation checking with OCSP. We (ValiCert) do have >a plugin for both IE 5.0 and Outlook that can also enable those >applications to do revocation checking with OCSP. > >We also have plugins for Netscape Enterprise Server and IIS, but >you don't seem to be interested in servers from your mail. > >Regards, >Ambarish > > >--------------------------------------------------------------------- >Ambarish Malpani >Architect 650.567.5457 >ValiCert, Inc. ambarish@valicert.com >339 N. Bernardo Ave. http://www.valicert.com >Mountain View, CA 94043 > -----Original Message----- > From: Jeff Spinney [mailto:spinneyj@flashcom.net] > Sent: Thursday, August 10, 2000 3:05 PM > To: juancarlos.perez@acepta.com; ''Ietf-Pkix' > Subject: RE: Client-side revocation checking capability > > > OCSP server vendors such as CertCo (www.certco.com) or Valicert > (www.valicert.com) have toolkits with which you can OCSP 'enable' an > application. This is great for application vendors who wish > to make their > apps more robust and certificate enabled. Most applications > at this point in > the game are not OCSP enabled even if they can deal with > certificates, they > do the basic crypto checking *if* they have the issuer cert > on hand, but do > not do real time status checking to see whether or not the > cert has been > revoked since it was issued. > > in that regard, it seems as though the application > market needs to be > persuaded to make their software support real time certificate status > checking. > > > As for Netscape, they do have an OCSP client for their > browser. I am unsure > if it is publically available at this time. It loads into the > security area, > under 'advanced' and gives you the option to specify an OCSP > responder. In > my experiance, and it was in the early stages of this modules > lifetime, it > was very finicky. If i remember correctly, it wanted the > OCSP response to > be sgned by the same cert that signed the cert being checked. > This may not > always be the case. > > > -j > > > > -----Original Message----- > From: Juan Carlos Pérez Aguayo [mailto:juancarlos.perez@acepta.com] > Sent: Thursday, August 10, 2000 12:36 PM > To: 'Ietf-Pkix > Subject: Client-side revocation checking capability > > > I am in trouble about this: What is the real support that have the > client-side software for certificate revocation checking now? > i.e. (Internet > Explorer, Netscape, etc.) > > I heard that, in fact, client-applications don`t do any > revocation checking > at all? It's that truly? > > What is the real capability of those client applications this time? > > By example, I know that Netscape define some certificate > extensions for > managing revocation, but I am not sure if realy work > > Can anyone give me some help? > > Thanks you > > > > Juan Carlos Pérez Aguayo > Software Engineer > Acepta.com > juancarlos.perez@acepta.com > > From owner-ietf-pkix@imc.org Sat Aug 12 01:04:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14727 for ; Sat, 12 Aug 2000 01:04:45 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA05660; Fri, 11 Aug 2000 22:04:05 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 11 Aug 2000 22:03:57 -0700 Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA05615 for ; Fri, 11 Aug 2000 22:03:55 -0700 (PDT) Received: from mega (t5o69p73.telia.com [213.64.110.73]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id HAA29863; Sat, 12 Aug 2000 07:03:07 +0200 (CEST) Message-ID: <002201c00422$d9da85b0$0201a8c0@mega.vincent.se> From: "Anders Rundgren" To: , "'Ietf-Pkix" Subject: Re: Client-side revocation checking capability Date: Sat, 12 Aug 2000 08:02:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA05617 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Juan Carlos, That on-line checking of server-certificates is not standard in browsers is probably beacuse a revocation is not that likely to happen. In case of a key compromize at the VeriSign CA the whole world will be notified and in the case of key compromize in a web-server no one will know or be notified. You can steal a web-cert+key from a lousy installation (most are) in case you have sys-admin rights. Nothing to do about except tighten up internal security. And if the host-name is no longer valid (the company filed for bancruptsy) the server will be taken down some day. IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where you may revoke yourself due to loss (of card) or by the company because you got fired. This is a slightly different answer than you get by asking a typical crypto expert but to my knowledge they usually know zilch, nada etc. about practical things that may be 100 times more important than the cryptologic solurtion. I.e. as long as there are serious practical problems associated with server-certificates, CRLs etc. would basically add nothing (but delays). Regards Anders From owner-ietf-pkix@imc.org Sat Aug 12 02:16:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27620 for ; Sat, 12 Aug 2000 02:16:58 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA09726; Fri, 11 Aug 2000 23:05:14 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 11 Aug 2000 23:05:04 -0700 Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA09677 for ; Fri, 11 Aug 2000 23:05:03 -0700 (PDT) Received: from m3.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0006-Fujitsu Gateway) id PAA01942 for ; Sat, 12 Aug 2000 15:03:51 +0900 (JST) (envelope-from takiguti@fjh.se.fujitsu.co.jp) Received: from nic10.fjh.se.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.9.3/3.7W-0008-Fujitsu Domain Master) id PAA23810; Sat, 12 Aug 2000 15:03:50 +0900 (JST) Received: from anakin (anakin.fjh.se.fujitsu.co.jp [10.131.201.130]) by nic10.fjh.se.fujitsu.co.jp (8.9.3+3.2W/3.7W) with ESMTP id PAA28203 for ; Sat, 12 Aug 2000 15:03:49 +0900 (JST) Date: Sat, 12 Aug 2000 15:03:49 +0900 From: TAKIGUCHI Naruhito To: ietf-pkix@imc.org Subject: Re: CRL number in CRL and ARL In-Reply-To: References: Message-Id: <20000812145530.5F39.TAKIGUTI@fjh.se.fujitsu.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00 (beta 25) Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Ambarish, Sharon, Thank you very much. I could understand clearly about the numbering of CRL. > An additional point on the numbering of CRLs. In the 2000 edition of > X.509, additional flexibility for CRLs was added. For example, a status > referrals extension can indicate that an authority has changed its > partitioning scheme, indirect delta CRL streams were added etc. To help > reduce confusion over the CRL numbering, the new cRLStreamIdentifier > extension was added. This new extension basically identifies a context > (e.g. full crls, CRL DPs, delta for a given CRLDP,indirect delta for a > given scope, etc) within which the cRLNumber must be unique. This > is defined in 8.5.2.7 of the 2000 text of 509: > > ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/ > > Sharon > > > -----Original Message----- > > From: Ambarish Malpani [mailto:ambarish@valicert.com] > > Sent: Thursday, August 10, 2000 7:33 PM > > To: 'TAKIGUCHI Naruhito'; ietf-pkix@imc.org > > Subject: RE: CRL number in CRL and ARL > > > > > > > > That is perfectly legal. > > > > Regards, > > Ambarish > > > > --------------------------------------------------------------------- > > Ambarish Malpani > > Architect 650.567.5457 > > ValiCert, Inc. ambarish@valicert.com > > 339 N. Bernardo Ave. http://www.valicert.com > > Mountain View, CA 94043 > > > > > > > -----Original Message----- > > > From: TAKIGUCHI Naruhito [mailto:takiguti@fjh.se.fujitsu.co.jp] > > > Sent: Thursday, August 10, 2000 4:52 AM > > > To: ietf-pkix@imc.org > > > Subject: Re: CRL number in CRL and ARL > > > > > > > > > Ambarish, > > > > > > > If you are using CRLDPs, the numbering for each DP is independent. > > > > > > > > It is okay to number them in the following way: > > > > > > > > Time DP1 DP2 > > > > 1 10 5 > > > > 2 12 17 > > > > 3 15 18 > > > > 4 99 201 > > > > 5 202 202 > > > > > > > > Or any other interesting scheme you would prefer, as long as > > > > the numbers for DP1 are monotonically increasing and the > > > > numbers for DP2 are monotoncally increasing. > > > > > > > > Note: This example is *not* meant to imply that you even need to > > > > issue both DPs at all the times specified. > > > > > > Thank you very much. > > > I see that the CRL number is a monotonically increasing > > > number for each CRL scope. > > > > > > But, in your example, the CRL number is not a sequence number. > > > Is this right? > > > > > > ----- > > > Naruhito TAKIGUCHI > > > FUJITSU HOKURIKU SYSTEMS LTD. > > > > > > > > ----- Naruhito TAKIGUCHI FUJITSU HOKURIKU SYSTEMS LTD. From owner-ietf-pkix@imc.org Mon Aug 14 03:18:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01723 for ; Mon, 14 Aug 2000 03:18:19 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA01988; Mon, 14 Aug 2000 00:17:27 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Aug 2000 00:16:06 -0700 Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA01939 for ; Mon, 14 Aug 2000 00:16:03 -0700 (PDT) Received: from sigma (sigma.initech.com [203.238.37.133]) by venus.initech.com (8.9.3/8.9.3) with SMTP id QAA26818 for ; Mon, 14 Aug 2000 16:12:47 +0900 (KST) Reply-To: From: "Kwon, YongChul" To: Subject: PKIFailureInfo in RFC-2510 Date: Mon, 14 Aug 2000 16:13:37 +0900 Message-ID: <005901c005bf$2ae02940$8525eecb@initech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="EUC-KR" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit I have a question in PKIFailureInfo in RFC-2510 the PKIFailureInfo type is defined in 2510 like this. PKIFailureInfo ::= BIT STRING { badAlg (0), badMessageCheck (1), badRequest (2), ... } the value (0), (1), (2)... means just INTEGER value? or n-th bit is on? if it just means INTEGER, I wonder why its type is defined as BIT STRING rather than INTEGER. :-( --------------- Kwon, YongChul(godslord@initech.com) Institute of Researching Security Technology of Initiative Technology, Inc. From owner-ietf-pkix@imc.org Mon Aug 14 07:02:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03411 for ; Mon, 14 Aug 2000 07:02:51 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA08810; Mon, 14 Aug 2000 04:02:42 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Aug 2000 04:02:32 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA08780 for ; Mon, 14 Aug 2000 04:02:31 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03351; Mon, 14 Aug 2000 07:02:10 -0400 (EDT) Message-Id: <200008141102.HAA03351@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-pi-01.txt Date: Mon, 14 Aug 2000 07:02:10 -0400 Sender: nsyracus@cnri.reston.va.us Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Permanent Identifier Author(s) : D. Pinkas, T. Gindin Filename : draft-ietf-pkix-pi-01.txt Pages : 9 Date : 11-Aug-00 This document define a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to a physical person. The permanent identifier is an optional feature that may be used by a CA to indicate that the certificate relates to the same individual even if the name of that individual has changed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-pi-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-pi-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000811100400.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-pi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-pi-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000811100400.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@imc.org Mon Aug 14 08:52:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05916 for ; Mon, 14 Aug 2000 08:52:15 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA10292; Mon, 14 Aug 2000 05:50:24 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Aug 2000 05:50:17 -0700 Received: from exchng-fairfax.pec.com (exchng-fairfax.pec.com [204.254.216.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10260 for ; Mon, 14 Aug 2000 05:50:16 -0700 (PDT) Received: by EXCHNG-FAIRFAX with Internet Mail Service (5.5.2650.21) id ; Mon, 14 Aug 2000 08:51:24 -0400 Message-ID: <5023FFCA43D8D311A8360008C7F450FDABFE3F@EXCHNG-FAIRFAX> From: GMurphy To: "'ietf-pkix@imc.org'" Date: Mon, 14 Aug 2000 08:51:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C005EE.59E77760" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C005EE.59E77760 Content-Type: text/plain unsubscribe ------_=_NextPart_001_01C005EE.59E77760 Content-Type: text/html

unsubscribe

------_=_NextPart_001_01C005EE.59E77760-- From owner-ietf-pkix@imc.org Mon Aug 14 10:15:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09275 for ; Mon, 14 Aug 2000 10:15:49 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA11932; Mon, 14 Aug 2000 07:15:30 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Aug 2000 07:15:15 -0700 Received: from picard.noroff.no ([212.20.204.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11892 for ; Mon, 14 Aug 2000 07:15:13 -0700 (PDT) Received: by picard.noroff.no (Postfix, from userid 815) id D89D62201F; Mon, 14 Aug 2000 16:59:32 +0200 (CEST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by picard.noroff.no (Postfix) with ESMTP id 2719DB3802 for ; Mon, 14 Aug 2000 16:59:27 +0200 (CEST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA19907 for ietf-123-outbound.09@ietf.org; Mon, 14 Aug 2000 09:25:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA18755 for ; Mon, 14 Aug 2000 07:02:10 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03351; Mon, 14 Aug 2000 07:02:10 -0400 (EDT) Message-Id: <200008141102.HAA03351@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-pi-01.txt Date: Mon, 14 Aug 2000 07:02:10 -0400 Sender: nsyracus@cnri.reston.va.us X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Permanent Identifier Author(s) : D. Pinkas, T. Gindin Filename : draft-ietf-pkix-pi-01.txt Pages : 9 Date : 11-Aug-00 This document define a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to a physical person. The permanent identifier is an optional feature that may be used by a CA to indicate that the certificate relates to the same individual even if the name of that individual has changed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-pi-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-pi-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000811100400.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-pi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-pi-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000811100400.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@imc.org Mon Aug 14 11:06:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11226 for ; Mon, 14 Aug 2000 11:05:58 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA13139; Mon, 14 Aug 2000 08:05:38 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Aug 2000 08:05:34 -0700 Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13109 for ; Mon, 14 Aug 2000 08:05:32 -0700 (PDT) Received: from kant [129.27.152.76] by iaik.tu-graz.ac.at (SMTPD32-6.00) id AAA337E0090; Mon, 14 Aug 2000 17:05:07 +0200 Message-ID: <002801c00601$05b4c1c0$4c981b81@iaik.tugraz.ac.at> From: "Christian Vogel" To: Subject: Time Stamp Protocol implementation Date: Mon, 14 Aug 2000 17:05:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA13110 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit I have implemented the Time Stamp Protocol . I would be pleased to test my implementation against other implementations. I will run a TCP/IP time stamping server on the IP address 129.27.142.232 port 318 The time stamp is still very inaccurate, since the automatic time correction of the server doesn't work until now but in a few days. The server does not accept any PolicyInformation and no Extensions (but you can try it). The accuracy was adjusted to 3600.111999 seconds;-) I am grateful for each note. Thanks Christian Vogel -- Christian Vogel office: [cvogel@iaik.at] [http://jcewww.iaik.tu-graz.ac.at] private: [bird@sbox.tu-graz.ac.at] [http://www.sbox.tu-graz.ac.at/home/b/bird] From owner-ietf-pkix@imc.org Mon Aug 14 13:38:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15580 for ; Mon, 14 Aug 2000 13:38:11 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA20990; Mon, 14 Aug 2000 10:38:05 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Aug 2000 10:37:53 -0700 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA20959 for ; Mon, 14 Aug 2000 10:37:52 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 14 Aug 2000 11:36:38 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 14 Aug 2000 11:36:38 -0600 From: "Bob Jueneman" To: , , Subject: Re: Client-side revocation checking capability Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA20960 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Anders, There is a lot of practical truth in what you say. CRL checking certainly seems like a nice thing to do cryptographically, until you consider what the threat is that you are trying to address. Let's suppose amazon.com's key were compromised somehow. What would happen? Well, the first thing is that they would call up their CA and get a new certificate, and then download that certificate to any SSL user. So the old certificate and key would be completely out of the picture, and hence no CRL would be needed, much less OCSP. since they don't use that certificate to sign anything other than SSL sessions, which in which the certificates are sent in line, they don't even need to revoke their old certs -- just stop using them. The only case where a CRL might be useful in that scenario would be in the case of some fly-by-night mafia.com type of store-front, where the CA might conceivably revoke the certificate for fraud or other cause. However, that would represent a substantial legal liability for the CA, and so that doesn't seem terribly likely in practice. Since the retail merchant accounts for the overwhelming use of PKI to date (e-mail is just barely beginning to make a dent, and everything else are just pilots, it isn't surprising that the browsers don't enable CRL checking by default. It would merely add lots of delay and processing time. Bob >>> "Anders Rundgren" 08/12/00 12:02AM >>> Juan Carlos, That on-line checking of server-certificates is not standard in browsers is probably beacuse a revocation is not that likely to happen. In case of a key compromize at the VeriSign CA the whole world will be notified and in the case of key compromize in a web-server no one will know or be notified. You can steal a web-cert+key from a lousy installation (most are) in case you have sys-admin rights. Nothing to do about except tighten up internal security. And if the host-name is no longer valid (the company filed for bancruptsy) the server will be taken down some day. IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where you may revoke yourself due to loss (of card) or by the company because you got fired. This is a slightly different answer than you get by asking a typical crypto expert but to my knowledge they usually know zilch, nada etc. about practical things that may be 100 times more important than the cryptologic solurtion. I.e. as long as there are serious practical problems associated with server-certificates, CRLs etc. would basically add nothing (but delays). Regards Anders From owner-ietf-pkix@imc.org Mon Aug 14 13:59:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16144 for ; Mon, 14 Aug 2000 13:59:53 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA21583; Mon, 14 Aug 2000 10:57:57 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Aug 2000 10:57:55 -0700 Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21551 for ; Mon, 14 Aug 2000 10:57:54 -0700 (PDT) Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.11.0/8.11.0) with ESMTP id e7EHue275864; Mon, 14 Aug 2000 10:56:40 -0700 (PDT) Message-ID: <399832D7.44313089@software-munitions.com> Date: Mon, 14 Aug 2000 10:56:39 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Jueneman CC: juancarlos.perez@acepta.com, ietf-pkix@imc.org, anders.rundgren@telia.com Subject: Re: Client-side revocation checking capability References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Bob Jueneman wrote: > > Anders, > > There is a lot of practical truth in what you say. > > CRL checking certainly seems like a nice thing to do > cryptographically, until you consider what the threat is that you > are trying to address. > > Let's suppose amazon.com's key were compromised somehow. What > would happen? Well, the first thing is that they would call up > their CA and get a new certificate, and then download that > certificate to any SSL user. So the old certificate and key would > be completely out of the picture, and hence no CRL would be > needed, much less OCSP. since they don't use that certificate to > sign anything other than SSL sessions, which in which the > certificates are sent in line, they don't even need to revoke > their old certs -- just stop using them. > > The only case where a CRL might be useful in that scenario would > be in the case of some fly-by-night mafia.com type of store-front, > where the CA might conceivably revoke the certificate for fraud > or other cause. However, that would represent a substantial legal > liability for the CA, and so that doesn't seem terribly likely > in practice. > > Since the retail merchant accounts for the overwhelming use of PKI > to date (e-mail is just barely beginning to make a dent, and > everything else are just pilots, it isn't surprising that the > browsers don't enable CRL checking by default. It would merely add > lots of delay and processing time. > I disagree. To access www.amazon.com one uses DNS, which is not secure and often easy to poison. Consequently, mafia.com can redirect some number of browsers by poisoning some number of DNS servers, present a Amazon.COM store front, and use Amazon's cert and private key. If the browser doesn't check for revocation then the consumer is none the wiser, at least for a while. > Bob > > >>> "Anders Rundgren" 08/12/00 12:02AM >>> > Juan Carlos, > > That on-line checking of server-certificates is not standard in browsers is probably > beacuse a revocation is not that likely to happen. In case of a key compromize at the VeriSign > CA the whole world will be notified and in the case of key compromize in a web-server no > one will know or be notified. You can steal a web-cert+key from a lousy installation (most are) > in case you have sys-admin rights. Nothing to do about except tighten up internal security. > And if the host-name is no longer valid (the company filed for bancruptsy) the > server will be taken down some day. > > IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where > you may revoke yourself due to loss (of card) or by the company because you got fired. > > This is a slightly different answer than you get by asking a typical crypto expert but to my > knowledge they usually know zilch, nada etc. about practical things that may be 100 times more > important than the cryptologic solurtion. I.e. as long as there are serious practical problems > associated with server-certificates, CRLs etc. would basically add nothing (but delays). > > Regards > Anders -- Dennis Glatting Copyright (c) 2000 Software Munitions From owner-ietf-pkix@imc.org Mon Aug 14 15:12:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17385 for ; Mon, 14 Aug 2000 15:12:11 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA22933; Mon, 14 Aug 2000 12:10:34 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Aug 2000 12:10:20 -0700 Received: from mail02-ewr.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22891 for ; Mon, 14 Aug 2000 12:10:18 -0700 (PDT) From: Lynn.Wheeler@firstdata.com Received: from mailgw.firstdata.com ([204.48.27.156]) by mail02-ewr.pilot.net with ESMTP id PAA03336; Mon, 14 Aug 2000 15:09:57 -0400 (EDT) Received: from lnsunr02.firstdata.com (localhost [127.0.0.1]) by mailgw.firstdata.com with SMTP id PAA03531; Mon, 14 Aug 2000 15:09:56 -0400 (EDT) Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525693B.0068C730 ; Mon, 14 Aug 2000 15:04:27 -0400 X-Lotus-FromDomain: FDC To: Dennis Glatting cc: Bob Jueneman , juancarlos.perez@acepta.com, ietf-pkix@imc.org, anders.rundgren@telia.com Message-ID: <8525693B.0068C56E.00@lnsunr02.firstdata.com> Date: Mon, 14 Aug 2000 12:08:31 -0700 Subject: Re: Client-side revocation checking capability Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe it goes further than that ... since the "authority" for which domain name certificates are issued is the domain authority .... it is possible to "poisen" that infrastructure (domain name hijacking) ... apply for a certificate ... have it verified as valid by the domain name infrastructure, and have such a certificate certified as valid. there are proposals for improving the infrastructure of the domain name infrastructure with digital signatures and public keys .... which addresses both dynamic poisening as well as domain name hijacking types of poisen. Such a trusted DNS infrastructure then could also return the same public key as part of domain name lookup. At that point, existing certificates become superfulous and redundant. In part, the problem of vulnerable DNS infrastructure is not only the dynamic name lookups but also extends to core DNS infrastructure ... which domain name certificates rely on for validating information that goes into a certificate. Addressing the vulnerabilities of the DNS infrastructure (for both dynamic name lookup as well as certification/validating of certificate information) turns out to also make certificates redundant and superfulous. Dennis Glatting on 08/14/2000 10:56:39 AM To: Bob Jueneman cc: juancarlos.perez@acepta.com, ietf-pkix@imc.org, anders.rundgren@telia.com Subject: Re: Client-side revocation checking capability I disagree. To access www.amazon.com one uses DNS, which is not secure and often easy to poison. Consequently, mafia.com can redirect some number of browsers by poisoning some number of DNS servers, present a Amazon.COM store front, and use Amazon's cert and private key. If the browser doesn't check for revocation then the consumer is none the wiser, at least for a while. > Bob > > >>> "Anders Rundgren" 08/12/00 12:02AM >>> > Juan Carlos, > > That on-line checking of server-certificates is not standard in browsers is probably > beacuse a revocation is not that likely to happen. In case of a key compromize at the VeriSign > CA the whole world will be notified and in the case of key compromize in a web-server no > one will know or be notified. You can steal a web-cert+key from a lousy installation (most are) > in case you have sys-admin rights. Nothing to do about except tighten up internal security. > And if the host-name is no longer valid (the company filed for bancruptsy) the > server will be taken down some day. > > IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where > you may revoke yourself due to loss (of card) or by the company because you got fired. > > This is a slightly different answer than you get by asking a typical crypto expert but to my > knowledge they usually know zilch, nada etc. about practical things that may be 100 times more > important than the cryptologic solurtion. I.e. as long as there are serious practical problems > associated with server-certificates, CRLs etc. would basically add nothing (but delays). > > Regards > Anders -- Dennis Glatting Copyright (c) 2000 Software Munitions From owner-ietf-pkix@imc.org Mon Aug 14 15:19:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17500 for ; Mon, 14 Aug 2000 15:19:40 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA23337; Mon, 14 Aug 2000 12:17:26 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Aug 2000 12:17:24 -0700 Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23304 for ; Mon, 14 Aug 2000 12:17:22 -0700 (PDT) Received: from mega (t3o69p11.telia.com [62.20.145.11]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id VAA15310; Mon, 14 Aug 2000 21:16:44 +0200 (CEST) Message-ID: <002601c0062c$6dc07130$0201a8c0@mega.vincent.se> From: "Anders Rundgren" To: "Dennis Glatting" , "Bob Jueneman" Cc: , Subject: Re: Client-side revocation checking capability Date: Mon, 14 Aug 2000 22:15:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA23306 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Dennis, >I disagree. To access www.amazon.com one uses DNS, which is not secure >and often easy to poison. Consequently, mafia.com can redirect some >number of browsers by poisoning some number of DNS servers, present a >Amazon.COM store front, and use Amazon's cert and private key. If the >browser doesn't check for revocation then the consumer is none the >wiser, at least for a while. I assume that you refer to the situation where a web-site key is compromized (stolen, copied)? This is very hard to detect if they have low security standards. And if they have high security standards it is unlikely to happen. Since server-based PKI is likely to skyrocket for other purposes than SSL, I believe that it is more important to get cheap hardware-based key-stores with built-in crypto-processing rather than on-line revocation processing, to minimize doubts like "did John copy our server key when he was found in the server-room where he should not be?" To get a new server-certificate is BTW not that trivial so it makes sense to improve local security in various ways. Anders From owner-ietf-pkix@imc.org Mon Aug 14 15:24:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17561 for ; Mon, 14 Aug 2000 15:24:30 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA23630; Mon, 14 Aug 2000 12:21:48 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Aug 2000 12:21:46 -0700 Received: from angel.algonet.se (angel.algonet.se [194.213.74.112]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA23594 for ; Mon, 14 Aug 2000 12:21:40 -0700 (PDT) Received: (qmail 22597 invoked from network); 14 Aug 2000 21:21:11 +0200 Received: from sinclair.tninet.se (HELO algonet.se) (195.100.94.101) by angel.algonet.se with SMTP; 14 Aug 2000 21:21:11 +0200 Received: from x-obi.com (sdu157-198.ppp.algonet.se [195.163.198.157]) by sinclair.tninet.se (BLUETAIL Mail Robustifier 2.2.1) with ESMTP id 607611.280868.966sinclair-s2 ; Mon, 14 Aug 2000 21:21:08 +0200 Message-ID: <39984756.A83E7C87@x-obi.com> Date: Mon, 14 Aug 2000 21:24:06 +0200 From: Henrik Bergman Reply-To: henrik.bergman@x-obi.com Organization: X-OBI X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: sv,en MIME-Version: 1.0 To: Dennis Glatting CC: juancarlos.perez@acepta.com, ietf-pkix@imc.org, anders.rundgren@telia.com Subject: Re: Client-side revocation checking capability References: <399832D7.44313089@software-munitions.com> Content-Type: multipart/mixed; boundary="------------C80DAA36B6275D04FE1C0472" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. --------------C80DAA36B6275D04FE1C0472 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dennis, The case you are discribing is hardly a good example to show why CRL's are needed for server-certificates. If www.amazon.com uses unsecure DNS and gets poisoned, the action is hardly the put the stolen cert i a CRL. Shouldn't the action be to cure the DNS? If someone can poison the unsecure DNS, shouldn't the long term goal be to secure the DNS, rather than letting all users check all servers cert in CRL's all the time? Henrik Bergman X-OBI To access one uses Dennis Glatting wrote: > Bob Jueneman wrote: > > > > Anders, > > > > There is a lot of practical truth in what you say. > > > > CRL checking certainly seems like a nice thing to do > > cryptographically, until you consider what the threat is that you > > are trying to address. > > > > Let's suppose amazon.com's key were compromised somehow. What > > would happen? Well, the first thing is that they would call up > > their CA and get a new certificate, and then download that > > certificate to any SSL user. So the old certificate and key would > > be completely out of the picture, and hence no CRL would be > > needed, much less OCSP. since they don't use that certificate to > > sign anything other than SSL sessions, which in which the > > certificates are sent in line, they don't even need to revoke > > their old certs -- just stop using them. > > > > The only case where a CRL might be useful in that scenario would > > be in the case of some fly-by-night mafia.com type of store-front, > > where the CA might conceivably revoke the certificate for fraud > > or other cause. However, that would represent a substantial legal > > liability for the CA, and so that doesn't seem terribly likely > > in practice. > > > > Since the retail merchant accounts for the overwhelming use of PKI > > to date (e-mail is just barely beginning to make a dent, and > > everything else are just pilots, it isn't surprising that the > > browsers don't enable CRL checking by default. It would merely add > > lots of delay and processing time. > > > > I disagree. To access www.amazon.com one uses DNS, which is not secure > and often easy to poison. Consequently, mafia.com can redirect some > number of browsers by poisoning some number of DNS servers, present a > Amazon.COM store front, and use Amazon's cert and private key. If the > browser doesn't check for revocation then the consumer is none the > wiser, at least for a while. > > > Bob > > > > >>> "Anders Rundgren" 08/12/00 12:02AM >>> > > Juan Carlos, > > > > That on-line checking of server-certificates is not standard in browsers is probably > > beacuse a revocation is not that likely to happen. In case of a key compromize at the VeriSign > > CA the whole world will be notified and in the case of key compromize in a web-server no > > one will know or be notified. You can steal a web-cert+key from a lousy installation (most are) > > in case you have sys-admin rights. Nothing to do about except tighten up internal security. > > And if the host-name is no longer valid (the company filed for bancruptsy) the > > server will be taken down some day. > > > > IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where > > you may revoke yourself due to loss (of card) or by the company because you got fired. > > > > This is a slightly different answer than you get by asking a typical crypto expert but to my > > knowledge they usually know zilch, nada etc. about practical things that may be 100 times more > > important than the cryptologic solurtion. I.e. as long as there are serious practical problems > > associated with server-certificates, CRLs etc. would basically add nothing (but delays). > > > > Regards > > Anders > > -- > Dennis Glatting > Copyright (c) 2000 Software Munitions -- __________________________________________ Henrik Bergman, X-OBI, mob 070-866 87 72 e-mail: henrik.bergman@x-obi.com --------------C80DAA36B6275D04FE1C0472 Content-Type: text/x-vcard; charset=us-ascii; name="henrik.bergman.vcf" Content-Description: Card for Henrik Bergman Content-Disposition: attachment; filename="henrik.bergman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Bergman;Henrik tel;cell:070-866 87 72 x-mozilla-html:FALSE org:X-OBI adr:;;;;;; version:2.1 email;internet:henrik.bergman@x-obi.com x-mozilla-cpt:;24768 fn:Henrik Bergman end:vcard --------------C80DAA36B6275D04FE1C0472-- From owner-ietf-pkix@imc.org Mon Aug 14 16:01:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18053 for ; Mon, 14 Aug 2000 16:01:28 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA24485; Mon, 14 Aug 2000 13:00:20 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Aug 2000 13:00:16 -0700 Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24455 for ; Mon, 14 Aug 2000 13:00:15 -0700 (PDT) Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.11.0/8.11.0) with ESMTP id e7EJx4276707; Mon, 14 Aug 2000 12:59:04 -0700 (PDT) Message-ID: <39984F88.43FAF1C3@software-munitions.com> Date: Mon, 14 Aug 2000 12:59:04 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: henrik.bergman@x-obi.com CC: juancarlos.perez@acepta.com, ietf-pkix@imc.org, anders.rundgren@telia.com Subject: Re: Client-side revocation checking capability References: <399832D7.44313089@software-munitions.com> <39984756.A83E7C87@x-obi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Henrik Bergman wrote: > > Dennis, > > The case you are discribing is hardly a good example to show why CRL's are needed for server-certificates. > If www.amazon.com uses unsecure DNS and gets poisoned, the action is hardly the put the stolen cert i a > CRL. > Assume we have a fairly crappy DNS server, such as the one serving pki2.com (mine and hopefully not crappy :). Start nslookup and point to my server. Tell it to look up information from your custom server (i.e., ask pki2 to lookup www.whatever.com, a zone delegated to you). Have your custom server return the sought information plus information in the extra data segment, such as "www.amazon.com IN A 206.129.5.135". Some servers will cache this extra data without checking it; others, such as BIND 8.x, will discard and log it. Since pki2 in this example is crappy then when I query it for www.amazon.com I am going to go to 206.129.5.135, not Amazon's real web site. In this case we did not poison Amazon's DNS, rather pki2's. If my browser checked for CRLs then it is likely I will see Amazon's certificate had been revoked. On the other hand, if www.amazon.com is spoofed then so can the CRL host address (it's just "extra data"). Then the question becomes what would my browser do if the spoofed CRL host doesn't answer to a CRL request. Not perfect but does raise the bar, IMO. > Shouldn't the action be to cure the DNS? If someone can poison the unsecure DNS, shouldn't the long term > goal be to secure the DNS, rather than letting all users check all servers cert in CRL's all the time? > I am highly skeptical of DNSsec. Assuming we get the roots signed; trusted keys embedded in servers; and TSIG to clients, we have to get all COMs/NETs/whatever to sign their zones and all DNS servers to upgraded. If all these things do not happen, IMO, DNSsec is fairly worthless because you are operating in an untrusted environment. Certainly you can configure your local DNS server as to which zones are DNSsec'd, which is what is done now, but that list will quickly become very long and we might as well go back to FTPing HOSTS.TXT. From owner-ietf-pkix@imc.org Mon Aug 14 16:03:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18068 for ; Mon, 14 Aug 2000 16:03:48 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA24718; Mon, 14 Aug 2000 13:02:42 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Aug 2000 13:02:40 -0700 Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24687 for ; Mon, 14 Aug 2000 13:02:39 -0700 (PDT) Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.11.0/8.11.0) with ESMTP id e7EK1d276724; Mon, 14 Aug 2000 13:01:39 -0700 (PDT) Message-ID: <39985023.EF5B5ED8@software-munitions.com> Date: Mon, 14 Aug 2000 13:01:39 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Rundgren CC: Bob Jueneman , juancarlos.perez@acepta.com, ietf-pkix@imc.org Subject: Re: Client-side revocation checking capability References: <002601c0062c$6dc07130$0201a8c0@mega.vincent.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Anders Rundgren wrote: > To get a new server-certificate is BTW not that trivial so it makes sense to improve > local security in various ways. > One of the (many) problems with the PKI as it is today (okay, SSL/TLS) is all you need is to compromise one CA and you can issue bogus server certificates and set up bogus web sites to your hearts content, at least for a while. The popular browsers have many root certificates, 58 in Netscape I believe. If you compromise one of those roots then a browser is going to accept a certificate from a compromised CA with Amazon.COM and DNS spoofed without distinction from the real Amazon.COM. Another trick is to send a viral laden e-mail message to the masses and implant a root certificate. In both cases I am skeptical of the value of CR. I am also skeptical that all consumers would repair their systems even with a flood of strongly worded advertising. So, :), I believe a compromised or spoofed (bogus embeded root certificate) root is the kind of gift that keeps on giving. From owner-ietf-pkix@imc.org Mon Aug 14 16:16:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18225 for ; Mon, 14 Aug 2000 16:16:09 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA25114; Mon, 14 Aug 2000 13:14:33 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Aug 2000 13:14:28 -0700 Received: from cnbskpt2.cnbs.navy.mil (cnbskpt2.cnbs.navy.mil [164.221.184.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA25082 for ; Mon, 14 Aug 2000 13:14:27 -0700 (PDT) Received: by cnbskpt2.cnbs.navy.mil with Internet Mail Service (5.5.2650.21) id ; Mon, 14 Aug 2000 13:09:50 -0700 Message-ID: <07278C38CF83D21181B200105AA34A859DD4B3@cnbskpt2.cnbs.navy.mil> From: "Morrill, Dan" To: "'Dennis Glatting'" , Anders Rundgren Cc: Bob Jueneman , juancarlos.perez@acepta.com, ietf-pkix@imc.org Subject: RE: Client-side revocation checking capability Date: Mon, 14 Aug 2000 13:09:50 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Dennis, My question then is, has anyone ever had a CA compromised? (not that it could not happen, but usually CA's are on the "Must Secure at all costs" level) Wouldn't that compromise be part of a policy statement? With appropriate protocols to address a security issue. I know that with the CA's that I have worked on, all of them are geared high (Paranoid) on a sensor like Real Secure, with NetRanger and some Enterprise management backup, so that if it goes red (looks like it is under attack), the system is cut off the net whenever there is a possible breach, then the folks are paged to come take a look. Normal response times, metrics and other ways of reporting data then take over. If warranted, backups, disaster recovery protocols then go into effect. Then there is network issues that can go a long way to secure a CA from compromise. I think that security of a CA is more policy than is a technical specification. Feel free to disagree. R/ Dan Morrill Computer Sciences Corporation -----Original Message----- From: Dennis Glatting [mailto:dennis.glatting@software-munitions.com] Sent: Monday, August 14, 2000 01:02 PM To: Anders Rundgren Cc: Bob Jueneman; juancarlos.perez@acepta.com; ietf-pkix@imc.org Subject: Re: Client-side revocation checking capability Anders Rundgren wrote: > To get a new server-certificate is BTW not that trivial so it makes sense to improve > local security in various ways. > One of the (many) problems with the PKI as it is today (okay, SSL/TLS) is all you need is to compromise one CA and you can issue bogus server certificates and set up bogus web sites to your hearts content, at least for a while. The popular browsers have many root certificates, 58 in Netscape I believe. If you compromise one of those roots then a browser is going to accept a certificate from a compromised CA with Amazon.COM and DNS spoofed without distinction from the real Amazon.COM. Another trick is to send a viral laden e-mail message to the masses and implant a root certificate. In both cases I am skeptical of the value of CR. I am also skeptical that all consumers would repair their systems even with a flood of strongly worded advertising. So, :), I believe a compromised or spoofed (bogus embeded root certificate) root is the kind of gift that keeps on giving. From owner-ietf-pkix@imc.org Mon Aug 14 16:42:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18550 for ; Mon, 14 Aug 2000 16:42:06 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA25887; Mon, 14 Aug 2000 13:40:57 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Aug 2000 13:40:49 -0700 Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA25855 for ; Mon, 14 Aug 2000 13:40:48 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id NAA21902; Mon, 14 Aug 2000 13:39:02 -0700 (PDT) Message-Id: <4.2.2.20000814133155.00aa0100@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 14 Aug 2000 13:48:16 -0700 To: "Morrill, Dan" , "'Dennis Glatting'" , Anders Rundgren From: Tony Bartoletti Subject: RE: Client-side revocation checking capability Cc: Bob Jueneman , juancarlos.perez@acepta.com, ietf-pkix@imc.org In-Reply-To: <07278C38CF83D21181B200105AA34A859DD4B3@cnbskpt2.cnbs.navy. mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 01:09 PM 8/14/00 -0700, Morrill, Dan wrote: >Dennis, > >My question then is, has anyone ever had a CA compromised? (not that it >could not happen, but usually CA's are on the "Must Secure at all costs" >level) Wouldn't that compromise be part of a policy statement? With >appropriate protocols to address a security issue. > >I know that with the CA's that I have worked on, all of them are geared high >(Paranoid) on a sensor like Real Secure, with NetRanger and some Enterprise >management backup, so that if it goes red (looks like it is under attack), >the system is cut off the net whenever there is a possible breach, then the >folks are paged to come take a look. Normal response times, metrics and >other ways of reporting data then take over. If warranted, backups, disaster >recovery protocols then go into effect. Then there is network issues that >can go a long way to secure a CA from compromise. > >I think that security of a CA is more policy than is a technical >specification. Feel free to disagree. I'm my view, the "likely" scenario of a CA root key compromise would follow from a "trusted" hardware technician working on the inside, swapping chips or boards under the guise of "routine service". It won't be from some net- hacker swooping in from afar. As Dennis Glatting points out, the far more reasonable scenario involves the massive covert replacement of browser "root-certs" accomplished by some viral email code, followed shortly thereafter by concerted DNS redirection to "fake" commercial sites. The fraudulent root certificates verify the fraudulent site certificates, take your credit card numbers and run. If and when that happens, I suppose browser manufacturers will see fit to make it an "option" for consumers to "self-sign" or encrypt the installed root-certs, and suffer being prompted for a "key" to verify each transaction. It seems that most "PKIs" are best suited to everyone BUT the public. ___tony___ >-----Original Message----- >From: Dennis Glatting [mailto:dennis.glatting@software-munitions.com] >Sent: Monday, August 14, 2000 01:02 PM >To: Anders Rundgren >Cc: Bob Jueneman; juancarlos.perez@acepta.com; ietf-pkix@imc.org >Subject: Re: Client-side revocation checking capability > > >Anders Rundgren wrote: > > > > To get a new server-certificate is BTW not that trivial so it makes sense >to improve > > local security in various ways. > > > >One of the (many) problems with the PKI as it is today (okay, SSL/TLS) >is all you need is to compromise one CA and you can issue bogus server >certificates and set up bogus web sites to your hearts content, at >least for a while. The popular browsers have many root certificates, >58 in Netscape I believe. If you compromise one of those roots then a >browser is going to accept a certificate from a compromised CA with >Amazon.COM and DNS spoofed without distinction from the real >Amazon.COM. Another trick is to send a viral laden e-mail message to >the masses and implant a root certificate. > >In both cases I am skeptical of the value of CR. I am also skeptical >that all consumers would repair their systems even with a flood of >strongly worded advertising. So, :), I believe a compromised or >spoofed (bogus embeded root certificate) root is the kind of gift that >keeps on giving. Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 From owner-ietf-pkix@imc.org Mon Aug 14 16:56:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18686 for ; Mon, 14 Aug 2000 16:56:08 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA26368; Mon, 14 Aug 2000 13:54:08 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Aug 2000 13:54:06 -0700 Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26338 for ; Mon, 14 Aug 2000 13:54:05 -0700 (PDT) Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.11.0/8.11.0) with ESMTP id e7EKr4276886; Mon, 14 Aug 2000 13:53:04 -0700 (PDT) Message-ID: <39985C30.A8B91F74@software-munitions.com> Date: Mon, 14 Aug 2000 13:53:04 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Morrill, Dan" CC: Anders Rundgren , Bob Jueneman , juancarlos.perez@acepta.com, ietf-pkix@imc.org Subject: Re: Client-side revocation checking capability References: <07278C38CF83D21181B200105AA34A859DD4B3@cnbskpt2.cnbs.navy.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit "Morrill, Dan" wrote: > > Dennis, > > My question then is, has anyone ever had a CA compromised? (not that it > could not happen, but usually CA's are on the "Must Secure at all costs" > level) Wouldn't that compromise be part of a policy statement? With > appropriate protocols to address a security issue. > I have not heard of any CA compromise. > I know that with the CA's that I have worked on, all of them are geared high > (Paranoid) on a sensor like Real Secure, with NetRanger and some Enterprise > management backup, so that if it goes red (looks like it is under attack), > the system is cut off the net whenever there is a possible breach, then the > folks are paged to come take a look. Normal response times, metrics and > other ways of reporting data then take over. If warranted, backups, disaster > recovery protocols then go into effect. Then there is network issues that > can go a long way to secure a CA from compromise. > > I think that security of a CA is more policy than is a technical > specification. Feel free to disagree. Of course CAs can be compromised, web sites spoofed, implementations be of low caliber, and browsers and computers attacked in various imaginative was. Some of these things are unlikely and others very likely. All are possible and some aren't very hard. The overall point of my comments is by checking CRLs we improve the quality of transactions. From owner-ietf-pkix@imc.org Mon Aug 14 17:06:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18821 for ; Mon, 14 Aug 2000 17:06:02 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA26799; Mon, 14 Aug 2000 14:04:21 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Aug 2000 14:04:18 -0700 Received: from cnbskpt2.cnbs.navy.mil (cnbskpt2.cnbs.navy.mil [164.221.184.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA26768 for ; Mon, 14 Aug 2000 14:04:17 -0700 (PDT) Received: by cnbskpt2.cnbs.navy.mil with Internet Mail Service (5.5.2650.21) id ; Mon, 14 Aug 2000 13:59:41 -0700 Message-ID: <07278C38CF83D21181B200105AA34A859DD4B5@cnbskpt2.cnbs.navy.mil> From: "Morrill, Dan" To: "'Tony Bartoletti'" , "Morrill, Dan" , "'Dennis Glatting'" , Anders Rundgren Cc: Bob Jueneman , juancarlos.perez@acepta.com, ietf-pkix@imc.org Subject: RE: Client-side revocation checking capability Date: Mon, 14 Aug 2000 13:59:40 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Tony & co. Sorry, this really peaks my interest, cause this is something I am dealing with. Here goes.... Tony>> I'm my view, the "likely" scenario of a CA root key compromise would follow Tony>> from a "trusted" hardware technician working on the inside, swapping chips Tony>> or boards under the guise of "routine service". It won't be from some net- Tony>> hacker swooping in from afar. Ok, since a server cert is 1 to 1 bound to IP and lots of other data for 1/2 the key, the CA cuts the other half the key, you would already have to have your 1/2 keys cut on your bogus servers, and have access to the systems to do this (RA), plus if it is entrust, you would need their web package, so much like a DDOS crack, this would have to be highly thought out and highly coordinated, with plenty of servers and bandwidth. All that for credit card numbers? It would be easier, and unfortunately far more realistic and frequent to grab the database that stores all this through the web server. I don't see a high return on this scenario for the work involved. Tony>> As Dennis Glatting points out, the far more reasonable scenario involves Tony>> the massive covert replacement of browser "root-certs" accomplished by Tony>> some viral email code, followed shortly thereafter by concerted DNS Tony>> redirection to "fake" commercial sites. The fraudulent root certificates Tony>> verify the fraudulent site certificates, take your credit card numbers Tony>> and run. Same issue, you would have had to prepped a whole catalog of systems, then run your code, easier to simulate the RA responses and mimic a trusted agent via a virus or hostile code? Again, lots of work, lots of really clever thinking if they have incorporated IPSec into the Network, plus overhead as above. Again, not a good value for the return, especially when it is easier to get credit card numbers from an improperly secured dBase or flat file driving the e-commerce site. Tony>> If and when that happens, I suppose browser manufacturers will see fit to make Tony>> it an "option" for consumers to "self-sign" or encrypt the installed Tony>> root-certs, and suffer being prompted for a "key" to verify each transaction. Browsers will already warn you about what is an unrecognized cert (one not in DB7 or the registry) or one that has expired, or one that is not meeting all the qualifications. If you poison a DNS system, and point xxx.xxx.xxx.xxx to a different server, all that cert information is really doing at the server level is initiating SSL/TLS. It is usually signed by Verisign, RSA, DST or any of the other 20+ 'root' certs already in your browser. There should be enough hokey things happening that the user will pay attention, and if they don't like with anything else, you suffer for your actions. I think again, the argument rests with, more trouble and work than it is worth because there are ton's easier ways to get credit card numbers. Now, if it was war time, and we had real enemies, this would be great for DoD's level of effort to exploit this on the web for intelligence information & etc. Maybe then this would be a "fun" issue to explore. Anyone ask what the Banking industry is doing now about this, or have they thought about it yet? Tony>> It seems that most "PKIs" are best suited to everyone BUT the public. On this point we agree. ;-) r/ Dan -----Original Message----- From: Tony Bartoletti [mailto:azb@llnl.gov] Sent: Monday, August 14, 2000 01:48 PM To: Morrill, Dan; 'Dennis Glatting'; Anders Rundgren Cc: Bob Jueneman; juancarlos.perez@acepta.com; ietf-pkix@imc.org Subject: RE: Client-side revocation checking capability At 01:09 PM 8/14/00 -0700, Morrill, Dan wrote: >Dennis, > >My question then is, has anyone ever had a CA compromised? (not that it >could not happen, but usually CA's are on the "Must Secure at all costs" >level) Wouldn't that compromise be part of a policy statement? With >appropriate protocols to address a security issue. > >I know that with the CA's that I have worked on, all of them are geared high >(Paranoid) on a sensor like Real Secure, with NetRanger and some Enterprise >management backup, so that if it goes red (looks like it is under attack), >the system is cut off the net whenever there is a possible breach, then the >folks are paged to come take a look. Normal response times, metrics and >other ways of reporting data then take over. If warranted, backups, disaster >recovery protocols then go into effect. Then there is network issues that >can go a long way to secure a CA from compromise. > >I think that security of a CA is more policy than is a technical >specification. Feel free to disagree. I'm my view, the "likely" scenario of a CA root key compromise would follow from a "trusted" hardware technician working on the inside, swapping chips or boards under the guise of "routine service". It won't be from some net- hacker swooping in from afar. As Dennis Glatting points out, the far more reasonable scenario involves the massive covert replacement of browser "root-certs" accomplished by some viral email code, followed shortly thereafter by concerted DNS redirection to "fake" commercial sites. The fraudulent root certificates verify the fraudulent site certificates, take your credit card numbers and run. If and when that happens, I suppose browser manufacturers will see fit to make it an "option" for consumers to "self-sign" or encrypt the installed root-certs, and suffer being prompted for a "key" to verify each transaction. It seems that most "PKIs" are best suited to everyone BUT the public. ___tony___ >-----Original Message----- >From: Dennis Glatting [mailto:dennis.glatting@software-munitions.com] >Sent: Monday, August 14, 2000 01:02 PM >To: Anders Rundgren >Cc: Bob Jueneman; juancarlos.perez@acepta.com; ietf-pkix@imc.org >Subject: Re: Client-side revocation checking capability > > >Anders Rundgren wrote: > > > > To get a new server-certificate is BTW not that trivial so it makes sense >to improve > > local security in various ways. > > > >One of the (many) problems with the PKI as it is today (okay, SSL/TLS) >is all you need is to compromise one CA and you can issue bogus server >certificates and set up bogus web sites to your hearts content, at >least for a while. The popular browsers have many root certificates, >58 in Netscape I believe. If you compromise one of those roots then a >browser is going to accept a certificate from a compromised CA with >Amazon.COM and DNS spoofed without distinction from the real >Amazon.COM. Another trick is to send a viral laden e-mail message to >the masses and implant a root certificate. > >In both cases I am skeptical of the value of CR. I am also skeptical >that all consumers would repair their systems even with a flood of >strongly worded advertising. So, :), I believe a compromised or >spoofed (bogus embeded root certificate) root is the kind of gift that >keeps on giving. Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 From owner-ietf-pkix@imc.org Mon Aug 14 21:14:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21552 for ; Mon, 14 Aug 2000 21:14:37 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA01097; Mon, 14 Aug 2000 18:13:06 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Aug 2000 18:12:56 -0700 Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA01047 for ; Mon, 14 Aug 2000 18:12:55 -0700 (PDT) Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000815011237.HXOT4590.mail.rdc1.md.home.com@home.com>; Mon, 14 Aug 2000 18:12:37 -0700 Message-ID: <399898E3.BBFC5AE1@home.com> Date: Mon, 14 Aug 2000 21:12:03 -0400 From: Al Arsenault Organization: @Home Network X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Morrill, Dan" CC: "'Dennis Glatting'" , Anders Rundgren , Bob Jueneman , juancarlos.perez@acepta.com, ietf-pkix@imc.org Subject: Re: Client-side revocation checking capability References: <07278C38CF83D21181B200105AA34A859DD4B3@cnbskpt2.cnbs.navy.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit This is getting kind of off-the-track of "checking whether or not user certificates have been revoked", but... Of equal interest to CA compromise is the case where the CA goes bankrupt. Then the CA's private key is in essence "compromised" by, for example, being auctioned to the highest bidder. It's analogous to the situation that happens all too often today where, when a dot.com starts running into financial trouble, or actually goes under, the customers' private information is sold to the highest bidder or to many bidders to raise funds, pay off creditors, etc. So the company with its public key embedded in IE and/or Netscape goes belly-up. In swoops "Joe's Storm Door and Network Security Company" with a sweet financial bid for the private key, either directly or through the bankruptcy court. (That private key is an asset of the company and can be disposed of in a manner that raises the most value for the creditors.) Once "JSD&NSC" has the private key, who knows what kinds of certs get issued. And since the public key is embedded in millions of copies of the browsers, and can't easily be removed except for millions of users doing it manually, or upgrading to the next version of the browser that doesn't have that "trusted" root key embedded in it, ... (I'll leave it to the reader to figure out what can happen, to whom, and for how long.) BTW: this has already happened, in real life. Apparently, the bids in bankruptcy court for the private key started soaring to fairly high levels, rather quickly. Turned out to be just about the only marketable asset the company had. Al Arsenault "Morrill, Dan" wrote: > > Dennis, > > My question then is, has anyone ever had a CA compromised? (not that it > could not happen, but usually CA's are on the "Must Secure at all costs" > level) Wouldn't that compromise be part of a policy statement? With > appropriate protocols to address a security issue. > > I know that with the CA's that I have worked on, all of them are geared high > (Paranoid) on a sensor like Real Secure, with NetRanger and some Enterprise > management backup, so that if it goes red (looks like it is under attack), > the system is cut off the net whenever there is a possible breach, then the > folks are paged to come take a look. Normal response times, metrics and > other ways of reporting data then take over. If warranted, backups, disaster > recovery protocols then go into effect. Then there is network issues that > can go a long way to secure a CA from compromise. > > I think that security of a CA is more policy than is a technical > specification. Feel free to disagree. > R/ > Dan Morrill > Computer Sciences Corporation > > -----Original Message----- > From: Dennis Glatting [mailto:dennis.glatting@software-munitions.com] > Sent: Monday, August 14, 2000 01:02 PM > To: Anders Rundgren > Cc: Bob Jueneman; juancarlos.perez@acepta.com; ietf-pkix@imc.org > Subject: Re: Client-side revocation checking capability > > Anders Rundgren wrote: > > > > To get a new server-certificate is BTW not that trivial so it makes sense > to improve > > local security in various ways. > > > > One of the (many) problems with the PKI as it is today (okay, SSL/TLS) > is all you need is to compromise one CA and you can issue bogus server > certificates and set up bogus web sites to your hearts content, at > least for a while. The popular browsers have many root certificates, > 58 in Netscape I believe. If you compromise one of those roots then a > browser is going to accept a certificate from a compromised CA with > Amazon.COM and DNS spoofed without distinction from the real > Amazon.COM. Another trick is to send a viral laden e-mail message to > the masses and implant a root certificate. > > In both cases I am skeptical of the value of CR. I am also skeptical > that all consumers would repair their systems even with a flood of > strongly worded advertising. So, :), I believe a compromised or > spoofed (bogus embeded root certificate) root is the kind of gift that > keeps on giving. From owner-ietf-pkix@imc.org Mon Aug 14 21:23:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21636 for ; Mon, 14 Aug 2000 21:23:20 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA02323; Mon, 14 Aug 2000 18:23:16 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Aug 2000 18:23:14 -0700 Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA02288 for ; Mon, 14 Aug 2000 18:23:13 -0700 (PDT) Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000815012256.IFNR4590.mail.rdc1.md.home.com@home.com>; Mon, 14 Aug 2000 18:22:56 -0700 Message-ID: <39989B4F.A0FF0C63@home.com> Date: Mon, 14 Aug 2000 21:22:23 -0400 From: Al Arsenault Organization: @Home Network X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Jueneman CC: juancarlos.perez@acepta.com, ietf-pkix@imc.org, anders.rundgren@telia.com Subject: Re: Client-side revocation checking capability References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Bob, et alia: The scenario against which CRL-checking-for-server-certs-in-SSL-sessions protects is: - the key for Popular_fictional_site.com is compromised, and whoever has it sets up a duplicate site, with appropriate DNS spoofs to direct traffic to the duplicate site - the legitimate owners of Popular_fictional_site.com realize that the compromise has occurred, report it, and get a new cert. - now, along comes Jean User, connecting to Popular_fictional_site.com. Quick: is this the real site, or the spoof? Both have certs and matching private keys that trace back to the same trusted root. If the client checks the CRL, (s)he will detect that they cert/key offered by the spoof site is revoked, while the cert/key offered by the legitimate site will be okay. Okay, now, how realistic is that threat? Is that the one against which you're defending? Who knows? But it is one of the threats against which the revocation mechanism was designed to work. Al Arsenault Chief Security Architect Diversinet Corp. Bob Jueneman wrote: > > Anders, > > There is a lot of practical truth in what you say. > > CRL checking certainly seems like a nice thing to do cryptographically, until you consider what the threat is that you are trying to address. > > Let's suppose amazon.com's key were compromised somehow. What would happen? Well, the first thing is that they would call up their CA and get a new certificate, and then download that certificate to any SSL user. So the old certificate and key would be completely out of the picture, and hence no CRL would be needed, much less OCSP. since they don't use that certificate to sign anything other than SSL sessions, which in which the certificates are sent in line, they don't even need to revoke their old certs -- just stop using them. > > The only case where a CRL might be useful in that scenario would be in the case of some fly-by-night mafia.com type of store-front, where the CA might conceivably revoke the certificate for fraud or other cause. However, that would represent a substantial legal liability for the CA, and so that doesn't seem terribly likely in practice. > > Since the retail merchant accounts for the overwhelming use of PKI to date (e-mail is just barely beginning to make a dent, and everything else are just pilots, it isn't surprising that the browsers don't enable CRL checking by default. It would merely add lots of delay and processing time. > > Bob > > >>> "Anders Rundgren" 08/12/00 12:02AM >>> > Juan Carlos, > > That on-line checking of server-certificates is not standard in browsers is probably > beacuse a revocation is not that likely to happen. In case of a key compromize at the VeriSign > CA the whole world will be notified and in the case of key compromize in a web-server no > one will know or be notified. You can steal a web-cert+key from a lousy installation (most are) > in case you have sys-admin rights. Nothing to do about except tighten up internal security. > And if the host-name is no longer valid (the company filed for bancruptsy) the > server will be taken down some day. > > IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where > you may revoke yourself due to loss (of card) or by the company because you got fired. > > This is a slightly different answer than you get by asking a typical crypto expert but to my > knowledge they usually know zilch, nada etc. about practical things that may be 100 times more > important than the cryptologic solurtion. I.e. as long as there are serious practical problems > associated with server-certificates, CRLs etc. would basically add nothing (but delays). > > Regards > Anders From owner-ietf-pkix@imc.org Tue Aug 15 00:10:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25039 for ; Tue, 15 Aug 2000 00:10:35 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA17590; Mon, 14 Aug 2000 21:10:30 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Aug 2000 21:10:10 -0700 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA17524 for ; Mon, 14 Aug 2000 21:10:09 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 14 Aug 2000 22:09:19 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 14 Aug 2000 22:09:09 -0600 From: "Bob Jueneman" To: Cc: , , Subject: Re: Client-side revocation checking capability Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id VAA17525 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Al, I don't disagree with you, but then I don't distribute the popular browsers or control what their defaults are, either. All that I was trying to say was that there are, substantive reasons to believe that the CRL "cure" may be worse than the disease, at least with respect to the current use of PKI consumer e-commerce sites. that's not to say that other applications may not have different trade-offs and criteria. Without making too big a deal of the whole issue, I think it is important to realize that the goal of PKI is to reduce risk to an affordable level, NOT necessarily to try to reduce that risk to absolute zero, regardless of cost. Bob >>> Al Arsenault 08/14/00 07:22PM >>> Bob, et alia: The scenario against which CRL-checking-for-server-certs-in-SSL-sessions protects is: - the key for Popular_fictional_site.com is compromised, and whoever has it sets up a duplicate site, with appropriate DNS spoofs to direct traffic to the duplicate site - the legitimate owners of Popular_fictional_site.com realize that the compromise has occurred, report it, and get a new cert. - now, along comes Jean User, connecting to Popular_fictional_site.com. Quick: is this the real site, or the spoof? Both have certs and matching private keys that trace back to the same trusted root. If the client checks the CRL, (s)he will detect that they cert/key offered by the spoof site is revoked, while the cert/key offered by the legitimate site will be okay. Okay, now, how realistic is that threat? Is that the one against which you're defending? Who knows? But it is one of the threats against which the revocation mechanism was designed to work. Al Arsenault Chief Security Architect Diversinet Corp. Bob Jueneman wrote: > > Anders, > > There is a lot of practical truth in what you say. > > CRL checking certainly seems like a nice thing to do cryptographically, until you consider what the threat is that you are trying to address. > > Let's suppose amazon.com's key were compromised somehow. What would happen? Well, the first thing is that they would call up their CA and get a new certificate, and then download that certificate to any SSL user. So the old certificate and key would be completely out of the picture, and hence no CRL would be needed, much less OCSP. since they don't use that certificate to sign anything other than SSL sessions, which in which the certificates are sent in line, they don't even need to revoke their old certs -- just stop using them. > > The only case where a CRL might be useful in that scenario would be in the case of some fly-by-night mafia.com type of store-front, where the CA might conceivably revoke the certificate for fraud or other cause. However, that would represent a substantial legal liability for the CA, and so that doesn't seem terribly likely in practice. > > Since the retail merchant accounts for the overwhelming use of PKI to date (e-mail is just barely beginning to make a dent, and everything else are just pilots, it isn't surprising that the browsers don't enable CRL checking by default. It would merely add lots of delay and processing time. > > Bob > > >>> "Anders Rundgren" 08/12/00 12:02AM >>> > Juan Carlos, > > That on-line checking of server-certificates is not standard in browsers is probably > beacuse a revocation is not that likely to happen. In case of a key compromize at the VeriSign > CA the whole world will be notified and in the case of key compromize in a web-server no > one will know or be notified. You can steal a web-cert+key from a lousy installation (most are) > in case you have sys-admin rights. Nothing to do about except tighten up internal security. > And if the host-name is no longer valid (the company filed for bancruptsy) the > server will be taken down some day. > > IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where > you may revoke yourself due to loss (of card) or by the company because you got fired. > > This is a slightly different answer than you get by asking a typical crypto expert but to my > knowledge they usually know zilch, nada etc. about practical things that may be 100 times more > important than the cryptologic solurtion. I.e. as long as there are serious practical problems > associated with server-certificates, CRLs etc. would basically add nothing (but delays). > > Regards > Anders From owner-ietf-pkix@imc.org Tue Aug 15 08:02:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12023 for ; Tue, 15 Aug 2000 08:02:33 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA18375; Tue, 15 Aug 2000 05:01:36 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 15 Aug 2000 05:00:33 -0700 Received: from gatekeeper.itsec-debis.de (gatekeeper.itsec-debis.de [195.227.50.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA18217 for ; Tue, 15 Aug 2000 05:00:31 -0700 (PDT) Received: from gatekeeper (gatekeeper [192.168.2.1] (may be forged)) by gatekeeper.itsec-debis.de (8.8.8+Sun/8.8.8) with SMTP id NAA07086 for ; Tue, 15 Aug 2000 13:57:36 +0200 (MET DST) Received: by itsec-debis.de id OAA28543; Tue, 15 Aug 2000 14:29:01 +0200 Message-ID: <39993045.276B1EF9@debis.com> Date: Tue, 15 Aug 2000 13:57:57 +0200 From: Jochen Gottsmann Organization: debis Systemhaus Information Security Services GmbH X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: unsubscribe Content-Type: multipart/mixed; boundary="------------2C2C6C2F1C1F0F9D7FBF0EB6" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. --------------2C2C6C2F1C1F0F9D7FBF0EB6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------2C2C6C2F1C1F0F9D7FBF0EB6 Content-Type: text/x-vcard; charset=us-ascii; name="j.gottsmann.vcf" Content-Description: Card for Jochen Gottsmann Content-Disposition: attachment; filename="j.gottsmann.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Gottsmann;Jochen tel;fax:+49 6196 961 451 tel;work:+49 6196 961 380 x-mozilla-html:FALSE org:debis Information Security Services GmbH version:2.1 email;internet:j.gottsmann@debis.com title:Diplom-Mathematiker adr;quoted-printable:;;Mergenthalerallee 38-40=0D=0A=0D=0A;65760 Eschborn;;; fn:Jochen Gottsmann end:vcard --------------2C2C6C2F1C1F0F9D7FBF0EB6-- From owner-ietf-pkix@imc.org Tue Aug 15 15:02:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22113 for ; Tue, 15 Aug 2000 15:02:40 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA11191; Tue, 15 Aug 2000 12:02:27 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 15 Aug 2000 12:02:17 -0700 Received: from avocet.prod.itd.earthlink.net (avocet.prod.itd.earthlink.net [207.217.121.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11161 for ; Tue, 15 Aug 2000 12:02:17 -0700 (PDT) Received: from [38.29.130.217] (ip217.phoenix16.az.pub-ip.psi.net [38.29.130.217]) by avocet.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id MAA02624; Tue, 15 Aug 2000 12:01:05 -0700 (PDT) Mime-Version: 1.0 X-Sender: hoytkesterson@mail.earthlink.net Message-Id: Date: Tue, 15 Aug 2000 11:59:49 -0700 To: OSI Directory List , ietf-pkix@imc.org, pki-twg@nist.gov From: "Hoyt L. Kesterson II" Subject: a new revision of the draft 4th edition of X.509 is on the server Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe hello all we have been receiving comments on the x509 text (thank you all) and have been making corrections. a new revision of the draft 4th edition of x509 is on the directory server in both pdf and office 98 formats. the urls are: ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV5.pdf ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV5.doc this revision (v5) contains: 1) an correction to an asn.1 abstract data type name In the ASN.1 in Clause 11.2.9, replaced "PolicyID ::= CertPolicyID" with: "PolicyID ::= CertPolicyId" This same correction made in Annex A in the AuthenticationFramework module, on page 97 (about 2/3 of the way down the page) 2) a corrected text cross reference In clause 8.2.2.6, 2nd sentence, the reference "as described in 12.4.3", is replaced with "as described in 10". 3) corrections to handle the inhibitAnyPolicy extension Clause 10.1 Path processing inputs: - added item f) to list of inputs to the certification path processing - renumbered old f) to g) and - added f) to the paragraph following list list. Clause 10.3 Path processing variables - added item g) to the list of variables used by the procedure - renumbered old item f) to g) - revised the text of item h) Clause 10.4 Initialization step - revised item h) to reflect the 3 rather than 2 settings Clause 10.5 Certificate processing - Under "The following checks are applied to a certificate": - replaced old steps d) e) and f) with revised steps d), e) and f) - Under "For an intermediate certificate, ..." - added item f) to the list of checks - renumbered old item f) to g) - Under "For all certificates ..." - added a new 2nd bullet to the list - revised the second last paragraph of the clause and delete the last paragraph (redundant). From owner-ietf-pkix@imc.org Tue Aug 15 18:25:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28995 for ; Tue, 15 Aug 2000 18:25:40 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA16215; Tue, 15 Aug 2000 15:25:23 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 15 Aug 2000 15:25:12 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16176 for ; Tue, 15 Aug 2000 15:25:11 -0700 (PDT) Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA28463; Tue, 15 Aug 2000 18:24:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <8525693B.0068C56E.00@lnsunr02.firstdata.com> References: <8525693B.0068C56E.00@lnsunr02.firstdata.com> Date: Tue, 15 Aug 2000 16:30:47 -0400 To: Lynn.Wheeler@firstdata.com From: Stephen Kent Subject: Re: Client-side revocation checking capability Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Lynn, I agree that a PKI based on the DNS would be a great benefit to the Internet. Now that VeriSIgn has bought NSI, the likelihood of creating such a PKI seems remote, as it would create a decentralized PKI that would challenge the VeriSign TTP model. DNSSEC makes use of non-certificate constructs (for understandable reasons having to do with DNS security details), that are not really a good substitute for real certs. Of course, you're a strong believer in no certs at all, so I'm not surprised that you would find DNSSEC a suitable alternative all by itself :-). Steve From owner-ietf-pkix@imc.org Tue Aug 15 19:33:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00337 for ; Tue, 15 Aug 2000 19:33:44 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA18217; Tue, 15 Aug 2000 16:33:35 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 15 Aug 2000 16:33:25 -0700 Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18180 for ; Tue, 15 Aug 2000 16:33:25 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id QAA23947; Tue, 15 Aug 2000 16:33:09 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Tue, 15 Aug 2000 16:31:40 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4F93746@vhqpostal.verisign.com> From: Warwick Ford To: Stephen Kent , Lynn.Wheeler@firstdata.com Cc: ietf-pkix@imc.org Subject: RE: Client-side revocation checking capability Date: Tue, 15 Aug 2000 16:31:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Steve: Seeing our corporate name used in vain here, I feel the need to correct a misconception of the VeriSign business model that you are promulgating. VeriSign provides different types of PKI solutions in different environments. One model is the "TTP" model, which we feel has served the community well for some purposes, such as public SSL server authentication. However, we also operate extensive enterprise and service provider PKI businesses, in which we enable other organizations to be their own CAs or even to allow their customers to be their own CAs, through selective outsourcing of particular PKI functions or through service-provider technology platforms. The concept of a "decentralized PKI" based on DNS is in not fundamentally alien to our business strategy. Warwick > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Tuesday, August 15, 2000 1:31 PM > To: Lynn.Wheeler@firstdata.com > Cc: ietf-pkix@imc.org > Subject: Re: Client-side revocation checking capability > > > Lynn, > > I agree that a PKI based on the DNS would be a great benefit to the > Internet. Now that VeriSIgn has bought NSI, the likelihood of > creating such a PKI seems remote, as it would create a decentralized > PKI that would challenge the VeriSign TTP model. > > DNSSEC makes use of non-certificate constructs (for understandable > reasons having to do with DNS security details), that are not really > a good substitute for real certs. Of course, you're a strong > believer in no certs at all, so I'm not surprised that you would find > DNSSEC a suitable alternative all by itself :-). > > Steve > From owner-ietf-pkix@imc.org Tue Aug 15 20:45:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01604 for ; Tue, 15 Aug 2000 20:45:10 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA20081; Tue, 15 Aug 2000 17:44:52 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 15 Aug 2000 17:44:46 -0700 Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA20049 for ; Tue, 15 Aug 2000 17:44:45 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Tue, 15 Aug 2000 17:34:53 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE235E387@seine.valicert.com> From: Peter Williams To: "'Bob Jueneman'" Cc: ietf-pkix@imc.org Subject: RE: Client-side revocation checking capability Date: Tue, 15 Aug 2000 17:34:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Bob, How does the GroupWise client handle revocation and trust points? Is the root of trust the Novell directory? -----Original Message----- From: Bob Jueneman [mailto:BJUENEMAN@novell.com] Sent: Monday, August 14, 2000 9:09 PM To: awa1@home.com Cc: juancarlos.perez@acepta.com; ietf-pkix@imc.org; anders.rundgren@telia.com Subject: Re: Client-side revocation checking capability Al, I don't disagree with you, but then I don't distribute the popular browsers or control what their defaults are, either. All that I was trying to say was that there are, substantive reasons to believe that the CRL "cure" may be worse than the disease, at least with respect to the current use of PKI consumer e-commerce sites. that's not to say that other applications may not have different trade-offs and criteria. Without making too big a deal of the whole issue, I think it is important to realize that the goal of PKI is to reduce risk to an affordable level, NOT necessarily to try to reduce that risk to absolute zero, regardless of cost. Bob >>> Al Arsenault 08/14/00 07:22PM >>> Bob, et alia: The scenario against which CRL-checking-for-server-certs-in-SSL-sessions protects is: - the key for Popular_fictional_site.com is compromised, and whoever has it sets up a duplicate site, with appropriate DNS spoofs to direct traffic to the duplicate site - the legitimate owners of Popular_fictional_site.com realize that the compromise has occurred, report it, and get a new cert. - now, along comes Jean User, connecting to Popular_fictional_site.com. Quick: is this the real site, or the spoof? Both have certs and matching private keys that trace back to the same trusted root. If the client checks the CRL, (s)he will detect that they cert/key offered by the spoof site is revoked, while the cert/key offered by the legitimate site will be okay. Okay, now, how realistic is that threat? Is that the one against which you're defending? Who knows? But it is one of the threats against which the revocation mechanism was designed to work. Al Arsenault Chief Security Architect Diversinet Corp. Bob Jueneman wrote: > > Anders, > > There is a lot of practical truth in what you say. > > CRL checking certainly seems like a nice thing to do cryptographically, until you consider what the threat is that you are trying to address. > > Let's suppose amazon.com's key were compromised somehow. What would happen? Well, the first thing is that they would call up their CA and get a new certificate, and then download that certificate to any SSL user. So the old certificate and key would be completely out of the picture, and hence no CRL would be needed, much less OCSP. since they don't use that certificate to sign anything other than SSL sessions, which in which the certificates are sent in line, they don't even need to revoke their old certs -- just stop using them. > > The only case where a CRL might be useful in that scenario would be in the case of some fly-by-night mafia.com type of store-front, where the CA might conceivably revoke the certificate for fraud or other cause. However, that would represent a substantial legal liability for the CA, and so that doesn't seem terribly likely in practice. > > Since the retail merchant accounts for the overwhelming use of PKI to date (e-mail is just barely beginning to make a dent, and everything else are just pilots, it isn't surprising that the browsers don't enable CRL checking by default. It would merely add lots of delay and processing time. > > Bob > > >>> "Anders Rundgren" 08/12/00 12:02AM >>> > Juan Carlos, > > That on-line checking of server-certificates is not standard in browsers is probably > beacuse a revocation is not that likely to happen. In case of a key compromize at the VeriSign > CA the whole world will be notified and in the case of key compromize in a web-server no > one will know or be notified. You can steal a web-cert+key from a lousy installation (most are) > in case you have sys-admin rights. Nothing to do about except tighten up internal security. > And if the host-name is no longer valid (the company filed for bancruptsy) the > server will be taken down some day. > > IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where > you may revoke yourself due to loss (of card) or by the company because you got fired. > > This is a slightly different answer than you get by asking a typical crypto expert but to my > knowledge they usually know zilch, nada etc. about practical things that may be 100 times more > important than the cryptologic solurtion. I.e. as long as there are serious practical problems > associated with server-certificates, CRLs etc. would basically add nothing (but delays). > > Regards > Anders From owner-ietf-pkix@imc.org Wed Aug 16 09:09:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24006 for ; Wed, 16 Aug 2000 09:09:48 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA17932; Wed, 16 Aug 2000 06:08:31 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 16 Aug 2000 06:07:16 -0700 Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA17747 for ; Wed, 16 Aug 2000 06:07:15 -0700 (PDT) Received: from kant [129.27.152.76] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A1E36C500A8; Wed, 16 Aug 2000 15:06:43 +0200 Message-ID: <00e501c00782$d312c720$4c981b81@iaik.tugraz.ac.at> From: "Christian Vogel" To: Subject: TSP implementation IP address change Date: Wed, 16 Aug 2000 15:06:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA17751 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit The IP address has changed to: 129.27.142.227:318 Regards Christian Vogel -- Christian Vogel office: [cvogel@iaik.at] [http://jcewww.iaik.tu-graz.ac.at] private: [bird@sbox.tu-graz.ac.at] [http://www.sbox.tu-graz.ac.at/home/b/bird] From owner-ietf-pkix@imc.org Wed Aug 16 13:15:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00440 for ; Wed, 16 Aug 2000 13:15:41 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA08290; Wed, 16 Aug 2000 10:15:22 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 16 Aug 2000 10:15:13 -0700 Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08257 for ; Wed, 16 Aug 2000 10:15:12 -0700 (PDT) From: Lynn.Wheeler@firstdata.com Received: from mailgw.firstdata.com ([204.48.27.156]) by mail-ewr-3.pilot.net with ESMTP id NAA21099; Wed, 16 Aug 2000 13:15:03 -0400 (EDT) Received: from lnsunr02.firstdata.com (localhost [127.0.0.1]) by mailgw.firstdata.com with SMTP id NAA26643; Wed, 16 Aug 2000 13:15:02 -0400 (EDT) Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525693D.005E4131 ; Wed, 16 Aug 2000 13:09:30 -0400 X-Lotus-FromDomain: FDC To: Stephen Kent cc: ietf-pkix@imc.org Message-ID: <8525693D.005E4021.00@lnsunr02.firstdata.com> Date: Wed, 16 Aug 2000 10:13:33 -0700 Subject: Re: Client-side revocation checking capability Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe actually I believe in CERTS containing some amount of "account" data that can be used in offline environments when access to the account record is not available. In that sense, for business applications that are account record oriented, CERTS can provide a stale (possibly subset) of what might appear in the business account record. however, in an online model where a transaction or message has to "hit" the account record in any case, it is possible to obtain the public key from the "master" in the account record ... w/o having to bother with an account record substitute represented by a CERT (i.e. a certification authority has a master account record someplace with most/all information that went into a CERT ... along with audit trails and other business requirements that are ordinary part of business account transaction). In the DNS case, lack of trusted DNS is even a problem for certification authorities issueing SSL certificates ... since the domain name "authority" that the certificationa authority has to reference to validate the information to put in a CERT ... is the same untrusted DNS infrastructure (as some of the comments about domain name hijacking represents). Part of the solution for created a trusting domain name "authority" operation is to add public keys and digital signature authentication to DNS operation. That would even closes integrity "holes" that SSL certificates have because the authority for the domain information that goes into the SSL certificates can now be trusted. My observation is just that with the addition of public keys to domain name infrastructure ... then the DNS operation not only "hits" an online account record ... but also one that may include the trusted public key (part of making the entry trusted and harder to hijack). DNS already supports returning all sorts of information in addition to host names to ip address mapping ... so the ability of returning such public keys as part of a trusted DNS operation is straight forward. At this point, all DNS operations now could provide both trusted address mapping and public key binding as part of each online operation. Such a facility would then make the majority of existing server-side SSL certificates superfulous and redundant. The side observation is there is a requirement for such a trusted DNS infrastructure ... just to improve the integrity of existing server-side SSL certificates (i.e. problem with hijacking host name and then obtaining a SSL certificate since the certification authority has to resort to using the DNS infrastructure as the authoritative entity for validating DNS information). But addressing that requirement then also makes the need for such servier-side SSL certificates superfulous and redundant. Stephen Kent on 08/15/2000 01:30:47 PM To: Lynn Wheeler@firstdata.com cc: ietf-pkix@imc.org Subject: Re: Client-side revocation checking capability Lynn, I agree that a PKI based on the DNS would be a great benefit to the Internet. Now that VeriSIgn has bought NSI, the likelihood of creating such a PKI seems remote, as it would create a decentralized PKI that would challenge the VeriSign TTP model. DNSSEC makes use of non-certificate constructs (for understandable reasons having to do with DNS security details), that are not really a good substitute for real certs. Of course, you're a strong believer in no certs at all, so I'm not surprised that you would find DNSSEC a suitable alternative all by itself :-). Steve From owner-ietf-pkix@imc.org Wed Aug 16 14:07:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01300 for ; Wed, 16 Aug 2000 14:07:07 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA10370; Wed, 16 Aug 2000 11:06:46 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 16 Aug 2000 11:06:43 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA10340 for ; Wed, 16 Aug 2000 11:06:42 -0700 (PDT) Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA27278; Wed, 16 Aug 2000 14:06:00 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4F93746@vhqpostal.verisign.com> References: <2F3EC696EAEED311BB2D009027C3F4F4F93746@vhqpostal.verisign.com> Date: Wed, 16 Aug 2000 13:59:31 -0400 To: Warwick Ford From: Stephen Kent Subject: RE: Client-side revocation checking capability Cc: Lynn.Wheeler@firstdata.com, ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Warwick, >Steve: > >Seeing our corporate name used in vain here, I feel the need to correct a >misconception of the VeriSign business model that you are promulgating. > >VeriSign provides different types of PKI solutions in different >environments. One model is the "TTP" model, which we feel has served the >community well for some purposes, such as public SSL server authentication. >However, we also operate extensive enterprise and service provider PKI >businesses, in which we enable other organizations to be their own CAs or >even to allow their customers to be their own CAs, through selective >outsourcing of particular PKI functions or through service-provider >technology platforms. > >The concept of a "decentralized PKI" based on DNS is in not fundamentally >alien to our business strategy. > >Warwick > We agree that VeriSign supports several different PKI models. However, VeriSign, through its marketing arm, promotes the TTP model most aggressively, almost to the point of ignoring other PKI models that you support. For example, last week the dirtector of operations for veriSig was invited to address the Defense Science Board Information Assurance panel, in CA. His briefing began with some marketing slides (for which he apologized). The PKI portion of those slides (the rest emphasized the scope of the NSI DNS business) were almost exclusively devoted to the TTP business, especially the web server aspect. In fact, I had to raise the fact that VeriSIgn offered programs such as VeriSign Onsite to bring out the other aspects of the business. So, while we agree that, from a technical perspective that VeriSign does offer more than just TTP services, the public perception, which has been cultivated by VeriSign, focuses almost exclusively on the TTP model. Steve From owner-ietf-pkix@imc.org Wed Aug 16 14:10:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01359 for ; Wed, 16 Aug 2000 14:10:52 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA10777; Wed, 16 Aug 2000 11:10:11 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 16 Aug 2000 11:10:09 -0700 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA10745 for ; Wed, 16 Aug 2000 11:10:08 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 16 Aug 2000 12:09:27 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 16 Aug 2000 12:09:24 -0600 From: "Bob Jueneman" To: Cc: Subject: RE: Client-side revocation checking capability Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA10746 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Peter, The current GroupWise S/MIME functionality is built upon the capabilities provided by IE5 and MS-CAPI, unlike other Novell applications which use our NICI crypto and are more tightly integrated with NDS. The currently shipping version of GroupWise does not support CRLs, although I believe that functionality will be included in the forthcoming release, later this year. Because of the more or less common infrastructure, plug-ins for other revocation/validation models, e.g., ValiCert's, should be straight-forward, assuming there is sufficient user demand. Since GroupWise shares the same underpinnings as IE5, we have both some of the same benefits and same problems as the existing browsers. In particular, looking forward a couple of years, I can foresee a chaotic situation where every organization on the planet want to have their own "root" CA, and the browsers and e-mail clients simply collapse under the weight of the trust administration. The single PEM-type of hierarchical structure obviously isn't going to work, but an unconstrained explosion of trusted roots isn't going to work either. Some commercial CA's will fail to gain sufficient acceptance, and others will just be ignored. If the existing TTPs are not willing to enable the use of subordinate CAs (some are and some aren't, for obvious business reasons), then an opportunity will arise for others to take on this responsibility. one way or the other, though, some coalescing of CAs is going have to take place before very long. From my point of view, the existing PKI and validation structure has been perhaps excessively focused on the role of the subscriber and the CA and the identity function, and not enough attention has been payed to the management of the basic, underlying TRUST relationship by the relying party. For that reason, we are looking carefully at the use of the directory to provide local mediation and enterprise control over the trust relationships at the relying party end. Case in point, lets say that a hospital decides to revoke a Doctor's staff privileges, perhaps because a few too many of his patients have been dying. Not only do they not want him in the operating room, they don't want him reviewing patient records, issuing prescriptions or medical orders, etc. Most of those issues only involve access control, not nonrepudiation. Now, does the hospital care what say VeriSign thinks of that Doctor's credentials, or even the State of Utah? Clearly not. So CRL checking isn't the answer for managing _trust_, because the issue isn't identity, and it isn't key compromise either. An attribute certificate issued by the hospital, as opposed to an identity broker, might be the solution, but frankly just getting identity certs deployed and working has been a sufficient challenge. And it is really hard to imagine every hospital, pharmacy, HMO, etc., issuing their own individual attribute cert to every doctor, complete with their own revocation structure. This might be necessary if nonrepudiation were really an issue, but in most of these cases it probably isn't. In that case, a local directory can be used as the relying party's Delphic oracle with respect to privilege, and it may also be used to cache certificates and CRLs to minimize the computational load and bandwidth requirements. Where CRL checking does have a role to play in this environment, I believe, is in the case of extranet access control., In this case Enterprise A may issue identity certificates to one of their employees, perhaps using the Novell Security Attributes to confirm that Dr. Doakes is a doctor. Enterprise B, assuming they have a relationship with Enterprise A, may accept Dr. Doakes certificate as sufficient evidence of his credentials and allow him access to certain files, based only on his certificate and Enterprise A's say so (while of course auditing his actions based on the name in his certificate). In that type of scenario, Enterprise B would be relying on Enterprise A to revoke Dr. Doakes certificate if he is no longer working for them. But that revocation could take the form of a CRL, or alternately a directory status update. Each enterprise probably doesn't want to take on the management burden of managing the entries in the directory for all of the employees in the other enterprise, but they might be willing to accept the burden on an exception basis. Bob >>> Peter Williams 08/15/00 06:34PM >>> Bob, How does the GroupWise client handle revocation and trust points? Is the root of trust the Novell directory? -----Original Message----- From: Bob Jueneman [mailto:BJUENEMAN@novell.com] Sent: Monday, August 14, 2000 9:09 PM To: awa1@home.com Cc: juancarlos.perez@acepta.com; ietf-pkix@imc.org; anders.rundgren@telia.com Subject: Re: Client-side revocation checking capability Al, I don't disagree with you, but then I don't distribute the popular browsers or control what their defaults are, either. All that I was trying to say was that there are, substantive reasons to believe that the CRL "cure" may be worse than the disease, at least with respect to the current use of PKI consumer e-commerce sites. that's not to say that other applications may not have different trade-offs and criteria. Without making too big a deal of the whole issue, I think it is important to realize that the goal of PKI is to reduce risk to an affordable level, NOT necessarily to try to reduce that risk to absolute zero, regardless of cost. Bob >>> Al Arsenault 08/14/00 07:22PM >>> Bob, et alia: The scenario against which CRL-checking-for-server-certs-in-SSL-sessions protects is: - the key for Popular_fictional_site.com is compromised, and whoever has it sets up a duplicate site, with appropriate DNS spoofs to direct traffic to the duplicate site - the legitimate owners of Popular_fictional_site.com realize that the compromise has occurred, report it, and get a new cert. - now, along comes Jean User, connecting to Popular_fictional_site.com. Quick: is this the real site, or the spoof? Both have certs and matching private keys that trace back to the same trusted root. If the client checks the CRL, (s)he will detect that they cert/key offered by the spoof site is revoked, while the cert/key offered by the legitimate site will be okay. Okay, now, how realistic is that threat? Is that the one against which you're defending? Who knows? But it is one of the threats against which the revocation mechanism was designed to work. Al Arsenault Chief Security Architect Diversinet Corp. Bob Jueneman wrote: > > Anders, > > There is a lot of practical truth in what you say. > > CRL checking certainly seems like a nice thing to do cryptographically, until you consider what the threat is that you are trying to address. > > Let's suppose amazon.com's key were compromised somehow. What would happen? Well, the first thing is that they would call up their CA and get a new certificate, and then download that certificate to any SSL user. So the old certificate and key would be completely out of the picture, and hence no CRL would be needed, much less OCSP. since they don't use that certificate to sign anything other than SSL sessions, which in which the certificates are sent in line, they don't even need to revoke their old certs -- just stop using them. > > The only case where a CRL might be useful in that scenario would be in the case of some fly-by-night mafia.com type of store-front, where the CA might conceivably revoke the certificate for fraud or other cause. However, that would represent a substantial legal liability for the CA, and so that doesn't seem terribly likely in practice. > > Since the retail merchant accounts for the overwhelming use of PKI to date (e-mail is just barely beginning to make a dent, and everything else are just pilots, it isn't surprising that the browsers don't enable CRL checking by default. It would merely add lots of delay and processing time. > > Bob > > >>> "Anders Rundgren" 08/12/00 12:02AM >>> > Juan Carlos, > > That on-line checking of server-certificates is not standard in browsers is probably > beacuse a revocation is not that likely to happen. In case of a key compromize at the VeriSign > CA the whole world will be notified and in the case of key compromize in a web-server no > one will know or be notified. You can steal a web-cert+key from a lousy installation (most are) > in case you have sys-admin rights. Nothing to do about except tighten up internal security. > And if the host-name is no longer valid (the company filed for bancruptsy) the > server will be taken down some day. > > IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where > you may revoke yourself due to loss (of card) or by the company because you got fired. > > This is a slightly different answer than you get by asking a typical crypto expert but to my > knowledge they usually know zilch, nada etc. about practical things that may be 100 times more > important than the cryptologic solurtion. I.e. as long as there are serious practical problems > associated with server-certificates, CRLs etc. would basically add nothing (but delays). > > Regards > Anders From owner-ietf-pkix@imc.org Wed Aug 16 15:16:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02568 for ; Wed, 16 Aug 2000 15:16:43 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA13295; Wed, 16 Aug 2000 12:16:15 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 16 Aug 2000 12:16:00 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13256 for ; Wed, 16 Aug 2000 12:15:59 -0700 (PDT) Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA07801 for ; Wed, 16 Aug 2000 15:15:50 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: Date: Wed, 16 Aug 2000 15:12:23 -0400 To: ietf-pkix@imc.org From: Stephen Kent Subject: final minutes Content-Type: multipart/alternative; boundary="============_-1245669045==_ma============" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --============_-1245669045==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Several folks sent messages correcting minor errors in the minutes. I have made the requested changes and will now submit a final version to the IETF Secretariat. Also, I was informed that the minutes from the Adelaide meeting did not make it into the IETF archive. I will attempt to address that problem as well. Finally, I have received slides from the speakers (in a timely fashion) and will be forwarding those as well. Steve ----- PKIX WG Meeting 8/1/00 Edited by Steve Kent (WG co-chair) The PKIX WG met once during the 48th IETF and a total of approximately 180 individuals participated in this meeting. The meeting began with the announcement that Tim Polk of NIST will take over from Warwick Ford as a co-chair of the WG. Warwick received a round of applause from the audience, for his service to the Wg since its inception. Tim began the meeting with a review of the status of all of the WG documents. The following text summarizes the status of the documents: PKIX COMPLETED DOCUMENTS (RFCs) PKIX Cert/CRL Profile (RFC 2459) HTTP/FTP Operations (RFC 2585) LDAP V2 Operational Protocols (RFC 2559) LDAP V2 Schema (RFC 2587) OCSP (RFC 2560) CMP (RFC 2510) CRMF (RFC 2511) CMC (RFC 2797) Diffie-Hellman POP (RFC 2875) Certificate Policy/Practices Guideline (RFC 2527) KEA Algorithms for Profile (RFC 2528) PKIX WORK IN PROGRESS (Internet Drafts) Revised Profile (draft-ietf-pkix-new-part1-02.txt) Algorithms for Profile (draft-ietf-pkix-ipki-pkalgs-00.txt) Qualified Certificates (draft-ietf-pkix-qc-05.txt) Time Stamp (draft-ietf-pkix-time-stamp-09.txt) PKIX Roadmap (draft-ietf-pkix-roadmap-05.txt) Revised CMP (draft-ietf-pkix-rfc2510bis.01) CMP Transports (draft-ietf-pkix-cmp-transport-protocols-01.txt) Operational Protocols - LDAPv3 (draft-ietf-pkix-ldap-v3-02.txt) Additional LDAP Schema (draft-ietf-pkix-ldap-schema-00.txt) Attribute Certificate Profile for Authorization (draft-ietf-pkix-ac509prof-04.txt) Limited Attribute Cert Acquisition Prot (draft-ietf-pkix-laap-01.txt) DCS (draft-ietf-pkix-dcs-05.txt) Simple Certificate Validation Protocol (SCVP) (draft-ietf-pkix-scvp-03.txt) Permanent Identifier (draft-ietf-pkix-pi-00.txt) Repository Locator Service (draft-ietf-pkix-pkixrep-00.txt) Tech. Rqmts. For Non-Repudiation (draft-ietf-pkix-technr-01.txt) ACTIVE PROJECTS: LDAP v3 Profile (D. Chadwick-U. of Salford) Split profile into two pieces: protocol vs. schema. The protocol parts should be completed in the next 6-8 weeks and be ready for WG last call. (Suggestion that the LDAP WG also be included in this last call.) The schema work will take longer, as it is a new topic. A major change for the schema is to allow searching on certificate fields, rather than searching on the directory attributes extracted from the certificate. For now, plan to keep the schema work related to certificates in PKIX, not in an LDAP WG, with David acting as principal liaison between the two groups. RFC 2459 evolution (T. Polk-NIST) 2459 has been split into algorithm profiles vs. certificate & CRL syntax and processing. This allows the algorithms document to be revised as algorithms change, without affecting the syntax and processing standard. There is little new material here, mostly clarifications, editorial revisions, etc. We will hold a straw poll on the list on naming mandatory algorithms, e.g., RSA and SHA-1. With the end of the RSA patent period, many other security WGs are taking similar steps. Also, if the WG decides to identify mandatory algorithms, we need to decide whether they are specified in the certificate and CRL processing document, or in the algorithms document. (See slides for more details.) We should be able to go to WG last call very soon on these documents. Qualified Certificates (S. Santesson-AddTrust) Discussions at this IETF meeting have resolved the few remaining points of contention with regard to this draft. Minor changes in wording will result in a new draft by the end of this week and this draft will be forwarded to the security area directors to proceed with the IESG last call. Permanent Identifiers (D, Pinkas-Bull) To be used only in certificates issued to individuals. Designed to track real world identity in the face of name changes, e.g., marriage or job changes within an organization. The ID is expressed as a new name type, with two components; an assigner authority and a name. The first component may be omitted, in which case the certificate Issuer is presumed to be the assigner authority. Note that a registered ID (from general name form) has the necessary property that it is globally unique, and permanent (although not directly meaningful). Thus, depending on which general name form is employed, one can compare names either within a CA domain, or globally, across all CAs. Plan for now is to proceed with it as a separate standards track document, not merged with the QC or son-of-RFC-2459 documents. (See slides for more details.) Time Stamping Protocol (D. Pinkas-Bull) Now on version 9. Several changes made after last call completed. Changes include definition of the serial number consistent with 2459 (can even be a hash of up to 160 bits!), change to SIA from AIA, etc. A number of minor wording changes were made, but the restriction on exclusive use of the TSA private key for signing responses has been preserved. Ready for forwarding to the IESG. Preface to OCSPX and SCVP discussions: As proposed at the Adelaide meeting, a small group was formed and generated a requirements document to characterize the motivations for remote validation services, to define the requirements for such services. The group did not compare the candidate protocols relative to these requirements. OCSP Extensions (M. Myers-VeriSign) Previous ID has expired, expunged from IETF web site. Mike argues that OCSP is the right choice for remote path processing (RPP), via the addition of extensions. Proposal is to revise RFC 2560, to fix minor problems, clarify OCPS role as a framework for remote validation services. Then, create separate documents to define extensions for remote path validation, remote path discovery, etc. So, there would not be an OCSPX document, but rather definitions for syntax and processing for standard extensions. (See slides for more details.) D. Pinkas provided some slides addressing the parameters of remote path processing, e.g., how the requestor constrains the path processing or path construction operation. So, the format needs to be able to indicate whether the requestor wants CRLs or OCSP responses, what security policy to use in evaluating a certificate path, other constraints, etc. Denis argues that the requirements document needs to cover more of these details. However, Paul Hoffman noted that the group was not able to agree to a larger set of "requirements." (See slides for more details.) SCVP (A. Malpani-ValiCert) The speaker reviewed RPP requirements and what OCSP does to support part of the process. Ambarish argues that changes to OCSP to meet these extended requirements may break existing OCSP implementations, and that the code base for OCSP is small, so there is not much to leverage in building an RPP protocol. SCVP will support both ASN.1 and XML, consistent with perceived client requirements to retain data in this format. (See slides for more details.) Attribute Certificates (S. Farrell-Baltimore) Profile has been updated, synchronized with latest X.509 version, and has completed WG last call. It is suggested that this document reference the successor to 2459, which clears up the residual reference issues. CMP (C. Adams-Entrust) CMP RFC is being revised to reflect minor changes. Plan is to wait until completion of interoperability testing (in the PKI forum) to finalize changes to this document, to reflect any further clarifications that arise from this testing. Repository Locator (P. Hallam-Baker-VeriSign) Goal of this document is to specify a means by which one can map an RFC822 name for a user to the LDAP server where the user's certificates are stored. The proposed approach is to use the SRV record in the DNS to provide the necessary pointer. The SRV record is analogous to an MX record, but more general, supporting a list of services and matching addresses. Open questions include the internationalization of DNS (which the DNS WG will address), plus communicating conventions for access protocols (LDAP, HTTP, ...). The base document is a very small work item, because it is merely profiling the existing SRV record. Separate documents will be generated to describe each access protocol convention, e.g., LDAP, OCSP, and HTTP. Need to coordinate with LDAP WG and maybe DNS WGs on their plans for using SRV records for LDAP directory location. (See slides for more details.) CMP Interoperability testing (R. Moskowitz-ICSA) ICSA is working with PKI Forum to coordinate these interoperability tests. Three workshops have been conducted to date, with more scheduled for August and September. Various algorithms, transport protocols, POP mechanisms have been tested. A number vendors have participated. Planned public demo at NISSC in October. Experience shows that variants in CA-side implementations do cause interoperability problems, and further clarifications are needed in RFC 2510 to help resolve ambiguities. CMC interoperability testing may also be pursued in the future. --============_-1245669045==_ma============ Content-Type: text/enriched; charset="us-ascii" Several folks sent messages correcting minor errors in the minutes. I have made the requested changes and will now submit a final version to the IETF Secretariat. Also, I was informed that the minutes from the Adelaide meeting did not make it into the IETF archive. I will attempt to address that problem as well. Finally, I have received slides from the speakers (in a timely fashion) and will be forwarding those as well. Steve ----- Courier_NewPKIX WG Meeting 8/1/00 Edited by Steve Kent (WG co-chair) The PKIX WG met once during the 48th IETF and a total of approximately 180 individuals participated in this meeting. The meeting began with the announcement that Tim Polk of NIST will take over from Warwick Ford as a co-chair of the WG. Warwick received a round of applause from the audience, for his service to the Wg since its inception. Tim began the meeting with a review of the status of all of the WG documents. The following text summarizes the status of the documents: PKIX COMPLETED DOCUMENTS (RFCs) PKIX Cert/CRL Profile (RFC 2459) HTTP/FTP Operations (RFC 2585) LDAP V2 Operational Protocols (RFC 2559) LDAP V2 Schema (RFC 2587) OCSP (RFC 2560) CMP (RFC 2510) CRMF (RFC 2511) CMC (RFC 2797) Diffie-Hellman POP (RFC 2875) Certificate Policy/Practices Guideline (RFC 2527) KEA Algorithms for Profile (RFC 2528) PKIX WORK IN PROGRESS (Internet Drafts) Revised Profile (draft-ietf-pkix-new-part1-02.txt) Algorithms for Profile (draft-ietf-pkix-ipki-pkalgs-00.txt) Qualified Certificates (draft-ietf-pkix-qc-05.txt) Time Stamp (draft-ietf-pkix-time-stamp-09.txt) PKIX Roadmap (draft-ietf-pkix-roadmap-05.txt) Revised CMP (draft-ietf-pkix-rfc2510bis.01) CMP Transports (draft-ietf-pkix-cmp-transport-protocols-01.txt) Operational Protocols - LDAPv3 (draft-ietf-pkix-ldap-v3-02.txt) Additional LDAP Schema (draft-ietf-pkix-ldap-schema-00.txt) Attribute Certificate Profile for Authorization (draft-ietf-pkix-ac509prof-04.txt) Limited Attribute Cert Acquisition Prot (draft-ietf-pkix-laap-01.txt) DCS (draft-ietf-pkix-dcs-05.txt) Simple Certificate Validation Protocol (SCVP) (draft-ietf-pkix-scvp-03.txt) Permanent Identifier (draft-ietf-pkix-pi-00.txt) Repository Locator Service (draft-ietf-pkix-pkixrep-00.txt) Tech. Rqmts. For Non-Repudiation (draft-ietf-pkix-technr-01.txt) ACTIVE PROJECTS: LDAP v3 Profile (D. Chadwick-U. of Salford) Split profile into two pieces: protocol vs. schema. The protocol parts should be completed in the next 6-8 weeks and be ready for WG last call. (Suggestion that the LDAP WG also be included in this last call.) The schema work will take longer, as it is a new topic. A major change for the schema is to allow searching on certificate fields, rather than searching on the directory attributes extracted from the certificate. For now, plan to keep the schema work related to certificates in PKIX, not in an LDAP WG, with David acting as principal liaison between the two groups. RFC 2459 evolution (T. Polk-NIST) 2459 has been split into algorithm profiles vs. certificate & CRL syntax and processing. This allows the algorithms document to be revised as algorithms change, without affecting the syntax and processing standard. There is little new material here, mostly clarifications, editorial revisions, etc. We will hold a straw poll on the list on naming mandatory algorithms, e.g., RSA and SHA-1. With the end of the RSA patent period, many other security WGs are taking similar steps. Also, if the WG decides to identify mandatory algorithms, we need to decide whether they are specified in the certificate and CRL processing document, or in the algorithms document. (See slides for more details.) We should be able to go to WG last call very soon on these documents. Qualified Certificates (S. Santesson-AddTrust) Discussions at this IETF meeting have resolved the few remaining points of contention with regard to this draft. Minor changes in wording will result in a new draft by the end of this week and this draft will be forwarded to the security area directors to proceed with the IESG last call. Permanent Identifiers (D, Pinkas-Bull) To be used only in certificates issued to individuals. Designed to track real world identity in the face of name changes, e.g., marriage or job changes within an organization. The ID is expressed as a new name type, with two components; an assigner authority and a name. The first component may be omitted, in which case the certificate Issuer is presumed to be the assigner authority. Note that a registered ID (from general name form) has the necessary property that it is globally unique, and permanent (although not directly meaningful). Thus, depending on which general name form is employed, one can compare names either within a CA domain, or globally, across all CAs. Plan for now is to proceed with it as a separate standards track document, not merged with the QC or son-of-RFC-2459 documents. (See slides for more details.) Time Stamping Protocol (D. Pinkas-Bull) Now on version 9. Several changes made after last call completed. Changes include definition of the serial number consistent with 2459 (can even be a hash of up to 160 bits!), change to SIA from AIA, etc. A number of minor wording changes were made, but the restriction on exclusive use of the TSA private key for signing responses has been preserved. Ready for forwarding to the IESG. Preface to OCSPX and SCVP discussions: As proposed at the Adelaide meeting, a small group was formed and generated a requirements document to characterize the motivations for remote validation services, to define the requirements for such services. The group did not compare the candidate protocols relative to these requirements. OCSP Extensions (M. Myers-VeriSign) Previous ID has expired, expunged from IETF web site. Mike argues that OCSP is the right choice for remote path processing (RPP), via the addition of extensions. Proposal is to revise RFC 2560, to fix minor problems, clarify OCPS role as a framework for remote validation services. Then, create separate documents to define extensions for remote path validation, remote path discovery, etc. So, there would not be an OCSPX document, but rather definitions for syntax and processing for standard extensions. (See slides for more details.) D. Pinkas provided some slides addressing the parameters of remote path processing, e.g., how the requestor constrains the path processing or path construction operation. So, the format needs to be able to indicate whether the requestor wants CRLs or OCSP responses, what security policy to use in evaluating a certificate path, other constraints, etc. Denis argues that the requirements document needs to cover more of these details. However, Paul Hoffman noted that the group was not able to agree to a larger set of "requirements." (See slides for more details.) SCVP (A. Malpani-ValiCert) The speaker reviewed RPP requirements and what OCSP does to support part of the process. Ambarish argues that changes to OCSP to meet these extended requirements may break existing OCSP implementations, and that the code base for OCSP is small, so there is not much to leverage in building an RPP protocol. SCVP will support both ASN.1 and XML, consistent with perceived client requirements to retain data in this format. (See slides for more details.) Attribute Certificates (S. Farrell-Baltimore) Profile has been updated, synchronized with latest X.509 version, and has completed WG last call. It is suggested that this document reference the successor to 2459, which clears up the residual reference issues. CMP (C. Adams-Entrust) CMP RFC is being revised to reflect minor changes. Plan is to wait until completion of interoperability testing (in the PKI forum) to finalize changes to this document, to reflect any further clarifications that arise from this testing. Repository Locator (P. Hallam-Baker-VeriSign) Goal of this document is to specify a means by which one can map an RFC822 name for a user to the LDAP server where the user's certificates are stored. The proposed approach is to use the SRV record in the DNS to provide the necessary pointer. The SRV record is analogous to an MX record, but more general, supporting a list of services and matching addresses. Open questions include the internationalization of DNS (which the DNS WG will address), plus communicating conventions for access protocols (LDAP, HTTP, ...). The base document is a very small work item, because it is merely profiling the existing SRV record. Separate documents will be generated to describe each access protocol convention, e.g., LDAP, OCSP, and HTTP. Need to coordinate with LDAP WG and maybe DNS WGs on their plans for using SRV records for LDAP directory location. (See slides for more details.) CMP Interoperability testing (R. Moskowitz-ICSA) ICSA is working with PKI Forum to coordinate these interoperability tests. Three workshops have been conducted to date, with more scheduled for August and September. Various algorithms, transport protocols, POP mechanisms have been tested. A number vendors have participated. Planned public demo at NISSC in October. Experience shows that variants in CA-side implementations do cause interoperability problems, and further clarifications are needed in RFC 2510 to help resolve ambiguities. CMC interoperability testing may also be pursued in the future. --============_-1245669045==_ma============-- From owner-ietf-pkix@imc.org Wed Aug 16 19:12:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05047 for ; Wed, 16 Aug 2000 19:12:31 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA16990; Wed, 16 Aug 2000 16:12:13 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 16 Aug 2000 16:12:06 -0700 Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16959 for ; Wed, 16 Aug 2000 16:12:04 -0700 (PDT) Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.11.0/8.11.0) with ESMTP id e7GNA8286205; Wed, 16 Aug 2000 16:10:08 -0700 (PDT) Message-ID: <399B1F50.74CE1A74@software-munitions.com> Date: Wed, 16 Aug 2000 16:10:08 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: Warwick Ford , Lynn.Wheeler@firstdata.com, ietf-pkix@imc.org Subject: Re: Client-side revocation checking capability References: <2F3EC696EAEED311BB2D009027C3F4F4F93746@vhqpostal.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Stephen Kent wrote: > > Warwick, > > >Steve: > > > >Seeing our corporate name used in vain here, I feel the need to correct a > >misconception of the VeriSign business model that you are promulgating. > > > >VeriSign provides different types of PKI solutions in different > >environments. One model is the "TTP" model, which we feel has served the > >community well for some purposes, such as public SSL server authentication. > >However, we also operate extensive enterprise and service provider PKI > >businesses, in which we enable other organizations to be their own CAs or > >even to allow their customers to be their own CAs, through selective > >outsourcing of particular PKI functions or through service-provider > >technology platforms. > > > >The concept of a "decentralized PKI" based on DNS is in not fundamentally > >alien to our business strategy. > > > >Warwick > > > We agree that VeriSign supports several different PKI models. > However, VeriSign, through its marketing arm, promotes the TTP model > most aggressively, almost to the point of ignoring other PKI models > that you support. For example, last week the dirtector of operations > for veriSig was invited to address the Defense Science Board > Information Assurance panel, in CA. His briefing began with some > marketing slides (for which he apologized). The PKI portion of those > slides (the rest emphasized the scope of the NSI DNS business) were > almost exclusively devoted to the TTP business, especially the web > server aspect. In fact, I had to raise the fact that VeriSIgn > offered programs such as VeriSign Onsite to bring out the other > aspects of the business. So, while we agree that, from a technical > perspective that VeriSign does offer more than just TTP services, the > public perception, which has been cultivated by VeriSign, focuses > almost exclusively on the TTP model. > And, if you follow www.verisign.com/repository/RPA/, which is embedded in my Verisign personal certificate as a pointer to their CPS, you will find: * You are responsible for deciding whether the information in the certificate is relevant. * If you are not a Verisign customer (e.g., some dummy connecting to a Verisign certified e-commerce site such as Amazon.COM), and you want to check for revocation, then you must agree to their CSP if you want to use their online services. So much for Section 1, Section 2, which covers CRLs, is equally interesting. However, Section 5 says, as a non-subscriber, that Verisign doesn't warrant certificate merchantability, fitness, or the accuracy of information. Then, of course, you won't hold Verisign liable in any way. So I see little value in Verisign certificates, infrastructure, and technologies; and any effort by Verisign to "secure DNS" of dubious value and a bit frightening. Marketing, yo! From owner-ietf-pkix@imc.org Wed Aug 16 21:29:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05864 for ; Wed, 16 Aug 2000 21:29:21 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA21877; Wed, 16 Aug 2000 18:29:07 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 16 Aug 2000 18:28:59 -0700 Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA21831 for ; Wed, 16 Aug 2000 18:28:57 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id SAA28942; Wed, 16 Aug 2000 18:27:50 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 Aug 2000 18:26:20 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4986826@vhqpostal.verisign.com> From: Warwick Ford To: "'Dennis Glatting'" , Stephen Kent Cc: Lynn.Wheeler@firstdata.com, ietf-pkix@imc.org Subject: RE: Client-side revocation checking capability Date: Wed, 16 Aug 2000 18:26:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Dennis: You are referring to T&C related to a particular type of certificate issued by VeriSign in a particular TTP capacity. Our other PKI service and technology offerings have their own contractual T&C. This is not a particularly unusual situation for vendors that offer many different types of products..... Warwick > -----Original Message----- > From: Dennis Glatting [mailto:dennis.glatting@software-munitions.com] > Sent: Wednesday, August 16, 2000 4:10 PM > To: Stephen Kent > Cc: Warwick Ford; Lynn.Wheeler@firstdata.com; ietf-pkix@imc.org > Subject: Re: Client-side revocation checking capability [snip] > And, if you follow www.verisign.com/repository/RPA/, which is > embedded in my Verisign personal certificate as a pointer to > their CPS, you will find: > > * You are responsible for deciding whether the > information in the certificate is relevant. > > * If you are not a Verisign customer (e.g., > some dummy connecting to a Verisign certified > e-commerce site such as Amazon.COM), and you > want to check for revocation, then you must > agree to their CSP if you want to use their > online services. > > So much for Section 1, Section 2, which covers CRLs, is equally > interesting. However, Section 5 says, as a non-subscriber, that > Verisign doesn't warrant certificate merchantability, fitness, > or the accuracy of information. Then, of course, you won't hold > Verisign liable in any way. > > So I see little value in Verisign certificates, infrastructure, and > technologies; and any effort by Verisign to "secure DNS" of dubious > value and a bit frightening. > > Marketing, yo! > From owner-ietf-pkix@imc.org Thu Aug 17 06:59:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23326 for ; Thu, 17 Aug 2000 06:59:09 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA03251; Thu, 17 Aug 2000 03:58:21 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Aug 2000 03:57:52 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA03218 for ; Thu, 17 Aug 2000 03:57:51 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23269; Thu, 17 Aug 2000 06:57:45 -0400 (EDT) Message-Id: <200008171057.GAA23269@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-qc-06.txt Date: Thu, 17 Aug 2000 06:57:45 -0400 Sender: nsyracus@cnri.reston.va.us Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Qualified Certificates Profile Author(s) : S. Santesson, T. Polk, P. Barzin, M. Nystrom Filename : draft-ietf-pkix-qc-06.txt Pages : 33 Date : 16-Aug-00 This document forms a certificate profile for Qualified Certificates, based on RFC 2459, for use in the Internet. The term Qualified Certificate is used to describe a certificate with a certain qualified status within applicable governing law. Further, Qualified Certificates are issued exclusively to physical persons. The goal of this document is to define a general syntax independent of local legal requirements. The profile is however designed to allow further profiling in order to meet specific local needs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-qc-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-qc-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000816095203.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-qc-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-qc-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000816095203.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@imc.org Thu Aug 17 08:13:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24731 for ; Thu, 17 Aug 2000 08:13:25 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA08805; Thu, 17 Aug 2000 05:12:40 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Aug 2000 05:12:34 -0700 Received: from picard.noroff.no ([212.20.204.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08771 for ; Thu, 17 Aug 2000 05:12:32 -0700 (PDT) Received: by picard.noroff.no (Postfix, from userid 815) id DD2E522003; Thu, 17 Aug 2000 14:57:24 +0200 (CEST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by picard.noroff.no (Postfix) with ESMTP id 490C1B3803 for ; Thu, 17 Aug 2000 14:57:22 +0200 (CEST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA28488 for ietf-123-outbound.09@ietf.org; Thu, 17 Aug 2000 07:25:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA28340 for ; Thu, 17 Aug 2000 06:57:45 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23269; Thu, 17 Aug 2000 06:57:45 -0400 (EDT) Message-Id: <200008171057.GAA23269@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-qc-06.txt Date: Thu, 17 Aug 2000 06:57:45 -0400 Sender: nsyracus@cnri.reston.va.us X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Qualified Certificates Profile Author(s) : S. Santesson, T. Polk, P. Barzin, M. Nystrom Filename : draft-ietf-pkix-qc-06.txt Pages : 33 Date : 16-Aug-00 This document forms a certificate profile for Qualified Certificates, based on RFC 2459, for use in the Internet. The term Qualified Certificate is used to describe a certificate with a certain qualified status within applicable governing law. Further, Qualified Certificates are issued exclusively to physical persons. The goal of this document is to define a general syntax independent of local legal requirements. The profile is however designed to allow further profiling in order to meet specific local needs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-qc-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-qc-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000816095203.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-qc-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-qc-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000816095203.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@imc.org Thu Aug 17 11:15:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28384 for ; Thu, 17 Aug 2000 11:15:42 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA18636; Thu, 17 Aug 2000 08:15:03 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Aug 2000 08:14:11 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18467 for ; Thu, 17 Aug 2000 08:14:08 -0700 (PDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10263 for ; Thu, 17 Aug 2000 08:14:03 -0700 (PDT) Received: from saguaro.East.Sun.COM (saguaro.East.Sun.COM [129.148.75.130]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA10978 for ; Thu, 17 Aug 2000 11:14:01 -0400 (EDT) Received: (from aha@localhost) by saguaro.East.Sun.COM (8.9.3+Sun/8.9.1) id LAA03478; Thu, 17 Aug 2000 11:13:59 -0400 (EDT) From: Anne Anderson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14748.311.613517.443300@east.sun.com> Date: Thu, 17 Aug 2000 11:13:59 -0400 (EDT) To: ietf-pkix@imc.org Subject: excluding all names of given type X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit CASE: NameConstraints excludedSubtrees contains a directoryName where the RDNSequence is null SEMANTICS: Does this mean that the subsequent path may contain no names of type directoryName in either Subject or the SubjectAlternativeNames? Is there a better way to achieve these semantics? Anne -- Anne H. Anderson Email: aha@acm.org Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692 From owner-ietf-pkix@imc.org Thu Aug 17 11:36:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28766 for ; Thu, 17 Aug 2000 11:36:33 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA23353; Thu, 17 Aug 2000 08:36:15 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Aug 2000 08:36:12 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23313 for ; Thu, 17 Aug 2000 08:36:11 -0700 (PDT) Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA10798; Thu, 17 Aug 2000 11:35:43 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <14748.311.613517.443300@east.sun.com> References: <14748.311.613517.443300@east.sun.com> Date: Thu, 17 Aug 2000 11:29:53 -0400 To: Anne Anderson From: Stephen Kent Subject: Re: excluding all names of given type Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Anne, I think the example you gave is a reasonable way to express the semantics in question. (Slight clarification: since a subject name is always a DN, the example suggests to me that the subject name would have to be NULL to comply, and that a subject alt name must be of a type other than directory name.) Steve From owner-ietf-pkix@imc.org Thu Aug 17 11:42:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28877 for ; Thu, 17 Aug 2000 11:42:01 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA24179; Thu, 17 Aug 2000 08:41:47 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Aug 2000 08:41:45 -0700 Received: from smtp.africaonline.co.ke (smtp.africaonline.co.ke [216.252.240.5]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA24149 for ; Thu, 17 Aug 2000 08:41:41 -0700 (PDT) Received: (qmail 22593 invoked from network); 17 Aug 2000 15:43:45 -0000 Received: from users.africaonline.co.ke (199.103.176.4) by smtp.africaonline.co.ke with SMTP; 17 Aug 2000 15:43:45 -0000 Received: (qmail 4704 invoked from network); 17 Aug 2000 15:37:29 -0000 Received: from kcb.co.ke (HELO PROJECTHERCULES.kcb.co.ke) (192.168.201.36) by users.africaonline.co.ke with SMTP; 17 Aug 2000 15:37:29 -0000 Received: by PROJECTHERCULES with Internet Mail Service (5.5.2650.21) id ; Thu, 17 Aug 2000 17:09:24 +0300 Message-ID: <25CEF634270DD41199BA00508B6B80AD10C1AF@GEMINI_EXCH> From: "Okello, Gilbert" To: ietf-pkix@imc.org Subject: unsubscribe Date: Thu, 17 Aug 2000 17:13:06 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00854.BEB3A736" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C00854.BEB3A736 Content-Type: text/plain; charset="iso-8859-1" ------_=_NextPart_001_01C00854.BEB3A736 Content-Type: text/html; charset="iso-8859-1" unsubscribe

------_=_NextPart_001_01C00854.BEB3A736-- From owner-ietf-pkix@imc.org Thu Aug 17 13:08:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00544 for ; Thu, 17 Aug 2000 13:08:27 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA26423; Thu, 17 Aug 2000 10:07:12 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Aug 2000 10:07:06 -0700 Received: from mail.yourdomain.com (m319-mp1-cvx1a.man.ntl.com [62.252.197.63]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA26173; Thu, 17 Aug 2000 09:58:55 -0700 (PDT) From: announce@leisurewebcams.com Message-Id: <200008171658.JAA26173@ns.secondary.com> Date: Thu, 17 Aug 2000 14:23:35 Subject: LeisureWebcams.com - See the World Precedence: bulk To: undisclosed-recipients:; List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe LeisureWebcams.com is a recently launched website specialising in providing free LIVE access to over 1,500 webcams and 2,000 Tourist Offices world wide. Check it out:- http://www.leisurewebcams.com/ This offers you the chance to check out live and frequently updated images of your chosen location through the webcams and get detailed local knowledge through the Tourist Offices. Along with booking holidays direct through our travel partner, there is the opportunity to sell your unwanted clothes and equipment through our free Swap Shop. There is a lot to see, so if you have enjoyed your trip through our site, do tell your friends and let us know through 'Your Views'. If you have any suggestions for the site, or queries, please feel free to contact me at cy@LeisureWebcams.com. I look forward to hearing from you. Kind regards, Charlie Yates MARKETING DIRECTOR LeisureWebcams.com From owner-ietf-pkix@imc.org Thu Aug 17 14:07:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01672 for ; Thu, 17 Aug 2000 14:07:10 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA27939; Thu, 17 Aug 2000 11:06:39 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Aug 2000 11:06:34 -0700 Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27909 for ; Thu, 17 Aug 2000 11:06:34 -0700 (PDT) Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id OAA23279; Thu, 17 Aug 2000 14:06:03 -0400 (EDT) Message-Id: <4.2.0.58.20000817130750.00c43200@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 17 Aug 2000 13:55:59 -0400 To: Anne Anderson , ietf-pkix@imc.org From: Tim Polk Subject: Re: excluding all names of given type Cc: Sharon Boeyen In-Reply-To: <14748.311.613517.443300@east.sun.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Anne,

I think I would state this in reverse.
CASE: NameConstraints *includedSubtrees* contains a directoryName where the RDNSequence is NULL

has the
SEMANTICS:  The Subject field and the directoryName field of the SubjectAlternativeName (if it appears at all) may only contain names in the subtree NULL for all successive certificates in the path.

The only name in the subtree NULL would be the exact match - the NULL value.  That would work, since we require a NULL RDNSequence if the Subject is omitted.  As Steve has pointed out, this should only occur in an end entity certificate.

This is not particularly straightforward, I know.  We are using the include feature to exclude names!  However, it works *if* you consider the only name in the subtree NULL is NULL itself.

On the other hand, you could consider NULL the implicit root of all subtrees, the correct answer is excludedSubtrees is NULL with a minimum value of 1.  (We would need to set the minimum to 1 so that NULL itself was not excluded.)

This would force us to use (and process) the minimum value.  RFC 2459 states that the minimum and maximum never are used, so minimum is always zero.

I prefer the *includedSubtrees* solution.  The truth is, of course, as long as we pick one way and state it clearly we should be fine.  I don't think the X.5xx specifications cover this issue, but I've been wrong before on that point!

Sharon, do you know if this topic has been addressed anywhere before??  Our first consideration should be conformance to X.509 etc if a clear solution has been established.  If this has not been addressed, we should sort it out ASAP.

Thanks,

Tim

At 11:13 AM 8/17/00 -0400, Anne Anderson wrote:
CASE: NameConstraints excludedSubtrees contains a directoryName where
the RDNSequence is null

SEMANTICS: Does this mean that the subsequent path may contain no
names of type directoryName in either Subject or the
SubjectAlternativeNames?

Is there a better way to achieve these semantics?

Anne
--
Anne H. Anderson             Email: aha@acm.org
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692
From owner-ietf-pkix@imc.org Fri Aug 18 10:46:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29446 for ; Fri, 18 Aug 2000 10:46:43 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA07752; Fri, 18 Aug 2000 07:43:42 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 18 Aug 2000 07:43:15 -0700 Received: from camero.webfilter.org ([63.106.56.213]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07705; Fri, 18 Aug 2000 07:43:12 -0700 (PDT) Received: from drew ([10.1.1.25]) by camero.webfilter.org (Post.Office MTA v3.5.3 release 223 ID# 0-61168U1000L100S0V35) with SMTP id org; Fri, 18 Aug 2000 10:50:11 -0400 Message-ID: <014901c00922$8c351140$1901010a@webfilter> From: education@iwebmedia.net (Ed. Dept.) To: Subject: Free Advertising Date: Fri, 18 Aug 2000 10:42:34 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0146_01C00901.04E04DC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------=_NextPart_000_0146_01C00901.04E04DC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -------------------------------------------------------------------------= ------- Try our free training demo and receive an advertising banner for your = company for 1 month FREE on the popular search engine Go Look For It! (no purchase necessary) -------------------------------------------------------------------------= ------- =20 Want to enhance your computer skills and career?=20 Employees need training but can't afford the time or investment?=20 Interested in becoming a Microsoft Certified Systems Engineer (MCSE)?=20 Want low-cost, high-quality training on Word, Excel and other PC = software?=20 Low-cost training to help you achieve your goals is at your fingertips! Our Courseware is accessible anywhere at any time through the Internet! Subjects such as Microsoft's MCSE, MCSE plus Internet, MCP and MOUS certifications (all Microsoft Approved) , A+ Certification, Java, = HTML, Cisco and more! Currently over 400 courses, with approximately 30 new courses added = quarterly!=20 Click here to TRY A FREE DEMO or see our COURSE CATALOG and FEATURES. Special price only $29.95 per month for unlimited access to all 400+ = courses! Click here to sign up online or call us at 727-536-5517. That's a $576.00 value for only $29.95 to receive of unlimited access to = over 400 courses! No long term contracts...cancel anytime! This special price is available through this e-mail offer only. Offer expires August 18, 2000 at 5:00 pm E.S.T. ONE YEAR FREE!! Register here to win full access to all 400+ courses = absolutely FREE for 1 year. No purchase necessary. Trying a free demo or signing up will = automatically register you. Education is the key to success... __________________________________________________________________ Over 400 courses available anytime, anywhere! Try our free demo at >>>> www.onlinetrainingcollege.com <<<< Your e-mail address was received from an opt-in list for educational = information. If you received this message in error or to be removed from this mailing list, reply to this message and type = the word REMOVE in your e-mail subject line.=20 ------=_NextPart_000_0146_01C00901.04E04DC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 Try our free training demo and receive an advertising banner = for your=20 company
for 1 month FREE on the = popular=20 search engine Go Look=20 For It!
(no purchase = necessary)
 
Want to enhance your computer skills and career?=20

Employees need training but = can't afford=20 the time or investment?

Interested in becoming a = Microsoft=20 Certified Systems Engineer (MCSE)?

Want low-cost, high-quality = training on=20 Word, Excel and other PC software?

Low-cost training to help you achieve = your goals is=20 at your fingertips!
Our Courseware is accessible anywhere at any time = through=20 the Internet!
Subjects such as Microsoft's MCSE, MCSE plus Internet, = MCP=20 and
MOUS certifications (all Microsoft = Approved) ,=20 A+ Certification, Java, HTML, Cisco and more!
Currently over 400 = courses, with approximately 30 new courses added = quarterly! 

Click=20 here to TRY=20 A FREE DEMO or see our COURSE=20 CATALOG and FEATURES.

Special price = only $29.95 per=20 month for unlimited access to all 400+=20 courses!
Click here to sign=20 up online or call us at=20 727-536-5517.
That's a $576.00 value for only=20 $29.95 to receive of unlimited access to over 400 courses!
No = long term=20 contracts...cancel anytime!

This special price is available = through this=20 e-mail offer only.
Offer expires August 18, 2000 at 5:00 pm = E.S.T.

ONE = YEAR FREE!! =20 Register=20 here to win full access to all 400+ courses absolutely = FREE for 1 year.
No purchase = necessary.=20 Trying a free demo or signing up will automatically register=20 you.
 
Education is the key=20 to success...
 
________________________________________________________________= __
Over=20 400 courses available anytime, anywhere!
Try our free demo at=20 >>>> www.onlinetrainingcollege.c= om=20 <<<<
 
Your e-mail address was received from = an opt-in=20 list for educational information. If you received this message in=20 error
or to be = removed from this=20 mailing list, reply to this message and type the word REMOVE in your = e-mail=20 subject line.
------=_NextPart_000_0146_01C00901.04E04DC0-- From owner-ietf-pkix@imc.org Sat Aug 19 19:43:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03816 for ; Sat, 19 Aug 2000 19:43:23 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA26441; Sat, 19 Aug 2000 16:42:32 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 19 Aug 2000 16:41:34 -0700 Received: from crack.x509.com (root@crack.x509.com [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26401 for ; Sat, 19 Aug 2000 16:41:33 -0700 (PDT) Received: from xcert.com (home.x509.com [199.175.150.4]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e7JNfeS03117 for ; Sat, 19 Aug 2000 16:41:40 -0700 (PDT) Message-ID: <399F4859.A91DD008@xcert.com> Date: Sat, 19 Aug 2000 19:54:17 -0700 From: Tom Strickland X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: President Clinton digital signing Content-Type: multipart/mixed; boundary="------------FC009E784720B3674DD36487" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. --------------FC009E784720B3674DD36487 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello All, After reading several articles about President Clinton and the digital signature signing, it appears that people have an inaccurate impression regarding the PKI technology utilized. The actual smart card was produced by DataKey but the certs were provided by Digital Signature Trust (DST) which is based on the CA software designed and built by Xcert International. --------------FC009E784720B3674DD36487 Content-Type: text/x-vcard; charset=us-ascii; name="tstrickland.vcf" Content-Description: Card for Tom Strickland Content-Disposition: attachment; filename="tstrickland.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Strickland;Tom tel;cell:678 296-4866 x-mozilla-html:TRUE org:
Xcert International Inc. adr:;;;;;; version:2.1 email;internet:tstrickland@xcert.com title:Senior Sales Engineer fn:Tom Strickland end:vcard --------------FC009E784720B3674DD36487-- From owner-ietf-pkix@imc.org Sat Aug 19 23:17:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06411 for ; Sat, 19 Aug 2000 23:17:07 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA11131; Sat, 19 Aug 2000 20:16:40 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 19 Aug 2000 20:16:16 -0700 Received: from world.std.com (geer@world-f.std.com [199.172.62.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA11073 for ; Sat, 19 Aug 2000 20:16:14 -0700 (PDT) Received: from localhost (geer@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id XAA17065 for ; Sat, 19 Aug 2000 23:16:22 -0400 (EDT) Message-Id: <200008200316.XAA17065@world.std.com> X-Authentication-Warning: world.std.com: geer@localhost didn't use HELO protocol To: ietf-pkix@imc.org Subject: Re: President Clinton digital signing In-reply-to: Your message of "Sat, 19 Aug 2000 19:54:17 EDT." <399F4859.A91DD008@xcert.com> Date: Sat, 19 Aug 2000 23:16:21 -0400 From: Dan Geer Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > After reading several articles about President Clinton and the > digital signature signing, it appears that people have an > inaccurate impression regarding the PKI technology utilized. > > The actual smart card was produced by DataKey but the certs were > provided by Digital Signature Trust (DST) which is based on the CA > software designed and built by Xcert International. I would be interested to know how this selection was made. --dan From owner-ietf-pkix@imc.org Sun Aug 20 12:42:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08812 for ; Sun, 20 Aug 2000 12:42:59 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA28323; Sun, 20 Aug 2000 09:41:52 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sun, 20 Aug 2000 09:41:33 -0700 Received: from dns1.provide.net (root@dns1.provide.net [216.86.64.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28290 for ; Sun, 20 Aug 2000 09:41:32 -0700 (PDT) Received: from cyclonecommerce.com (usr07-104.provide.net [216.86.68.104]) by dns1.provide.net (8.9.0/8.9.3) with ESMTP id MAA07576; Sun, 20 Aug 2000 12:41:10 -0400 (EDT) Message-ID: <39A00A2F.87DB18A5@cyclonecommerce.com> Date: Sun, 20 Aug 2000 12:41:19 -0400 From: Timothy Fisher X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Strickland CC: ietf-pkix@imc.org Subject: Re: President Clinton digital signing References: <399F4859.A91DD008@xcert.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Does't DST also use Entrust software? Timothy Fisher Tom Strickland wrote: > Hello All, > > After reading several articles about President Clinton and the digital > signature signing, it appears that people have an inaccurate impression > regarding the PKI technology utilized. > > The actual smart card was produced by DataKey but the certs were > provided by Digital Signature Trust (DST) which is based on the CA > software designed and built by Xcert International. From owner-ietf-pkix@imc.org Mon Aug 21 09:14:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00391 for ; Mon, 21 Aug 2000 09:14:20 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA07663; Mon, 21 Aug 2000 06:12:27 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Aug 2000 06:10:01 -0700 Received: from alpha.cdp.adelphia.net (alpha.cdp.adelphia.net [24.48.64.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07570 for ; Mon, 21 Aug 2000 06:09:59 -0700 (PDT) Received: from agibson (dynamic87.cdp.adelphia.net [24.48.60.87] (may be forged)) by alpha.cdp.adelphia.net (8.9.2/8.9.2) with SMTP id JAA02114; Mon, 21 Aug 2000 09:19:29 -0400 (EDT) Message-ID: <018a01c00b70$82719b60$576211ac@cdp.adelphia.net> From: "Alan Gibson" To: "Timothy Fisher" , "Tom Strickland" Cc: References: <399F4859.A91DD008@xcert.com> <39A00A2F.87DB18A5@cyclonecommerce.com> Subject: Re: President Clinton digital signing Date: Mon, 21 Aug 2000 09:05:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Yes ----- Original Message ----- From: "Timothy Fisher" To: "Tom Strickland" Cc: Sent: Sunday, August 20, 2000 12:41 PM Subject: Re: President Clinton digital signing > Does't DST also use Entrust software? > > Timothy Fisher > > Tom Strickland wrote: > > > Hello All, > > > > After reading several articles about President Clinton and the digital > > signature signing, it appears that people have an inaccurate impression > > regarding the PKI technology utilized. > > > > The actual smart card was produced by DataKey but the certs were > > provided by Digital Signature Trust (DST) which is based on the CA > > software designed and built by Xcert International. From owner-ietf-pkix@imc.org Mon Aug 21 10:02:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01078 for ; Mon, 21 Aug 2000 10:02:52 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA08701; Mon, 21 Aug 2000 07:02:16 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Aug 2000 07:02:09 -0700 Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08669 for ; Mon, 21 Aug 2000 07:02:06 -0700 (PDT) From: John_Wray@iris.com Subject: Re: excluding all names of given type To: Tim Polk Cc: Anne Anderson , ietf-pkix@imc.org, Sharon Boeyen X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Mon, 21 Aug 2000 10:02:32 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/21/2000 10:02:24 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA08671 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Tim Polk wrote: >On the other hand, you could consider NULL the implicit root of all subtrees, >the correct answer is excludedSubtrees is NULL with a minimum value of 1. >(We would need to set the minimum to 1 so that NULL itself was not excluded.) I don't think that's right. An empty subject DN in a certificate doesn't mean that the certificate applies to a principal whose DN is the root of the DIT, rather that the principal in question has no DN. This is a special case, called out explicitly in the PKIX profile. A certificate with an empty DN should be permitted regardless of any DN name constraints. So I don't think this requires that you set the minimum value to 1 - 0 should do just fine. >CASE: NameConstraints *includedSubtrees* contains a directoryName >where the RDNSequence is NULL > >has the > >SEMANTICS:  The Subject field and the directoryName field of the >SubjectAlternativeName (if it appears at all) may only contain names >in the subtree NULL for all successive certificates in the path. > >The only name in the subtree NULL would be the exact match - the >NULL value.  That would work, since we require a NULL RDNSequence >if the Subject is omitted.  As Steve has pointed out, this should only >occur in an end entity certificate. > >This is not particularly straightforward, I know.  We are using the include >feature to exclude names!  However, it works *if* you consider the only >name in the subtree NULL is NULL itself. Normally when a name is given as the root of a subtree, it means that members of that subtree are formed by appending RDNs to the root name (subject to any minimum and maximum path lengths in the subtree constraint, which don't apply to the PKIX profile). Thus the subtree rooted at the empty DN includes all names in the DIT. So by putting this name in the permittedSubtrees field you are saying all names are permitted, which doesn't say anything useful, as it's the default state. To use either of these mechanisms, some special-casing has to be done by relying parties, so we need to decide which mechanism we should recommend and put language into the profile to explicitly support it. I definitely favor the use of excludedSubtrees to exclude the entire X.500 DIT, both because it just seems illogical to use a permitted Subtrees extension to exclude things, but also because the reason that special-casing is necessary at all is that we have decided that an empty DN in the subject field of a certificate has special semantics, so we should strive to restrict any special casing necesssary to our interpretation of that field, rather than having to change the semantics of other fields to suit. John From owner-ietf-pkix@imc.org Mon Aug 21 10:17:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01271 for ; Mon, 21 Aug 2000 10:17:21 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA09142; Mon, 21 Aug 2000 07:16:49 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Aug 2000 07:16:45 -0700 Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09111 for ; Mon, 21 Aug 2000 07:16:44 -0700 (PDT) Received: from kant [129.27.152.76] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A9DAB500BA; Mon, 21 Aug 2000 16:16:58 +0200 Message-ID: <021801c00b7a$780282c0$4c981b81@iaik.tugraz.ac.at> From: "Christian Vogel" To: Subject: time stamping server example Date: Mon, 21 Aug 2000 16:16:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA09112 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit I checked the log files of the time stamping server. There were a lot of problems with the correct format. Therefore I will post an example: The time stamping server is a socket based server as described in . Its IP adress is: 129.27.142.227:318 common format: [4 bytes length (network byte order)][1 byte flag][length bytes DER encoded TimeStampReq] TimeStampReq: Version: 1 MessageImprint: HashAlgorithm: SHA HashedMessage: 45:81:E2:50:F2:F0:9E:0D:EC:00:14:C7:20:A7:87:6B:BE:05:06:6B Nonce: 15757292069520509269 CertReq: true DER encoded TimeStampReq: 30:34:02:01:01:30:21:30:09:06:05:2B:0E:03:02:1A:05:00:04:14:45:81:E2:50:F2:F0:9E: 0D:EC:00:14:C7:20:A7:87:6B:BE:05:06:6B:02:09:00:DA:AD:25:A6:C9:D9:89:55:01:01:FF direct TCP-based TSA message: 00:00:00:37:00:30:34:02:01:01:30:21:30:09:06:05:2B:0E:03:02:1A:05:00:04:14:45:81:E2:50:F2:F0:9E: 0D:EC:00:14:C7:20:A7:87:6B:BE:05:06:6B:02:09:00:DA:AD:25:A6:C9:D9:89:55:01:01:FF Regards Christian -- Christian Vogel office: [cvogel@iaik.at] [http://jcewww.iaik.tu-graz.ac.at] private: [bird@sbox.tu-graz.ac.at] [http://www.sbox.tu-graz.ac.at/home/b/bird From owner-ietf-pkix@imc.org Mon Aug 21 11:04:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02171 for ; Mon, 21 Aug 2000 11:04:29 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA10260; Mon, 21 Aug 2000 08:02:42 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Aug 2000 08:02:34 -0700 Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10230 for ; Mon, 21 Aug 2000 08:02:32 -0700 (PDT) Received: (from godslord@localhost) by venus.initech.com (8.9.3/8.9.3) id XAA11039 for ietf-pkix@imc.org; Mon, 21 Aug 2000 23:59:49 +0900 (KST) Date: Mon, 21 Aug 2000 23:59:49 +0900 From: "Kwon, YongChul" To: ietf-pkix@imc.org Subject: ASN.1 Encoding of no valued extension Message-ID: <20000821235949.B10970@venus.initech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Organization: Initech, Inc Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I wonder about how no valued extension will be encoded in DER form. for example, NameConstraints ::= SEQUENCE { permittedSubtrees [0] GeneralSubtrees OPTIONAL, excludedSubtrees [1] GeneralSubtrees OPTIONAL } permittedSubtrees and excludedSubtrees are both omittable. and then it's an empty sequence when both are omitted. I'd omit this extension rather than encode as empty sequence. What's the PKIX's recomendation about this situation? both(omit or empty sequence)? or omit such extension? or encode as empty sequence? or depends on situation? :-( (I guess that just omitting Extension like that basic constraints should not appear in EE's certificates is the best way). From owner-ietf-pkix@imc.org Mon Aug 21 11:20:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02568 for ; Mon, 21 Aug 2000 11:20:29 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA11805; Mon, 21 Aug 2000 08:18:36 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Aug 2000 08:18:29 -0700 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11770 for ; Mon, 21 Aug 2000 08:18:28 -0700 (PDT) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0FZN00K01EJ3Z3@ext-mail.valicert.com> for ietf-pkix@imc.org; Mon, 21 Aug 2000 08:18:39 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0FZN00KDLEJ3IG@ext-mail.valicert.com> for ietf-pkix@imc.org; Mon, 21 Aug 2000 08:18:39 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Mon, 21 Aug 2000 08:08:39 -0700 Content-return: allowed Date: Mon, 21 Aug 2000 08:08:37 -0700 From: Ambarish Malpani Subject: RFC 2560 - OCSP - Clarification To: "'ietf-pkix@imc.org'" Message-id: <27FF4FAEA8CDD211B97E00902745CBE201B830EF@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hi Folks, Simon (Tardell) and I were talking about the need for clarification in section 2.2 of RFC 2560. We came up with the following proposal and are looking for comments on the changes -----------------Begin Proposed Changes-------------------- Replace the three paragraphs (in section 2.2) that start: 'The "good" state...the certificate being requested.' with: 'The "good" state indicates that the certificate has not been revoked. It does not indicate whether the certificate was ever issued, is still valid or any other assertion. The "revoked" state indicates that the certificate has been revoked(either permanantly or temporarily (on hold)). The "unknown" state indicates that the responder does not know, or is unwilling to tell, whether the certificate is revoked or not. A client may be able to get a definitive response later, or at another responder. Response extensions may be used to carry further status information (e.g. on issuance). -----------------End Proposed Changes-------------------- We are looking for comments on what the group thinks about these - they are just clarifications that I think can go in when we roll over from Proposed Standard to Draft Standard (at which time we should also add the OID for the ASN.1 module). Comments? Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 From owner-ietf-pkix@imc.org Mon Aug 21 11:30:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02874 for ; Mon, 21 Aug 2000 11:30:49 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA14007; Mon, 21 Aug 2000 08:28:59 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Aug 2000 08:28:57 -0700 Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13962; Mon, 21 Aug 2000 08:28:55 -0700 (PDT) Received: from alpha.hut.fi (haifengl@alpha.hut.fi [130.233.224.50]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id SAA04921; Mon, 21 Aug 2000 18:29:10 +0300 (EET DST) Date: Mon, 21 Aug 2000 18:29:10 +0300 (EET DST) From: Haifeng Lin ~!~ To: ietf-pkix-request@imc.org cc: ietf-pkix@imc.org Subject: about CA,X509,RA for security, certification validation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe subscribe Hello, I am Haifeng in Finland.I read your topic in internet. It is http://www.ietf.org/html.charters/pkix-charter.html It is very good. But it is knowledge and theory.How can I use it? I have some question about PKI, CA,CV security... I knew little bit PKI,CA, x509, RA... But I want to have a nice beginning to do. So, Would you mind give me some example and C or C++ or Java code for how to do "certificate validation"? I read one PKI book,(integrity, lifetime,signture...) It is " The integrity of the certificate is sound; that is, the digital signature on the certificate corresponds to the independently-calculated hash value of the certificate itself and the signer's public key". Another one: "the certificate is within its established validity period(as indicated by the Not Valid Before and Not valid after parameters in the certificate). how can I do "Integrity" and "validity period" for "CA"? And how did you think about "Revocation"? which is X509 structure, just for signture, lifetime,integrity,revocation? I would like to do "certification validation" by myself. 1. Presume one certification of structure that had in computer. struct x509{ int int int... } 2. I will use Vj++ or Vc++to do "validation". It includes: digitally signed, integrity,validity period, revocation. 3.Or If "Presume" I got CA from some software, how can I make "certificate Validation" in C or C++, or Java? Could you please tell me some idea and source code??Just simple... Thank you very much and have a nice week. B.R Haifeng:) From owner-ietf-pkix@imc.org Mon Aug 21 13:12:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04765 for ; Mon, 21 Aug 2000 13:12:17 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA18492; Mon, 21 Aug 2000 10:11:46 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Aug 2000 10:11:16 -0700 Received: from monet.digsigtrust.com (mail.digsigtrust.com [208.30.69.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18444 for ; Mon, 21 Aug 2000 10:11:14 -0700 (PDT) Received: from CC474623A (cc474623-a.abdn1.md.home.com [24.18.83.123]) by monet.digsigtrust.com (8.10.2/8.10.2) with SMTP id e7LHBDK13519; Mon, 21 Aug 2000 11:11:13 -0600 (MDT) Reply-To: From: "Yuriy Dzambasow" To: "Alan Gibson" , "Timothy Fisher" , "Tom Strickland" Cc: Subject: RE: President Clinton digital signing Date: Mon, 21 Aug 2000 13:06:34 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <018a01c00b70$82719b60$576211ac@cdp.adelphia.net> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit DST uses a variety of CA technologies in our managed services offerings, and are not solely reliant on any one technology. Yuriy -----Original Message----- From: Alan Gibson [mailto:agibson@adelphia.net] Sent: Monday, August 21, 2000 9:06 AM To: Timothy Fisher; Tom Strickland Cc: ietf-pkix@imc.org Subject: Re: President Clinton digital signing Yes ----- Original Message ----- From: "Timothy Fisher" To: "Tom Strickland" Cc: Sent: Sunday, August 20, 2000 12:41 PM Subject: Re: President Clinton digital signing > Does't DST also use Entrust software? > > Timothy Fisher > > Tom Strickland wrote: > > > Hello All, > > > > After reading several articles about President Clinton and the digital > > signature signing, it appears that people have an inaccurate impression > > regarding the PKI technology utilized. > > > > The actual smart card was produced by DataKey but the certs were > > provided by Digital Signature Trust (DST) which is based on the CA > > software designed and built by Xcert International. From owner-ietf-pkix@imc.org Mon Aug 21 13:51:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05528 for ; Mon, 21 Aug 2000 13:51:29 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA19330; Mon, 21 Aug 2000 10:50:57 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Aug 2000 10:50:54 -0700 Received: from serv1.is1.u-net.net (serv1.is1.u-net.net [195.102.240.129]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19299 for ; Mon, 21 Aug 2000 10:50:49 -0700 (PDT) Received: from [195.232.106.149] (helo=dwc-acer) by serv1.is1.u-net.net with esmtp (Exim 3.12 #1) id 13Qvif-00019B-00; Mon, 21 Aug 2000 18:50:49 +0100 From: "David Chadwick" Organization: University of Salford To: Anne Anderson , ietf-pkix@imc.org, Tim Polk Date: Mon, 21 Aug 2000 18:50:20 +0100 MIME-Version: 1.0 Content-type: text/enriched; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: excluding all names of given type Reply-to: d.w.chadwick@salford.ac.uk CC: Sharon Boeyen Message-ID: <39A179EC.24015.5CF9C00@localhost> Priority: normal In-reply-to: <4.2.0.58.20000817130750.00c43200@email.nist.gov> References: <14748.311.613517.443300@east.sun.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7BIT Date sent: Thu, 17 Aug 2000 13:55:59 -0400 To: Anne Anderson <, ietf-pkix@imc.org From: Tim Polk < Subject: Re: excluding all names of given type Copies to: Sharon Boeyen < Times New RomanAnne,  I think I would state this in reverse.  leftCASE: NameConstraints *includedSubtrees* contains a directoryName where the RDNSequence is NULL  has the leftSEMANTICS: The Subject field and the directoryName field of the SubjectAlternativeName (if it appears at all) may only contain names in the subtree NULL for all successive certificates in the path. The only name in the subtree NULL would be the exact match - the NULL value. That would work, since we require a NULL RDNSequence if the Subject is omitted. As Steve has pointed out, this should only occur in an end entity certificate. leftTim I do not agree with your semantics. The null name is the name of the root of the DIT, and therefore implies ALL subordinate names. Since a DIT subtree can comprise a single entry or any number of entries up to the whole DIT, then a null name implies a subtree of the whole DIT. Thus include NULL implies include any directory name at all - not a particularly usefull extension to include in a certificate. David This is not particularly straightforward, I know. We are using the include feature to exclude names! However, it works *if* you consider the only name in the subtree NULL is NULL itself.  On the other hand, you could consider NULL the implicit root of all subtrees, the correct answer is excludedSubtrees is NULL with a minimum value of 1. (We would need to set the minimum to 1 so that NULL itself was not excluded.)  This would force us to use (and process) the minimum value. RFC 2459 states that the minimum and maximum never are used, so minimum is always zero.  I prefer the *includedSubtrees* solution. The truth is, of course, as long as we pick one way and state it clearly we should be fine. I don't think the X.5xx specifications cover this issue, but I've been wrong before on that point!  Sharon, do you know if this topic has been addressed anywhere before?? Our first consideration should be conformance to X.509 etc if a clear solution has been established. If this has not been addressed, we should sort it out ASAP.  Thanks,  Tim  At 11:13 AM 8/17/00 -0400, Anne Anderson wrote: leftCASE: NameConstraints excludedSubtrees contains a directoryName where the RDNSequence is null  SEMANTICS: Does this mean that the subsequent path may contain no names of type directoryName in either Subject or the SubjectAlternativeNames?  Is there a better way to achieve these semantics?  Anne --  Anne H. Anderson Email: aha@acm.org Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692 *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From owner-ietf-pkix@imc.org Mon Aug 21 13:51:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05542 for ; Mon, 21 Aug 2000 13:51:48 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA19422; Mon, 21 Aug 2000 10:51:18 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Aug 2000 10:51:15 -0700 Received: from serv1.is1.u-net.net (serv1.is1.u-net.net [195.102.240.129]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19368 for ; Mon, 21 Aug 2000 10:51:14 -0700 (PDT) Received: from [195.232.106.149] (helo=dwc-acer) by serv1.is1.u-net.net with esmtp (Exim 3.12 #1) id 13Qvj1-00019B-00; Mon, 21 Aug 2000 18:51:10 +0100 From: "David Chadwick" Organization: University of Salford To: Ambarish Malpani , "'TAKIGUCHI Naruhito'" , ietf-pkix@imc.org Date: Mon, 21 Aug 2000 18:50:21 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: CRL number in CRL and ARL Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <39A179ED.9934.5CFA05B@localhost> Priority: normal In-reply-to: <27FF4FAEA8CDD211B97E00902745CBE2B41816@seine.valicert.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7BIT From: Ambarish Malpani To: "'TAKIGUCHI Naruhito'" , ietf-pkix@imc.org Subject: RE: CRL number in CRL and ARL Date sent: Wed, 9 Aug 2000 22:33:13 -0700 > > If you are using CRLDPs, the numbering for each DP is independent. > > It is okay to number them in the following way: > > Time DP1 DP2 > 1 10 5 > 2 12 17 > 3 15 18 > 4 99 201 > 5 202 202 Ambarish, How does your unique and apparently random numbering scheme allow the CRL user to quote "detect whether CRLs issued prior to the one being processed were also seen and processed." I dont believe it can, and therefore does not fulfil the requirements of X.509. I believe the intention was always to have sequence numbers. Note that RFC2459 has changed the semantics of X.509 by using the phrase quote "allows users to easily determine when a particular CRL supersedes another CRL. " Clearly your randon scheme fulfils the requirement of 2459, but not of X.509. Was this semantic change intentional by the authors of 2459? Warwick, Tim, Dave, Russ? As I see it, for aperiodic issuing of CRLs, the CRL number can be used to detect a missing CRL. For strict periodic issuing the time can be used instead of the CRL number. David > > Or any other interesting scheme you would prefer, as long as > the numbers for DP1 are monotonically increasing and the > numbers for DP2 are monotoncally increasing. > > Note: This example is *not* meant to imply that you even need to > issue both DPs at all the times specified. > > Regards, > Ambarish > > --------------------------------------------------------------------- > Ambarish Malpani Architect > 650.567.5457 ValiCert, Inc. > ambarish@valicert.com 339 N. Bernardo Ave. > http://www.valicert.com Mountain View, CA 94043 > > > > -----Original Message----- > > From: TAKIGUCHI Naruhito [mailto:takiguti@fjh.se.fujitsu.co.jp] > > Sent: Wednesday, August 09, 2000 7:59 PM To: ietf-pkix@imc.org > > Subject: Re: CRL number in CRL and ARL > > > > > > Ambarish, > > > > > If you are creating CRLs and ARLs that are not complete (i.e. > > > don't contain all the entries the other does), it is very > > > important that you use the CRLDP method of doing it. Put in > > > CRLDP extensions in the certificates and IDP (Issuing Distribution > > > Point) extensions in your CRLs/ARLs. > > > > > > If you don't use the CRLDP mechanism, you run the risk of having a > > > bunch of applications misbehave with your CRLs. > > > > Thank you. I agree with your advice. > > But, I'm going to discussion about the CRL number. > > > > I think that the method (a)(the CRL number is a sequece > > number for each > > CRL scope) is better than the method (b) for a relying party. > > RFC2459 and son of RFC2459 describe following : > > > > The CRL number is a non-critical CRL extension which > > conveys a mono- > > tonically increasing sequence number for each CRL issued by a CA. > > > > Does "for each CRL issued by a CA" sentence mean the method (b) ? > > > > Thanks in advance. > > > > > Regards, > > > Ambarish > > > > > > > > -------------------------------------------------------------------- > > - > > > Ambarish Malpani > > > Architect > > 650.567.5457 > > > ValiCert, Inc. > > ambarish@valicert.com > > > 339 N. Bernardo Ave. > > http://www.valicert.com > > > Mountain View, CA 94043 > > > > > > > > > > -----Original Message----- > > > > From: TAKIGUCHI Naruhito [mailto:takiguti@fjh.se.fujitsu.co.jp] > > > > Sent: Tuesday, August 08, 2000 8:13 PM To: ietf-pkix@imc.org > > > > Subject: CRL number in CRL and ARL > > > > > > > > > > > > Hi, all. > > > > > > > > I have a question about the cRLNumber extension. > > > > > > > > For example, a CA issues CRL(end-entity certificate > > revocation list) > > > > and ARL(CA certificate revocation list). > > > > Which is correct (a) or (b) ? > > > > > > > > (a) In first CRL and ARL, the CRL number is 0. > > > > In next CRL and ARL, the CRL number is 1. > > > > > > > > In other words, CRL and ARL have same value of > > the CRL number. > > > > The CRL number is a monotonically increasing > > sequence number > > > > for each CRL scope. > > > > > > > > (b) In first CRL, the CRL Number is 0. > > > > In first ARL, the CRL Number is 1. > > > > In next CRL, the CRL number is 2. > > > > In next ARL, the CRL number is 3. > > > > > > > > In other words, the CRL number is monotonically > > > > increasing sequence number for each CA. > > > > > > > > Could anyone advice me? > > > > > > > > Thanks in advance. > > > > > > > > ----- > > > > Naruhito TAKIGUCHI > > > > FUJITSU HOKURIKU SYSTEMS LTD. > > > > > > > > ----- > > Naruhito TAKIGUCHI > > FUJITSU HOKURIKU SYSTEMS LTD. > > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From owner-ietf-pkix@imc.org Mon Aug 21 13:51:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05553 for ; Mon, 21 Aug 2000 13:51:59 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA19464; Mon, 21 Aug 2000 10:51:22 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Aug 2000 10:51:17 -0700 Received: from serv1.is1.u-net.net (serv1.is1.u-net.net [195.102.240.129]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19396 for ; Mon, 21 Aug 2000 10:51:16 -0700 (PDT) Received: from [195.232.106.149] (helo=dwc-acer) by serv1.is1.u-net.net with esmtp (Exim 3.12 #1) id 13QvjH-00019B-00; Mon, 21 Aug 2000 18:51:25 +0100 From: "David Chadwick" Organization: University of Salford To: Anne Anderson , ietf-pkix@imc.org Date: Mon, 21 Aug 2000 18:50:19 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: excluding all names of given type Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <39A179EB.15636.5CF9829@localhost> Priority: normal In-reply-to: <14748.311.613517.443300@east.sun.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7BIT From: Anne Anderson Date sent: Thu, 17 Aug 2000 11:13:59 -0400 (EDT) To: ietf-pkix@imc.org Subject: excluding all names of given type > CASE: NameConstraints excludedSubtrees contains a directoryName where > the RDNSequence is null > > SEMANTICS: Does this mean that the subsequent path may contain no > names of type directoryName in either Subject or the > SubjectAlternativeNames? Anne I would agree with your interpretation above, David > > Is there a better way to achieve these semantics? > > Anne > -- > Anne H. Anderson Email: aha@acm.org > Sun Microsystems Laboratories > 1 Network Drive,UBUR02-311 Tel: 781/442-0928 > Burlington, MA 01803-0902 USA Fax: 781/442-1692 > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From owner-ietf-pkix@imc.org Mon Aug 21 14:25:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06319 for ; Mon, 21 Aug 2000 14:25:12 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA20360; Mon, 21 Aug 2000 11:24:38 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Aug 2000 11:24:29 -0700 Received: from smtpproxy1.mitre.org ([129.83.20.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20328 for ; Mon, 21 Aug 2000 11:24:28 -0700 (PDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id OAA20227; Mon, 21 Aug 2000 14:24:08 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id OAA08332; Mon, 21 Aug 2000 14:21:40 -0400 (EDT) Received: from schaen-pc.mitre.org (128.29.162.49) by mailhub2.mitre.org with SMTP id 4251801; Mon, 21 Aug 2000 14:24:06 EST Message-ID: <39A173CA.C9EF2071@mitre.org> Date: Mon, 21 Aug 2000 14:24:10 -0400 From: Sam Schaen X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ambarish Malpani CC: "'ietf-pkix@imc.org'" Subject: Re: RFC 2560 - OCSP - Clarification References: <27FF4FAEA8CDD211B97E00902745CBE201B830EF@seine.valicert.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit I would like to suggest the words included in all-caps below to highlight the fact that the responder is in a position to know the revocation status of the certificate. 'The "good" state indicates that THE RESPONDER HAS CURRENT REVOCATION INFORMATION FROM THE CA THAT ISSUED THE CERTIFICATE AND the certificate has not been revoked. It does not indicate whether the certificate was ever issued, is still valid or any other assertion. Ambarish Malpani wrote: > Hi Folks, > Simon (Tardell) and I were talking about the need for > clarification in section 2.2 of RFC 2560. We came up with > the following proposal and are looking for comments on the > changes > > -----------------Begin Proposed Changes-------------------- > > Replace the three paragraphs (in section 2.2) that start: > 'The "good" state...the certificate being requested.' > with: > > 'The "good" state indicates that the certificate has not been revoked. It > does not indicate whether the certificate was ever issued, is still valid or > any other assertion. > > The "revoked" state indicates that the certificate has been revoked(either > permanantly or temporarily (on hold)). > > The "unknown" state indicates that the responder does not know, or is > unwilling to tell, whether the certificate is revoked or not. A client may > be able to get a definitive response later, or at another responder. > > Response extensions may be used to carry further status information (e.g. on > issuance). > > -----------------End Proposed Changes-------------------- > > We are looking for comments on what the group thinks about these - they > are just clarifications that I think can go in when we roll over from > Proposed Standard to Draft Standard (at which time we should also add > the OID for the ASN.1 module). > > Comments? > Regards, > Ambarish > > --------------------------------------------------------------------- > Ambarish Malpani > Architect 650.567.5457 > ValiCert, Inc. ambarish@valicert.com > 339 N. Bernardo Ave. http://www.valicert.com > Mountain View, CA 94043 From owner-ietf-pkix@imc.org Mon Aug 21 14:55:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07029 for ; Mon, 21 Aug 2000 14:55:52 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA21044; Mon, 21 Aug 2000 11:55:22 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Aug 2000 11:55:19 -0700 Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21013 for ; Mon, 21 Aug 2000 11:55:18 -0700 (PDT) Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA10671 for ; Mon, 21 Aug 2000 11:55:34 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id LAA10786 for ; Mon, 21 Aug 2000 11:55:33 -0700 (PDT) Received: from xch-pssbh-03.ca.boeing.com by blv-hub-01.boeing.com with ESMTP for ietf-pkix@imc.org; Mon, 21 Aug 2000 11:55:20 -0700 Received: by xch-pssbh-03.ca.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 21 Aug 2000 11:55:19 -0700 Message-Id: <5C92DF4CFB16D4119F5E00508B95A11EA5D06E@xch-nw-01b.ca.boeing.com> From: "Knoll, Jacqueline D" To: ietf-pkix@imc.org Subject: unsubscribe Date: Mon, 21 Aug 2000 11:55:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00BA1.5948D740" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C00BA1.5948D740 Content-Type: text/plain; charset="iso-8859-1" unsubscribe ------_=_NextPart_001_01C00BA1.5948D740 Content-Type: text/html; charset="iso-8859-1" unsubscribe
unsubscribe
------_=_NextPart_001_01C00BA1.5948D740-- From owner-ietf-pkix@imc.org Tue Aug 22 03:33:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28840 for ; Tue, 22 Aug 2000 03:33:02 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA26889; Tue, 22 Aug 2000 00:32:32 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 22 Aug 2000 00:32:19 -0700 Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA26830 for ; Tue, 22 Aug 2000 00:32:17 -0700 (PDT) Received: from kant [129.27.152.76] by iaik.tu-graz.ac.at (SMTPD32-6.00) id AC6C170F00D8; Tue, 22 Aug 2000 09:31:56 +0200 Message-ID: <005b01c00c0b$0cd36cd0$4c981b81@iaik.tugraz.ac.at> From: "Christian Vogel" To: Subject: Correction time stamping server example Date: Tue, 22 Aug 2000 09:31:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA26832 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Sorry, but I made a typing error. I wrote: >common format: >[4 bytes length (network byte order)][1 byte flag][length bytes DER encoded TimeStampReq] Correct is: [4 bytes length (network byte order)][1 byte flag][(length-1) bytes DER encoded TimeStampReq] ^^^^^^ Regards Christian -- Christian Vogel office: [cvogel@iaik.at] [http://jcewww.iaik.tu-graz.ac.at] private: [bird@sbox.tu-graz.ac.at] [http://www.sbox.tu-graz.ac.at/home/b/bird] From owner-ietf-pkix@imc.org Tue Aug 22 08:58:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04133 for ; Tue, 22 Aug 2000 08:58:00 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA19289; Tue, 22 Aug 2000 05:52:20 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 22 Aug 2000 05:52:08 -0700 Received: from scog-ws3.gsa.gov (host.159-142-144-58.gsa.gov [159.142.144.58]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA19256 for ; Tue, 22 Aug 2000 05:52:07 -0700 (PDT) From: marion.royal@gsa.gov Received: from 159.142.144.55 by scog-ws3.gsa.gov with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Tue, 22 Aug 2000 08:52:41 -0400 X-Server-Uuid: cb2f616c-ae65-11d3-874c-00508b6362bc Subject: RE: President Clinton digital signing To: ietf-pkix@imc.org cc: terri.hobson@gsa.gov, judith.spencer@gsa.gov Date: Tue, 22 Aug 2000 08:51:53 -0400 Message-ID: X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on SCOG-NOTESSMTP1/GSAEXTERNAL(Release 5.0.1b|September 30, 1999) at 08/22/2000 08:52:41 AM MIME-Version: 1.0 X-WSS-ID: 15BCA81381806-01-01 Content-Type: multipart/mixed; boundary="0__=deIEy6O39naAtLpneVQ57XCireralUSeYXpikJYQoreaRqDaEaoO4T2Q" Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --0__=deIEy6O39naAtLpneVQ57XCireralUSeYXpikJYQoreaRqDaEaoO4T2Q Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Terri suggests that the real significance of the certificate and smart card used by President Clinton is that they were obtained through the Access Certificates for Electronic Services (ACES) contract at GSA. Through the use of a Certificate Arbitrator Module (CAM), which is effectively a parser and validation tool (offered to public domain by GSA), multiple CA's are made available to the government applications. More info at http://www.gsa.gov/aces/ To me, though, the most significant thing is that the E-Sign bill was signed, regardless of the technology utilized. Cheers, ---------------------- Forwarded by Marion A. Royal/ME/CO/GSA/GOV on 08/22/2000 08:23 AM --------------------------- (Embedded Terri F. Hobson image moved 08/22/2000 08:08 AM to file: (Embedded image moved to file: pic14454.pcx) pic17883.pcx) To: Marion A. Royal/ME/CO/GSA/GOV@GSA cc: Judith A. Spencer/TI/CO/GSA/GOV@GSA Subject: RE: President Clinton digital signing (Document link: Marion A. Royal) Marion, Looks like they missed the point! Clinton used an ACES certificate. Yes, under the ACES contract there are 3 primes and lots of subcontractors, including Verisign, Entrust, XCert, AOL, and Valicert just to name a few. However, reguardless of who, the standard x509v3 format as described in the ACES Certificate Policy was used. see ya! Marion A. Royal 08/22/2000 07:44 AM To: Terri Hobson, Judy Spencer cc: Subject: RE: President Clinton digital signing I would be happy to forward any comments you might have on this subject. This is the IETF PKIX work group. marion ---------------------- Forwarded by Marion A. Royal/ME/CO/GSA/GOV on 08/22/2000 07:42 AM --------------------------- "Yuriy Dzambasow" on 08/21/2000 01:06:34 PM Please respond to yuriy.dzambasow@digsigtrust.com To: "Alan Gibson" , "Timothy Fisher" , "Tom Strickland" cc: ietf-pkix@imc.org Subject: RE: President Clinton digital signing DST uses a variety of CA technologies in our managed services offerings, and are not solely reliant on any one technology. Yuriy -----Original Message----- From: Alan Gibson [mailto:agibson@adelphia.net] Sent: Monday, August 21, 2000 9:06 AM To: Timothy Fisher; Tom Strickland Cc: ietf-pkix@imc.org Subject: Re: President Clinton digital signing Yes ----- Original Message ----- From: "Timothy Fisher" To: "Tom Strickland" Cc: Sent: Sunday, August 20, 2000 12:41 PM Subject: Re: President Clinton digital signing > Does't DST also use Entrust software? > > Timothy Fisher > > Tom Strickland wrote: > > > Hello All, > > > > After reading several articles about President Clinton and the digital > > signature signing, it appears that people have an inaccurate impression > > regarding the PKI technology utilized. > > > > The actual smart card was produced by DataKey but the certs were > > provided by Digital Signature Trust (DST) which is based on the CA > > software designed and built by Xcert International. --0__=deIEy6O39naAtLpneVQ57XCireralUSeYXpikJYQoreaRqDaEaoO4T2Q Content-Type: application/octet-stream; name=pic17883.pcx Content-Disposition: attachment; filename=pic17883.pcx Content-Description: Paintbrush Content-Transfer-Encoding: base64 CgUBCAAAAAArABoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABLAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADID9MAyQAAxA/CDw/JD9IAyQDFD8IPD8oP0gDHAMUPww8Pyw/RAMYAxg/D Dw/MD9EAxADGD8MPwg/NDdAAwwDHDcMNwg3OD9AAAMcPxA/CD88PzwDID8QPwg/DD80NzQDIDcQN wg8P0Q/LAMkPxA/CDw/SD8kAyQ/FD8IPD8YPzQ3HAMoNwg3ED8IP1A/FAMoPxQ/DDw/VD8MAyw/F D8MPD8kPzQ0Ayw0NxQ/DDw/XD8sPxg/DDw/XD8sPxg/DDw/MD9ENww3HD8MPwg/XD8sPxg/DDw/X D8sPxg/DDw/PD84NyA/ED8IPD9cPyw/GD8MPD9cPyw/GD8MPD9IPyA3KD8UPwg8P1w/LD8YPww8P 1w/LD8YPww8P1Q/CDcsPxg/DDw8MAAAAgAAAAIAAgIAAAACAgACAAICAgICAwMDA/wAAAP8A//8A AAD//wD/AP//////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --0__=deIEy6O39naAtLpneVQ57XCireralUSeYXpikJYQoreaRqDaEaoO4T2Q Content-Type: application/octet-stream; name=pic14454.pcx Content-Disposition: attachment; filename=pic14454.pcx Content-Description: Paintbrush Content-Transfer-Encoding: base64 CgUBCAAAAABSAQkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABUwEBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD/D/8P/w//D+wP1g/LD8YPww8Pwg/DBcgPwwXID8MFyA/DBcgPwwXID8MF yA/DBcgPwwXID8MFyA/DBcgPwwXID8MFyA/DBcgPwwXID8MFyA/DBcgPwwXID8MFyA/DBcgPwwXI D8MFyA/DBcgPwwXID8MFyA/DBcgPwwXID8MFyA/DBcgPwwXID8MFyA/DBcMPDw/FBcYPxQXGD8UF xg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXG D8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcIP Dw/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXG D8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYP xQXGD8UFxg/FBcIPDw/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXG D8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYP xQXGD8UFxg/FBcYPxQXGD8UFxg/FBcIPD8IPwwXID8MFyA/DBcgPwwXID8MFyA/DBcgPwwXID8MF yA/DBcgPwwXID8MFyA/DBcgPwwXID8MFyA/DBcgPwwXID8MFyA/DBcgPwwXID8MFyA/DBcgPwwXI D8MFyA/DBcgPwwXID8MFyA/DBcgPwwXID8MFyA/DBcgPwwXDDw//D/8P/w//D+wP1g/LD8YPww8P /w//D/8P/w/sD9YPyw/GD8MPD/8P/w//D/8P7A/WD8sPxg/DDw//D/8P/w//D+wP1g/LD8YPww8P DAAAAIAAAACAAICAAAAAgIAAgACAgMDAwICAgP8AAAD/AP//AAAA//8A/wD//////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --0__=deIEy6O39naAtLpneVQ57XCireralUSeYXpikJYQoreaRqDaEaoO4T2Q-- From owner-ietf-pkix@imc.org Tue Aug 22 11:18:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08211 for ; Tue, 22 Aug 2000 11:18:37 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA28040; Tue, 22 Aug 2000 08:17:36 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 22 Aug 2000 08:16:17 -0700 Received: from mtk-mail1.mitretek.org (mtk-mail1.mitretek.org [206.241.50.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27997 for ; Tue, 22 Aug 2000 08:16:16 -0700 (PDT) Received: from mail1.mitretek.org (mail1.mitretek.org [206.241.49.31]) by mtk-mail1.mitretek.org (8.9.3/8.9.3) with ESMTP id LAA29728; Tue, 22 Aug 2000 11:15:56 -0400 (EDT) Received: from mitretek.org ([206.241.162.220]) by mail1.mitretek.org (Lotus Domino Release 5.0.4) with ESMTP id 2000082211155650:39892 ; Tue, 22 Aug 2000 11:15:56 -0400 Message-ID: <39A298EA.FF97772@mitretek.org> Date: Tue, 22 Aug 2000 11:14:50 -0400 From: Scott Barman X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Geer CC: ietf-pkix@imc.org Subject: Re: President Clinton digital signing References: <200008200316.XAA17065@world.std.com> X-MIMETrack: Itemize by SMTP Server on Mail1/Mitretek Systems(Release 5.0.4 |June 8, 2000) at 08/22/2000 11:15:57 AM, Serialize by Router on Mail1/Mitretek Systems(Release 5.0.4 |June 8, 2000) at 08/22/2000 11:15:57 AM, Serialize complete at 08/22/2000 11:15:57 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Dan Geer wrote: > > > After reading several articles about President Clinton and the > > digital signature signing, it appears that people have an > > inaccurate impression regarding the PKI technology utilized. > > > > The actual smart card was produced by DataKey but the certs were > > provided by Digital Signature Trust (DST) which is based on the CA > > software designed and built by Xcert International. > > I would be interested to know how this selection was made. > > --dan See http://www.gsa.gov/aces From owner-ietf-pkix@imc.org Tue Aug 22 11:23:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08365 for ; Tue, 22 Aug 2000 11:23:43 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA28327; Tue, 22 Aug 2000 08:23:04 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 22 Aug 2000 08:23:03 -0700 Received: from c014.sfo.cp.net (c014-h017.c014.sfo.cp.net [209.228.12.81]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA28297 for ; Tue, 22 Aug 2000 08:23:02 -0700 (PDT) Received: (cpmta 23253 invoked from network); 22 Aug 2000 08:22:53 -0700 Received: from 3ff8359b.dsl.flashcom.net (HELO concord) (63.248.53.155) by smtp.flashcom.net with SMTP; 22 Aug 2000 08:22:53 -0700 X-Sent: 22 Aug 2000 15:22:53 GMT Reply-To: From: Sender: "Jeff Spinney" To: , Cc: , , Subject: RE: President Clinton digital signing Date: Tue, 22 Aug 2000 11:19:12 -0400 Message-ID: <008501c00c4c$53f42190$6501010a@jeffshouse.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit this is very interexting, can somebody please comment on why the US govt (GSA, at least) doesnt seem to want to embrace OCSP as a validation mechanism for ACES (and other programs)?? the 'CAM' as they call it sems to be an alternative mechanism....a duplication of much of the work OCSP has already worked through... -j -----Original Message----- From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] Sent: Tuesday, August 22, 2000 8:52 AM To: ietf-pkix@imc.org Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov Subject: RE: President Clinton digital signing Terri suggests that the real significance of the certificate and smart card used by President Clinton is that they were obtained through the Access Certificates for Electronic Services (ACES) contract at GSA. Through the use of a Certificate Arbitrator Module (CAM), which is effectively a parser and validation tool (offered to public domain by GSA), multiple CA's are made available to the government applications. More info at http://www.gsa.gov/aces/ To me, though, the most significant thing is that the E-Sign bill was signed, regardless of the technology utilized. Cheers, From owner-ietf-pkix@imc.org Tue Aug 22 11:25:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08420 for ; Tue, 22 Aug 2000 11:25:47 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA28560; Tue, 22 Aug 2000 08:24:55 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 22 Aug 2000 08:24:53 -0700 Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28530 for ; Tue, 22 Aug 2000 08:24:52 -0700 (PDT) Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id LAA29273; Tue, 22 Aug 2000 11:25:12 -0400 (EDT) Message-Id: <4.2.0.58.20000822105705.00cf7c00@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 22 Aug 2000 11:24:05 -0400 To: ietf-pkix@imc.org From: Tim Polk Subject: Re: excluding all names of given type Cc: Sharon Boeyen In-Reply-To: <39A179EC.24015.5CF9C00@localhost> References: <4.2.0.58.20000817130750.00c43200@email.nist.gov> <14748.311.613517.443300@east.sun.com> Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: quoted-printable
Folks,

I believe we have achieved consensus, and that Anne's original proposal should be incorporated into son-of-2459.  We have heard from Anne Anderson, John Wray, and David Chadwick on the list.  I also spoke to Sharon Boeyen on the phone.  Everyone agrees with David=20 that
"The null name *is* the name of the root of the DIT"
so we should use the null name in excludedSubtrees to exclude all names of type distinguished name (i.e, in the subject or directoryName in subjectAltName.)

John pointed out that
"An empty subject DN in a certificate doesn't  mean that the certificate applies to a principal whose DN is the root of  the DIT, rather that the principal in question has no DN. This is a special case, called out explicitly in the PKIX profile. A certificate=20
with an empty DN should be permitted regardless of any DN name constraints.So I don't think this requires that you set the minimum value to 1 - 0 should do just fine."

This means we do not have to change the specification with respect to minimum and maximum.

Anyway, I will draft some proposed text and forward it to the list in the next day or so...

Thanks!

Tim


At 06:50 PM 8/21/00 +0100, David Chadwick wrote:
Date sent:              Thu, 17 Aug 2000 13:55:59 -0400
To:                     Anne Anderson <Anne.Anderson@east.sun.com>, ietf-pkix@imc.org
From:                   Tim Polk <wpolk@nist.gov>
Subject:                Re: excluding all names of given type
Copies to:              Sharon Boeyen <sharon.boeyen@entrust.com>

Anne, I think I would state this in reverse. CASE: NameConstraints *includedSubtrees* contains a directoryName where the RDNSequence is NULL

has the

SEMANTICS: The Subject field and the directoryName field of the SubjectAlternativeName (if it appears at all) may only contain names in the subtree NULL for all successive certificates in the path.


The only name in the subtree NULL would be the exact match - the NULL value. That would work, since we require a NULL RDNSequence if the Subject is omitted. As Steve has pointed out, this should only occur in an end entity certificate.



Tim

I do not agree with your semantics. The null name is the name of the root of the DIT, and therefore implies ALL subordinate names. Since a DIT subtree can comprise a single entry or any number of entries up to the whole DIT, then a null name implies a subtree of the whole DIT. Thus include NULL implies include any directory name at all - not a particularly usefull extension to include in a certificate.

David

This is not particularly straightforward, I know. We are using the include feature to exclude names! However, it works *if* you consider the only name in the subtree NULL is NULL itself. On the other hand, you could consider NULL the implicit root of all subtrees, the correct answer is excludedSubtrees is NULL with a minimum value of 1. (We would need to set the minimum to 1 so that NULL itself was not excluded.) This would force us to use (and process) the minimum value. RFC 2459 states that the minimum and maximum never are used, so minimum is always zero. I prefer the *includedSubtrees* solution. The truth is, of course, as long as we pick one way and state it clearly we should be fine. I don't think the X.5xx specifications cover this issue, but I've been wrong before on that point! Sharon, do you know if this topic has been addressed anywhere before?? Our first consideration should be conformance to X.509 etc if a clear solution has been established. If this has not been addressed, we should sort it out ASAP. Thanks, Tim At 11:13 AM 8/17/00 -0400, Anne Anderson wrote:

CASE: NameConstraints excludedSubtrees contains a directoryName where the RDNSequence is null SEMANTICS: Does this mean that the subsequent path may contain no names of type directoryName in either Subject or the SubjectAlternativeNames? Is there a better way to achieve these semantics? Anne -- Anne H. Anderson Email: aha@acm.org Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692


***************************************************=20

David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel
+44 161 295 5351  Fax +44 161 745 8169 Mobile +44 790 167 0359 Email
D.W.Chadwick@salford.ac.uk Home Page 
http://www.salford.=
ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/=
its024/X500.htm X.500/LDAP Seminars http://www.salford.ac=
.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J=20

***************************************************=20

</blockquote></x-html>
From owner-ietf-pkix@imc.org Tue Aug 22 11:46:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09039 for ; Tue, 22 Aug 2000 11:46:13 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA00547; Tue, 22 Aug 2000 08:44:50 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 22 Aug 2000 08:44:47 -0700 Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA00512 for ; Tue, 22 Aug 2000 08:44:47 -0700 (PDT) Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id LAA18372; Tue, 22 Aug 2000 11:45:04 -0400 (EDT) Message-Id: <4.2.0.58.20000822113227.00cfeb60@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 22 Aug 2000 11:44:01 -0400 To: , , From: Tim Polk Subject: RE: President Clinton digital signing Cc: , , In-Reply-To: <008501c00c4c$53f42190$6501010a@jeffshouse.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe If the ACES project was starting today, they might very well have used OCSP. However, the ACES project was years in the making. No standard solution was available, and GSA could not afford to wait. Remember, OCSP didn't make it out of the editing queue until June 1999. GSA was well into the contracting process before OCSP was stable enough to consider. Considering the legal and contracting issues, GSA has done an amazing job bringing ACES on line. Hopefully, ACES will evolve to take advantage of the IETF protocols in the future. Tim At 11:19 AM 8/22/00 -0400, jspinney@securify.com wrote: >this is very interexting, can somebody please comment on why the US govt >(GSA, at least) doesnt seem to want to embrace OCSP as a validation >mechanism for ACES (and other programs)?? the 'CAM' as they call it sems >to be an alternative mechanism....a duplication of much of the work OCSP has >already worked through... > >-j > >-----Original Message----- >From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] >Sent: Tuesday, August 22, 2000 8:52 AM >To: ietf-pkix@imc.org >Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov >Subject: RE: President Clinton digital signing > > >Terri suggests that the real significance of the certificate and smart card >used by President Clinton is that they were obtained through the Access >Certificates for Electronic Services (ACES) contract at GSA. Through the >use of a Certificate Arbitrator Module (CAM), which is effectively a parser >and validation tool (offered to public domain by GSA), multiple CA's are >made available to the government applications. > >More info at > >http://www.gsa.gov/aces/ > >To me, though, the most significant thing is that the E-Sign bill was >signed, regardless of the technology utilized. > >Cheers, From owner-ietf-pkix@imc.org Tue Aug 22 11:58:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09283 for ; Tue, 22 Aug 2000 11:58:28 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA02229; Tue, 22 Aug 2000 08:57:46 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 22 Aug 2000 08:57:43 -0700 Received: from scog-ws3.gsa.gov (host.159-142-144-58.gsa.gov [159.142.144.58]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA02193 for ; Tue, 22 Aug 2000 08:57:42 -0700 (PDT) From: judith.spencer@gsa.gov Received: from 159.142.144.55 by scog-ws3.gsa.gov with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Tue, 22 Aug 2000 11:58:18 -0400 X-Server-Uuid: cb2f616c-ae65-11d3-874c-00508b6362bc Subject: RE: President Clinton digital signing To: spinneyj@flashcom.net cc: marion.royal@gsa.gov, ietf-pkix@imc.org, terri.hobson@gsa.gov, judith.spencer@gsa.gov, rsalz@caveosystems.com, stanley.choffrey@gsa.gov Sender: judith.spencer@gsa.gov Date: Tue, 22 Aug 2000 11:58:07 -0400 Message-ID: X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on SCOG-NOTESSMTP1/GSAEXTERNAL(Release 5.0.1b|September 30, 1999) at 08/22/2000 11:58:18 AM MIME-Version: 1.0 X-WSS-ID: 15BC7C90141665-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit GSA has no reluctance to embracing OCSP, and is moving in that direction. However, when CAM development was begun OCSP was not yet a standard. We held several industry forums and asked the attendees whether we should ascribe to OCSP or develop something generic. The unanimous response was to do something generic, since they did not want to be tied to a specific solution. We listened. Since then OCSP became a standard, and now, of course, there has been an about-face on everyone's opinion. The CAM will embrace OCSP in its future development. Thanks Judy Spencer jspinney@securify.com@flashcom.net> on 08/22/2000 11:19:12 AM Please respond to spinneyj@flashcom.net Sent by: "Jeff Spinney" To: marion.royal@gsa.gov, ietf-pkix@imc.org cc: terri.hobson@gsa.gov, judith.spencer@gsa.gov, rsalz@caveosystems.com Subject: RE: President Clinton digital signing this is very interexting, can somebody please comment on why the US govt (GSA, at least) doesnt seem to want to embrace OCSP as a validation mechanism for ACES (and other programs)?? the 'CAM' as they call it sems to be an alternative mechanism....a duplication of much of the work OCSP has already worked through... -j -----Original Message----- From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] Sent: Tuesday, August 22, 2000 8:52 AM To: ietf-pkix@imc.org Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov Subject: RE: President Clinton digital signing Terri suggests that the real significance of the certificate and smart card used by President Clinton is that they were obtained through the Access Certificates for Electronic Services (ACES) contract at GSA. Through the use of a Certificate Arbitrator Module (CAM), which is effectively a parser and validation tool (offered to public domain by GSA), multiple CA's are made available to the government applications. More info at http://www.gsa.gov/aces/ To me, though, the most significant thing is that the E-Sign bill was signed, regardless of the technology utilized. Cheers, From owner-ietf-pkix@imc.org Tue Aug 22 12:14:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09860 for ; Tue, 22 Aug 2000 12:14:43 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA03637; Tue, 22 Aug 2000 09:14:01 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 22 Aug 2000 09:13:58 -0700 Received: from crack.x509.com (root@crack.x509.com [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03606 for ; Tue, 22 Aug 2000 09:13:57 -0700 (PDT) Received: from xcert.com (home.x509.com [199.175.150.4]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e7MGEGS10919; Tue, 22 Aug 2000 09:14:16 -0700 (PDT) Message-ID: <39A2A7B0.BA4A8EF0@xcert.com> Date: Tue, 22 Aug 2000 12:17:52 -0400 From: Tom Strickland X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: spinneyj@flashcom.net, "ietf-pkix@imc.org" Subject: Re: President Clinton digital signing References: <008501c00c4c$53f42190$6501010a@jeffshouse.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDB0DAD23CD019D3A969F9422" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a cryptographically signed message in MIME format. --------------msDB0DAD23CD019D3A969F9422 Content-Type: multipart/mixed; boundary="------------C0DBA348AF658542728DE7AB" This is a multi-part message in MIME format. --------------C0DBA348AF658542728DE7AB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit You are correct to ask "why the US govt (GSA, at least) dosent seem to want to embrace OCSP as a validation mechanism for ACES (and other programs)??". You have to remember that ACES does have built in OCSP. The product that they chose includes an OCSP "real time" responder, not antiquated CRLs. Please review the following URLs to see how and why Xcert was chosen: ACES announcement: http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html Reference to digital signature law: http://www.xcert.com/resources/esign/index.html Sentry CA functionality: http://www.xcert.com/software/sentryca.html Scalability to manage over 8 million certs on one CA and box: http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html jspinney@securify.com wrote: > this is very interexting, can somebody please comment on why the US govt > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > mechanism for ACES (and other programs)?? the 'CAM' as they call it sems > to be an alternative mechanism....a duplication of much of the work OCSP has > already worked through... > > -j > > -----Original Message----- > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > Sent: Tuesday, August 22, 2000 8:52 AM > To: ietf-pkix@imc.org > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > Subject: RE: President Clinton digital signing > > Terri suggests that the real significance of the certificate and smart card > used by President Clinton is that they were obtained through the Access > Certificates for Electronic Services (ACES) contract at GSA. Through the > use of a Certificate Arbitrator Module (CAM), which is effectively a parser > and validation tool (offered to public domain by GSA), multiple CA's are > made available to the government applications. > > More info at > > http://www.gsa.gov/aces/ > > To me, though, the most significant thing is that the E-Sign bill was > signed, regardless of the technology utilized. > > Cheers, --------------C0DBA348AF658542728DE7AB Content-Type: text/x-vcard; charset=us-ascii; name="tstrickland.vcf" Content-Description: Card for Tom Strickland Content-Disposition: attachment; filename="tstrickland.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Strickland;Tom tel;cell:678 296-4866 x-mozilla-html:TRUE org:
Xcert International Inc. adr:;;;;;; version:2.1 email;internet:tstrickland@xcert.com fn:Tom Strickland end:vcard --------------C0DBA348AF658542728DE7AB-- --------------msDB0DAD23CD019D3A969F9422 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIEtQYJKoZIhvcNAQcCoIIEpjCCBKICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Aq0wggKpMIICEgIRAMevlgMAAAJ8AAAARgAAABswDQYJKoZIhvcNAQEEBQAwYTEcMBoGA1UE ChMTWGNlcnQgU29mdHdhcmUgSW5jLjEfMB0GA1UECxMWSW50ZXJuYWwgUmVwb3NpdG9yeSBD QTEgMB4GCSqGSIb3DQEJARYRc3VwcG9ydEB4Y2VydC5jb20wHhcNMDAwMjAzMTgyMTM1WhcN MzcxMjE2MTgyMTM1WjCByDELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0dlb3JnaWExEzARBgNV BAcTCkFscGhhcmV0dGExITAfBgNVBAoTGFhjZXJ0IEludGVybmF0aW9uYWwgSW5jLjETMBEG A1UECxMKd2FzaGluZ3RvbjEXMBUGA1UEAxMOVG9tIFN0cmlja2xhbmQxJDAiBgkqhkiG9w0B CQEWFXRzdHJpY2tsYW5kQHhjZXJ0LmNvbTEbMBkGCgmSJomT8ixkAQETC3RzdHJpY2tsYW5k MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDIpwUFKnmwbvpjbD8fYi9jrLDQdaZoHG2 qBXH3P+pBThxsfwx/FoFalPxo3LeM1lHaSu1sC+jhu9AT5U+3qJ0WCWF1uVabV1aTH6XKKgv rX3fGOruVzRm3YXVE1yEF0uQfUSzb+hPBXy2RCj2gX4swrjhl1NkaPVXUS+r/CbFiQIDAQAB MA0GCSqGSIb3DQEBBAUAA4GBAIxBn4Hwr5I8BJeub2feuRCyfXKQeKAXqKD9sboeFnlGTTEA xoEpmUI1rYwG6CzVQnmut+/1FUpWixRx/g/gQYnu5EQa1/0yKEvo9SPbhq48ksadKzEVYdTP 0ICWEaj68mgJDVfCBETAjZlUC4r/gLz94xW5R6JsluP56aJV5a1hMYIB0DCCAcwCAQEwdjBh MRwwGgYDVQQKExNYY2VydCBTb2Z0d2FyZSBJbmMuMR8wHQYDVQQLExZJbnRlcm5hbCBSZXBv c2l0b3J5IENBMSAwHgYJKoZIhvcNAQkBFhFzdXBwb3J0QHhjZXJ0LmNvbQIRAMevlgMAAAJ8 AAAARgAAABswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDA4MjIxNjE3NTJaMCMGCSqGSIb3DQEJBDEWBBQXudqUXJ9HgWTgYslD X7RPl2fL5DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gAEWT2EEYrIc6n0VT3x5PFSeIWuhsY2iEoJIdgQpigwqSznqlK61bJdh7ikuxyOMyzzc1foY LYSeWO17btcNjYhstgrGVUUz8C04HfHuCmhlg8BCjLXrMAFZN7IqP7V8xNtRIC8xbrXiuvPI 0xPkoKIdLIxFXigN4PhDpqDP+rtS --------------msDB0DAD23CD019D3A969F9422-- From owner-ietf-pkix@imc.org Tue Aug 22 13:27:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11382 for ; Tue, 22 Aug 2000 13:27:01 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA07078; Tue, 22 Aug 2000 10:25:50 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 22 Aug 2000 10:25:26 -0700 Received: from cnbskpt2.cnbs.navy.mil (cnbskpt2.cnbs.navy.mil [164.221.184.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07007 for ; Tue, 22 Aug 2000 10:25:25 -0700 (PDT) Received: by cnbskpt2.cnbs.navy.mil with Internet Mail Service (5.5.2650.21) id ; Tue, 22 Aug 2000 10:21:22 -0700 Message-ID: <07278C38CF83D21181B200105AA34A859DD4FF@cnbskpt2.cnbs.navy.mil> From: "Morrill, Dan" To: "'Tom Strickland'" , spinneyj@flashcom.net, ietf-pkix@imc.org Subject: RE: President Clinton digital signing Date: Tue, 22 Aug 2000 10:21:16 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe For specific information about the CAM and its status, please check out http://cam.fts.gsa.gov/ Cheers, r/ Dan -----Original Message----- From: Tom Strickland [mailto:tstrickland@xcert.com] Sent: Tuesday, August 22, 2000 09:18 AM To: spinneyj@flashcom.net; ietf-pkix@imc.org Subject: Re: President Clinton digital signing You are correct to ask "why the US govt (GSA, at least) dosent seem to want to embrace OCSP as a validation mechanism for ACES (and other programs)??". You have to remember that ACES does have built in OCSP. The product that they chose includes an OCSP "real time" responder, not antiquated CRLs. Please review the following URLs to see how and why Xcert was chosen: ACES announcement: http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html Reference to digital signature law: http://www.xcert.com/resources/esign/index.html Sentry CA functionality: http://www.xcert.com/software/sentryca.html Scalability to manage over 8 million certs on one CA and box: http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html jspinney@securify.com wrote: > this is very interexting, can somebody please comment on why the US govt > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > mechanism for ACES (and other programs)?? the 'CAM' as they call it sems > to be an alternative mechanism....a duplication of much of the work OCSP has > already worked through... > > -j > > -----Original Message----- > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > Sent: Tuesday, August 22, 2000 8:52 AM > To: ietf-pkix@imc.org > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > Subject: RE: President Clinton digital signing > > Terri suggests that the real significance of the certificate and smart card > used by President Clinton is that they were obtained through the Access > Certificates for Electronic Services (ACES) contract at GSA. Through the > use of a Certificate Arbitrator Module (CAM), which is effectively a parser > and validation tool (offered to public domain by GSA), multiple CA's are > made available to the government applications. > > More info at > > http://www.gsa.gov/aces/ > > To me, though, the most significant thing is that the E-Sign bill was > signed, regardless of the technology utilized. > > Cheers, From owner-ietf-pkix@imc.org Tue Aug 22 13:51:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11901 for ; Tue, 22 Aug 2000 13:51:28 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA09001; Tue, 22 Aug 2000 10:50:43 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 22 Aug 2000 10:50:41 -0700 Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08968 for ; Tue, 22 Aug 2000 10:50:40 -0700 (PDT) Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id KAA10349; Tue, 22 Aug 2000 10:47:03 -0700 (PDT) Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id ; Tue, 22 Aug 2000 10:49:17 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4F93A91@vhqpostal.verisign.com> From: Michael Myers To: Sam Schaen , "'ietf-pkix@imc.org'" Subject: OCSP edits Date: Tue, 22 Aug 2000 10:49:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Sam, all: I'm currently accumulating edits to RFC 2560's syntax and semantics for the WG's consideration and hope to have a draft revision out by 15 Sept. I agree with Sam Schaen that it's important to reinforce that an OCSP responder have the most current revocation information. While assumed, this in not as apparent in the Proposed Standard as it should be. I'll fold into the delta Sam's recommended text as we move 2560 forward. This delta will include, among other edits, the module specification I received from Russ in Adelaide. Mike From owner-ietf-pkix@imc.org Tue Aug 22 15:04:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13420 for ; Tue, 22 Aug 2000 15:04:01 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA11662; Tue, 22 Aug 2000 12:00:52 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 22 Aug 2000 12:00:43 -0700 Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11632 for ; Tue, 22 Aug 2000 12:00:42 -0700 (PDT) Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000822190103.EQDO4590.mail.rdc1.md.home.com@home.com>; Tue, 22 Aug 2000 12:01:03 -0700 Message-ID: <39A2CDC7.4800F20@home.com> Date: Tue, 22 Aug 2000 15:00:23 -0400 From: Al Arsenault Organization: @Home Network X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Strickland CC: spinneyj@flashcom.net, "ietf-pkix@imc.org" , judith.spencer@gsa.gov, yuriy.dzambasow@digsigtrust.com Subject: Re: President Clinton digital signing References: <008501c00c4c$53f42190$6501010a@jeffshouse.net> <39A2A7B0.BA4A8EF0@xcert.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Tom Strickland wrote: > > Please review the following URLs to see how and why Xcert was chosen: > > That's all fine and dandy, but I thought that the question was: "Why was a DST/XCert certificate selected for use, vice something from one of the other ACES contractors?" Since IIRC DST had the first ACES contract, I can certainly see giving them this task. But was there any special reason DST chose XCert, since DST provides certificates using most if not all of the major CA providers' equipments? Al Arsenault Chief Security Architect Diversinet Corp. From owner-ietf-pkix@imc.org Tue Aug 22 21:09:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18438 for ; Tue, 22 Aug 2000 21:09:22 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA19102; Tue, 22 Aug 2000 18:08:33 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 22 Aug 2000 18:08:15 -0700 Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19052 for ; Tue, 22 Aug 2000 18:08:14 -0700 (PDT) Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id SAA03085; Tue, 22 Aug 2000 18:05:23 -0700 (PDT) Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id ; Tue, 22 Aug 2000 18:07:36 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EBE7@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'marion.royal@gsa.gov'" , ietf-pkix@imc.org Cc: terri.hobson@gsa.gov, judith.spencer@gsa.gov Subject: RE: President Clinton digital signing Date: Tue, 22 Aug 2000 18:07:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_0009_01C00C7D.2D1EC350"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C00C7D.2D1EC350 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > To me, though, the most significant thing is that the E-Sign bill was > signed, regardless of the technology utilized. And it was totally illogical to use a digital signature for the purpose. The act is now effectively a self-signed cert! The validity of the authentication on the act is established through a circular reference to the act itself. Phill ------=_NextPart_000_0009_01C00C7D.2D1EC350 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINaDCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEFDCCA32gAwIBAgIQ AxTuqrYcesW8jpUyudZ0/DANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNOTkxMjIwMDAwMDAwWhcNMDAx MjE5MjM1OTU5WjBsMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNTAzBgNVBAMTLHBiYWtlciAoUGhpbGlwIEhhbGxhbS1CYWtlciwgVmVyaVNpZ24s IEluYy4pMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3f0kRIy2AU5cHhfnUwuHecFNq6dnf /wsvxS//4Nt8rFgr2KdvQETKaQ6wGl6mVijB6udZW9dUKVoE1lnu2MMcIhtAL3+Q2dsrxlrTInfq PKAdxu/Fvb4n3Y0RItW9zh1MzFWZ8Q9z6eF2HuBwG6ANfRzfJgironyftbbitRyaxQIDAQABo4IB dDCCAXAwCQYDVR0TBAIwADBVBgNVHR8ETjBMMEqgSKBGhkRodHRwOi8vb25zaXRlY3JsLnZlcmlz aWduLmNvbS9WZXJpU2lnbkluY0V4Y2hhbmdlRW1wbG95ZWVzL0xhdGVzdENSTDALBgNVHQ8EBAMC BaAwHgYDVR0RBBcwFYETcGJha2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgB hvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4g YnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeA MB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQAaUApBXCjc mPE5dFPHlQVl4n9WoOU7AE487xxC7vcR1MDhF8p/0GMu6zOyZe9CFVaOndaYCRgv69qKTVoANmsM F/eFsQn/HaoXEz+jHPNgWcPyBu3dujO9s2PLQbuBXE3rIaDiVyTftVgoNvO0fcknSlNOWxqHvbaH 9RYvhMghkjGCAvgwggL0AgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVy bXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVy aVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAJBgUrDgMCGgUAoIIB jDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDA4MjMwMTA4NTNa MCMGCSqGSIb3DQEJBDEWBBSOANK+0G2grL5vtgDvkXg3YlGlvzBYBgkqhkiG9w0BCQ8xSzBJMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjAKBggqhkiG9w0CBTCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEl MCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAN BgkqhkiG9w0BAQEFAASBgHbayQ5M3INMkvbrRjh2O3x1FPPI3AGCP8boETGBtHXLT42aqKJq0kjp /YFt+rHbxIlz89eQh8sQ2TxjAqNB6ip4o7Wg0R8VvPPqef4R5CEcHaLtW+HXWp8HqErwk6kBhTy8 X1WQyp61qnuaWvUS51oKFsU9c8bm5CdTeW+HfHXcAAAAAAAA ------=_NextPart_000_0009_01C00C7D.2D1EC350-- From owner-ietf-pkix@imc.org Tue Aug 22 21:35:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19559 for ; Tue, 22 Aug 2000 21:35:45 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA22293; Tue, 22 Aug 2000 18:35:01 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 22 Aug 2000 18:34:59 -0700 Received: from sina.com ([202.106.187.168]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA22263 for ; Tue, 22 Aug 2000 18:34:57 -0700 (PDT) Received: (qmail 10898 invoked by uid 99); 23 Aug 2000 01:36:46 -0000 Message-ID: <20000823013646.10897.qmail@sina.com> From: wangbingyan168 To: ietf-pkix@imc.org Date: Wed Aug 23 01:36:46 2000 X-Mailer: SinaMail 3.0Beta (FireToad) X-Priority: 3 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Who can tell me how can I join in the PKI(?PKIX) workgrop? Thanks a lot! ______________________________________ =================================================================== ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn ¾´Çë¹Ø×¢ 8ÔÂ27ÈÕ19µã45·Ö ºþÄÏÎÀÊÓ<õ¹åÖ®Ô¼> ÐÂÀË°ÂÔËÇéÂÂÌØʹ¾öÈü http://ad2.sina.com.cn/ads/olympics/ From owner-ietf-pkix@imc.org Tue Aug 22 21:37:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19575 for ; Tue, 22 Aug 2000 21:37:07 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA22519; Tue, 22 Aug 2000 18:36:20 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 22 Aug 2000 18:36:18 -0700 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA22488 for ; Tue, 22 Aug 2000 18:36:18 -0700 (PDT) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0FZQ007011T0DU@ext-mail.valicert.com> for ietf-pkix@imc.org; Tue, 22 Aug 2000 18:36:36 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0FZQ007BJ1T00X@ext-mail.valicert.com>; Tue, 22 Aug 2000 18:36:36 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Tue, 22 Aug 2000 18:26:31 -0700 Content-return: allowed Date: Tue, 22 Aug 2000 18:26:26 -0700 From: Ambarish Malpani Subject: RE: President Clinton digital signing To: "'Tom Strickland'" , spinneyj@flashcom.net, ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hi Tom, It really isn't that hard to set up quite a few of the CAs to create a new CRL whenever a new revocation happens. Think of this CRL as a snapshot of the CA's revocation database and the publishing of a new CRL as a trigger to tell the OCSP server that the snapshot has changed. Really, an OCSP server can be set up to be as current as any other software to provide revocation information, either with or without CRLs. It is completely unclear to me why the CAM solution is any more real time than OCSP. I believe the real reason for the CAM solution was just that OCSP didn't exist as a standard till late in the ACES project as indicated by the mails from both Judith and Tim. I have a suspicion that it still might be faster and cheaper for ACES to go with OCSP, rather than try to stick to a non-standard protocol. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Tom Strickland [mailto:tstrickland@xcert.com] > Sent: Tuesday, August 22, 2000 9:18 AM > To: spinneyj@flashcom.net; ietf-pkix@imc.org > Subject: Re: President Clinton digital signing > > > You are correct to ask "why the US govt (GSA, at least) > dosent seem to want to > embrace OCSP as a validation mechanism for ACES (and other > programs)??". > You have to remember that ACES does have built in OCSP. The > product that they > chose includes an OCSP "real time" responder, not antiquated CRLs. > > Please review the following URLs to see how and why Xcert was chosen: > > ACES announcement: > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > Reference to digital signature law: > http://www.xcert.com/resources/esign/index.html > > Sentry CA functionality: > http://www.xcert.com/software/sentryca.html > > Scalability to manage over 8 million certs on one CA and box: > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > jspinney@securify.com wrote: > > > this is very interexting, can somebody please comment on > why the US govt > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > mechanism for ACES (and other programs)?? the 'CAM' as > they call it sems > > to be an alternative mechanism....a duplication of much of > the work OCSP has > > already worked through... > > > > -j > > > > -----Original Message----- > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > Sent: Tuesday, August 22, 2000 8:52 AM > > To: ietf-pkix@imc.org > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > Subject: RE: President Clinton digital signing > > > > Terri suggests that the real significance of the > certificate and smart card > > used by President Clinton is that they were obtained > through the Access > > Certificates for Electronic Services (ACES) contract at > GSA. Through the > > use of a Certificate Arbitrator Module (CAM), which is > effectively a parser > > and validation tool (offered to public domain by GSA), > multiple CA's are > > made available to the government applications. > > > > More info at > > > > http://www.gsa.gov/aces/ > > > > To me, though, the most significant thing is that the > E-Sign bill was > > signed, regardless of the technology utilized. > > > > Cheers, > From owner-ietf-pkix@imc.org Wed Aug 23 00:08:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22468 for ; Wed, 23 Aug 2000 00:08:57 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA07705; Tue, 22 Aug 2000 21:08:09 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 22 Aug 2000 21:08:00 -0700 Received: from crack.x509.com (root@crack.x509.com [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA07656 for ; Tue, 22 Aug 2000 21:07:59 -0700 (PDT) Received: from xcert.com (home.x509.com [199.175.150.4]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e7N48KS24473; Tue, 22 Aug 2000 21:08:21 -0700 (PDT) Message-ID: <39A34EFD.2DE9A602@xcert.com> Date: Wed, 23 Aug 2000 00:11:41 -0400 From: Tom Strickland X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ambarish Malpani CC: spinneyj@flashcom.net, ietf-pkix@imc.org Subject: Re: President Clinton digital signing References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> Content-Type: multipart/mixed; boundary="------------0F6F7A326065ABAF0A48764C" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. --------------0F6F7A326065ABAF0A48764C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Ambarish, Thanks for your reply. I agree that OCSP services are by far better than CRLs. In general, as everyone knows, a CRL is a batch job that updates a database over certain intervals. From an audit standpoint, one of the many issues with CRLs is that they can be beat. For example, it is very easy to perform any series of denial of service attacks against the server. This could cause longer than expected delays in the execution of the batch job or worse, prevent the batch job from running causing latent (or corrupted) CRL publishing. Also, if someone is savvy enough, they could also issue hundreds of back to back CRL job requests resulting in multiple jobs waiting on shared services again causing problematic CRLs. I know this may sound farfetched but they are risks to be considered. As you may guess I am not a proponent of CRLs for obvious reasons. I have heard claims by some that their products are OCSP compliant. In reality it is just a batch job publishing to a database but still they have inherent CRL batch job latency. As for the CAM, I am not familiar enough with that to argue for or against its use. I do know however that the Xcert product has a non proprietary real time OCSP LDAP out of the box resulting in a more robust product. Note that the Sentry CA product can publish CRLs to non OCSP products to offer backwards compatibility when needed. Also, the Sentry product can import other vendors CRLs and place them in the real time OCSP LDAP. Also one of the several reasons that Sentry CA was chosen was due to its ability to cross certify against other CAs (cross certification). It is very easy to setup trust to another company's CA allowing multiple CAs or PKI vendors within a central Sentry OCSP environment. Best regards, Tom Ambarish Malpani wrote: > Hi Tom, > > It really isn't that hard to set up quite a few of the CAs to > create a new CRL whenever a new revocation happens. > > Think of this CRL as a snapshot of the CA's revocation database > and the publishing of a new CRL as a trigger to tell the OCSP > server that the snapshot has changed. > > Really, an OCSP server can be set up to be as current as any other > software to provide revocation information, either with or without > CRLs. > > It is completely unclear to me why the CAM solution is any > more real time than OCSP. I believe the real reason for the > CAM solution was just that OCSP didn't exist as a standard till > late in the ACES project as indicated by the mails from both > Judith and Tim. I have a suspicion that it still might be faster > and cheaper for ACES to go with OCSP, rather than try to stick to > a non-standard protocol. > > Regards, > Ambarish > > --------------------------------------------------------------------- > Ambarish Malpani > Architect 650.567.5457 > ValiCert, Inc. ambarish@valicert.com > 339 N. Bernardo Ave. http://www.valicert.com > Mountain View, CA 94043 > > > -----Original Message----- > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > Sent: Tuesday, August 22, 2000 9:18 AM > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > Subject: Re: President Clinton digital signing > > > > > > You are correct to ask "why the US govt (GSA, at least) > > dosent seem to want to > > embrace OCSP as a validation mechanism for ACES (and other > > programs)??". > > You have to remember that ACES does have built in OCSP. The > > product that they > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > Please review the following URLs to see how and why Xcert was chosen: > > > > ACES announcement: > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > Reference to digital signature law: > > http://www.xcert.com/resources/esign/index.html > > > > Sentry CA functionality: > > http://www.xcert.com/software/sentryca.html > > > > Scalability to manage over 8 million certs on one CA and box: > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > jspinney@securify.com wrote: > > > > > this is very interexting, can somebody please comment on > > why the US govt > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > mechanism for ACES (and other programs)?? the 'CAM' as > > they call it sems > > > to be an alternative mechanism....a duplication of much of > > the work OCSP has > > > already worked through... > > > > > > -j > > > > > > -----Original Message----- > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > To: ietf-pkix@imc.org > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > Subject: RE: President Clinton digital signing > > > > > > Terri suggests that the real significance of the > > certificate and smart card > > > used by President Clinton is that they were obtained > > through the Access > > > Certificates for Electronic Services (ACES) contract at > > GSA. Through the > > > use of a Certificate Arbitrator Module (CAM), which is > > effectively a parser > > > and validation tool (offered to public domain by GSA), > > multiple CA's are > > > made available to the government applications. > > > > > > More info at > > > > > > http://www.gsa.gov/aces/ > > > > > > To me, though, the most significant thing is that the > > E-Sign bill was > > > signed, regardless of the technology utilized. > > > > > > Cheers, > > --------------0F6F7A326065ABAF0A48764C Content-Type: text/x-vcard; charset=us-ascii; name="tstrickland.vcf" Content-Description: Card for Tom Strickland Content-Disposition: attachment; filename="tstrickland.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Strickland;Tom tel;cell:678 296-4866 x-mozilla-html:TRUE org:
Xcert International Inc. adr:;;;;;; version:2.1 email;internet:tstrickland@xcert.com fn:Tom Strickland end:vcard --------------0F6F7A326065ABAF0A48764C-- From owner-ietf-pkix@imc.org Wed Aug 23 04:42:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06391 for ; Wed, 23 Aug 2000 04:42:24 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA27517; Wed, 23 Aug 2000 01:41:47 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 01:41:38 -0700 Received: from tantalum (tantalum.btinternet.com [194.73.73.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA27482 for ; Wed, 23 Aug 2000 01:41:37 -0700 (PDT) Received: from [62.6.79.185] (helo=vaio) by tantalum with smtp (Exim 3.03 #83) id 13RW6i-0005qr-00 for ietf-pkix@imc.org; Wed, 23 Aug 2000 09:42:00 +0100 Message-ID: <001c01c00cde$64c6d840$68bc01d5@vaio> Reply-To: "Liaquat Khan" From: "Liaquat Khan" To: References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> Subject: Re: President Clinton digital signing Date: Wed, 23 Aug 2000 09:44:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit You have to assume that access to the server which issues CRLs is protected from denial of service attacks. For example, generally only trusted operators can authorise the generation of CRLs, after having their identities authenticated by the server. Also access to the CRL issuer has to be protected through firewalls, etc. If an attacker can perform a DoS attack on a CRL issuer, what is there to stop him/her launching a similar attack on an OCSP server (e.g. by issuing an extremely large amount of OCSP requests)? Regards, Liaquat Khan Technical Manager Global Trust Authority (GTA) ----- Original Message ----- From: Tom Strickland To: Ambarish Malpani Cc: ; Sent: Wednesday, August 23, 2000 5:11 AM Subject: Re: President Clinton digital signing > Hello Ambarish, > > Thanks for your reply. I agree that OCSP services are by far better than > CRLs. In general, as everyone knows, a CRL is a batch job that updates a > database over certain intervals. From an audit standpoint, one of the many > issues with CRLs is that they can be beat. For example, it is very easy to > perform any series of denial of service attacks against the server. This > could cause longer than expected delays in the execution of the batch job > or worse, prevent the batch job from running causing latent (or corrupted) > CRL publishing. Also, if someone is savvy enough, they could also issue > hundreds of back to back CRL job requests resulting in multiple jobs > waiting on shared services again causing problematic CRLs. I know this may > sound farfetched but they are risks to be considered. > > As you may guess I am not a proponent of CRLs for obvious reasons. I have > heard claims by some that their products are OCSP compliant. In reality it > is just a batch job publishing to a database but still they have inherent > CRL batch job latency. > > As for the CAM, I am not familiar enough with that to argue for or against > its use. I do know however that the Xcert product has a non proprietary > real time OCSP LDAP out of the box resulting in a more robust product. Note > that the Sentry CA product can publish CRLs to non OCSP products to offer > backwards compatibility when needed. Also, the Sentry product can import > other vendors CRLs and place them in the real time OCSP LDAP. > > Also one of the several reasons that Sentry CA was chosen was due to its > ability to cross certify against other CAs (cross certification). It is > very easy to setup trust to another company's CA allowing multiple CAs or > PKI vendors within a central Sentry OCSP environment. > > Best regards, > > Tom > > > Ambarish Malpani wrote: > > > Hi Tom, > > > > It really isn't that hard to set up quite a few of the CAs to > > create a new CRL whenever a new revocation happens. > > > > Think of this CRL as a snapshot of the CA's revocation database > > and the publishing of a new CRL as a trigger to tell the OCSP > > server that the snapshot has changed. > > > > Really, an OCSP server can be set up to be as current as any other > > software to provide revocation information, either with or without > > CRLs. > > > > It is completely unclear to me why the CAM solution is any > > more real time than OCSP. I believe the real reason for the > > CAM solution was just that OCSP didn't exist as a standard till > > late in the ACES project as indicated by the mails from both > > Judith and Tim. I have a suspicion that it still might be faster > > and cheaper for ACES to go with OCSP, rather than try to stick to > > a non-standard protocol. > > > > Regards, > > Ambarish > > > > --------------------------------------------------------------------- > > Ambarish Malpani > > Architect 650.567.5457 > > ValiCert, Inc. ambarish@valicert.com > > 339 N. Bernardo Ave. http://www.valicert.com > > Mountain View, CA 94043 > > > > > -----Original Message----- > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > Subject: Re: President Clinton digital signing > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > dosent seem to want to > > > embrace OCSP as a validation mechanism for ACES (and other > > > programs)??". > > > You have to remember that ACES does have built in OCSP. The > > > product that they > > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > > > Please review the following URLs to see how and why Xcert was chosen: > > > > > > ACES announcement: > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > Reference to digital signature law: > > > http://www.xcert.com/resources/esign/index.html > > > > > > Sentry CA functionality: > > > http://www.xcert.com/software/sentryca.html > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > this is very interexting, can somebody please comment on > > > why the US govt > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > they call it sems > > > > to be an alternative mechanism....a duplication of much of > > > the work OCSP has > > > > already worked through... > > > > > > > > -j > > > > > > > > -----Original Message----- > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > To: ietf-pkix@imc.org > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > Subject: RE: President Clinton digital signing > > > > > > > > Terri suggests that the real significance of the > > > certificate and smart card > > > > used by President Clinton is that they were obtained > > > through the Access > > > > Certificates for Electronic Services (ACES) contract at > > > GSA. Through the > > > > use of a Certificate Arbitrator Module (CAM), which is > > > effectively a parser > > > > and validation tool (offered to public domain by GSA), > > > multiple CA's are > > > > made available to the government applications. > > > > > > > > More info at > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > To me, though, the most significant thing is that the > > > E-Sign bill was > > > > signed, regardless of the technology utilized. > > > > > > > > Cheers, > > > > From owner-ietf-pkix@imc.org Wed Aug 23 07:00:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07615 for ; Wed, 23 Aug 2000 07:00:01 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA07945; Wed, 23 Aug 2000 03:59:24 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 03:59:18 -0700 Received: from scog-ws3.gsa.gov (host.159-142-144-58.gsa.gov [159.142.144.58]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA07907 for ; Wed, 23 Aug 2000 03:59:17 -0700 (PDT) From: judith.spencer@gsa.gov Received: from 159.142.144.55 by scog-ws3.gsa.gov with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Wed, 23 Aug 2000 06:59:57 -0400 X-Server-Uuid: cb2f616c-ae65-11d3-874c-00508b6362bc Subject: Re: President Clinton digital signing To: awa1@home.com cc: tstrickland@xcert.com, spinneyj@flashcom.net, ietf-pkix@imc.org, judith.spencer@gsa.gov, yuriy.dzambasow@digsigtrust.com, kcummins@digsigtrust.com Sender: judith.spencer@gsa.gov Date: Wed, 23 Aug 2000 06:59:47 -0400 Message-ID: X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on SCOG-NOTESSMTP1/GSAEXTERNAL(Release 5.0.1b|September 30, 1999) at 08/23/2000 06:59:57 AM MIME-Version: 1.0 X-WSS-ID: 15BD712738537-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit At the time of the Presidential signing, only Digital Signature Trust had completed the exhaustive certification and accreditation process required by GSA in order to receive authorization to issue ACES certificates (AT&T has now been certified, ORC is still in the process). The DST ACES solution that was certified uses the XCERT product (this was a decision made by DST, not mandated by the government). Therefore, on June 29, under the ACES contract, only DST was authorized to issue certificates, and the system certified to issue those certificates utilized the XCERT CA. Judy Spencer GSA "Al Arsenault" on 08/22/2000 03:00:23 PM To: "Tom Strickland" cc: spinneyj@flashcom.net, "ietf-pkix@imc.org" , judith.spencer@gsa.gov, yuriy.dzambasow@digsigtrust.com Subject: Re: President Clinton digital signing Tom Strickland wrote: > > Please review the following URLs to see how and why Xcert was chosen: > > That's all fine and dandy, but I thought that the question was: "Why was a DST/XCert certificate selected for use, vice something from one of the other ACES contractors?" Since IIRC DST had the first ACES contract, I can certainly see giving them this task. But was there any special reason DST chose XCert, since DST provides certificates using most if not all of the major CA providers' equipments? Al Arsenault Chief Security Architect Diversinet Corp. From owner-ietf-pkix@imc.org Wed Aug 23 08:28:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10241 for ; Wed, 23 Aug 2000 08:28:36 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA12991; Wed, 23 Aug 2000 05:27:45 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 05:27:37 -0700 Received: from crack.x509.com (root@crack.x509.com [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA12953 for ; Wed, 23 Aug 2000 05:27:36 -0700 (PDT) Received: from xcert.com (home.x509.com [199.175.150.4]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e7NCRWS06294; Wed, 23 Aug 2000 05:27:32 -0700 (PDT) Message-ID: <39A3C410.72912219@xcert.com> Date: Wed, 23 Aug 2000 08:31:12 -0400 From: Tom Strickland X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Liaquat Khan CC: ietf-pkix@imc.org Subject: Re: President Clinton digital signing References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> <001c01c00cde$64c6d840$68bc01d5@vaio> Content-Type: multipart/mixed; boundary="------------EF40674896C109D7FA4935E6" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. --------------EF40674896C109D7FA4935E6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Liaquat, You bring up a very good point, DoS attacks are a risk in each environment. However if your environment has critical need for current data (such as a bank or government), then a CRL has a higher risk. Example: If a company does not have a requirement for current information, a CRL is sufficient. If a company requires real time data (i.e. a bank or government) due to high value transactions or security, then I would highly recommend OCSP. The risk is if you use CRLs for the latter, the company may get a false sense of security believing their "high value" transactions are guarded by real time data. If the batch CRL is latent, you may continue processing utilizing old data. The risk is a cert believed to be revoked may still be considered good in the system exposing the company to potential fraud or negligence. In an OCSP environment, if you must trust real time data and someone executes a DoS attack, the responder may slow down or worst case, stop working. This is an added value because I would rather slow down or stop processing than to rely on old data. The risk here is slower response time but guaranteed accurate information. This is a question that each company must answer by performing a risk assessment to determine their acceptable level of "pain", risk and exposure. I am not trying to be confrontational in my recent "typings". I am just trying to bring added value to everyone here. As an auditor that has performed audits on several PKI environments, I am just trying to help elevate certain risks that sometimes get overlooked. Best regards, Tom Liaquat Khan wrote: > You have to assume that access to the server which issues CRLs is protected > from denial of service attacks. For example, generally only trusted > operators can authorise the generation of CRLs, after having their > identities authenticated by the server. Also access to the CRL issuer has > to be protected through firewalls, etc. > > If an attacker can perform a DoS attack on a CRL issuer, what is there to > stop him/her launching a similar attack on an OCSP server (e.g. by issuing > an extremely large amount of OCSP requests)? > > Regards, > Liaquat Khan > Technical Manager > Global Trust Authority (GTA) > > ----- Original Message ----- > From: Tom Strickland > To: Ambarish Malpani > Cc: ; > Sent: Wednesday, August 23, 2000 5:11 AM > Subject: Re: President Clinton digital signing > > > Hello Ambarish, > > > > Thanks for your reply. I agree that OCSP services are by far better than > > CRLs. In general, as everyone knows, a CRL is a batch job that updates a > > database over certain intervals. From an audit standpoint, one of the many > > issues with CRLs is that they can be beat. For example, it is very easy to > > perform any series of denial of service attacks against the server. This > > could cause longer than expected delays in the execution of the batch job > > or worse, prevent the batch job from running causing latent (or corrupted) > > CRL publishing. Also, if someone is savvy enough, they could also issue > > hundreds of back to back CRL job requests resulting in multiple jobs > > waiting on shared services again causing problematic CRLs. I know this may > > sound farfetched but they are risks to be considered. > > > > As you may guess I am not a proponent of CRLs for obvious reasons. I have > > heard claims by some that their products are OCSP compliant. In reality it > > is just a batch job publishing to a database but still they have inherent > > CRL batch job latency. > > > > As for the CAM, I am not familiar enough with that to argue for or against > > its use. I do know however that the Xcert product has a non proprietary > > real time OCSP LDAP out of the box resulting in a more robust product. > Note > > that the Sentry CA product can publish CRLs to non OCSP products to offer > > backwards compatibility when needed. Also, the Sentry product can import > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > Also one of the several reasons that Sentry CA was chosen was due to its > > ability to cross certify against other CAs (cross certification). It is > > very easy to setup trust to another company's CA allowing multiple CAs or > > PKI vendors within a central Sentry OCSP environment. > > > > Best regards, > > > > Tom > > > > > > Ambarish Malpani wrote: > > > > > Hi Tom, > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > create a new CRL whenever a new revocation happens. > > > > > > Think of this CRL as a snapshot of the CA's revocation database > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > server that the snapshot has changed. > > > > > > Really, an OCSP server can be set up to be as current as any other > > > software to provide revocation information, either with or without > > > CRLs. > > > > > > It is completely unclear to me why the CAM solution is any > > > more real time than OCSP. I believe the real reason for the > > > CAM solution was just that OCSP didn't exist as a standard till > > > late in the ACES project as indicated by the mails from both > > > Judith and Tim. I have a suspicion that it still might be faster > > > and cheaper for ACES to go with OCSP, rather than try to stick to > > > a non-standard protocol. > > > > > > Regards, > > > Ambarish > > > > > > --------------------------------------------------------------------- > > > Ambarish Malpani > > > Architect 650.567.5457 > > > ValiCert, Inc. ambarish@valicert.com > > > 339 N. Bernardo Ave. http://www.valicert.com > > > Mountain View, CA 94043 > > > > > > > -----Original Message----- > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > dosent seem to want to > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > programs)??". > > > > You have to remember that ACES does have built in OCSP. The > > > > product that they > > > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > > > > > Please review the following URLs to see how and why Xcert was chosen: > > > > > > > > ACES announcement: > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > Reference to digital signature law: > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > Sentry CA functionality: > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > this is very interexting, can somebody please comment on > > > > why the US govt > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > they call it sems > > > > > to be an alternative mechanism....a duplication of much of > > > > the work OCSP has > > > > > already worked through... > > > > > > > > > > -j > > > > > > > > > > -----Original Message----- > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > To: ietf-pkix@imc.org > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > Terri suggests that the real significance of the > > > > certificate and smart card > > > > > used by President Clinton is that they were obtained > > > > through the Access > > > > > Certificates for Electronic Services (ACES) contract at > > > > GSA. Through the > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > effectively a parser > > > > > and validation tool (offered to public domain by GSA), > > > > multiple CA's are > > > > > made available to the government applications. > > > > > > > > > > More info at > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > To me, though, the most significant thing is that the > > > > E-Sign bill was > > > > > signed, regardless of the technology utilized. > > > > > > > > > > Cheers, > > > > > > --------------EF40674896C109D7FA4935E6 Content-Type: text/x-vcard; charset=us-ascii; name="tstrickland.vcf" Content-Description: Card for Tom Strickland Content-Disposition: attachment; filename="tstrickland.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Strickland;Tom tel;cell:678 296-4866 x-mozilla-html:TRUE org:
Xcert International Inc. adr:;;;;;; version:2.1 email;internet:tstrickland@xcert.com fn:Tom Strickland end:vcard --------------EF40674896C109D7FA4935E6-- From owner-ietf-pkix@imc.org Wed Aug 23 08:43:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10534 for ; Wed, 23 Aug 2000 08:43:53 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA14034; Wed, 23 Aug 2000 05:42:43 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 05:42:39 -0700 Received: from smtpproxy1.mitre.org ([129.83.20.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA14004 for ; Wed, 23 Aug 2000 05:42:38 -0700 (PDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id IAA13781; Wed, 23 Aug 2000 08:42:07 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id IAA04668; Wed, 23 Aug 2000 08:39:36 -0400 (EDT) Received: from schaen-pc.mitre.org (128.29.162.49) by mailhub2.mitre.org with SMTP id 4269905; Wed, 23 Aug 2000 08:42:05 EST Message-ID: <39A3C6A0.6C3452C0@mitre.org> Date: Wed, 23 Aug 2000 08:42:08 -0400 From: Sam Schaen X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Strickland CC: Liaquat Khan , ietf-pkix@imc.org Subject: Re: President Clinton digital signing References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> <001c01c00cde$64c6d840$68bc01d5@vaio> <39A3C410.72912219@xcert.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit If the DoS prevents the OCSP responder from receiving a CRL from which it determines validity status, the result is the same. Tom Strickland wrote: > Liaquat, > > You bring up a very good point, DoS attacks are a risk in each environment. > However if your environment has critical need for current data (such as a bank > or government), then a CRL has a higher risk. > > Example: If a company does not have a requirement for current information, a CRL > is sufficient. If a company requires real time data (i.e. a bank or government) > due to high value transactions or security, then I would highly recommend OCSP. > The risk is if you use CRLs for the latter, the company may get a false sense of > security believing their "high value" transactions are guarded by real time > data. If the batch CRL is latent, you may continue processing utilizing old > data. The risk is a cert believed to be revoked may still be considered good in > the system exposing the company to potential fraud or negligence. > > In an OCSP environment, if you must trust real time data and someone executes a > DoS attack, the responder may slow down or worst case, stop working. This is an > added value because I would rather slow down or stop processing than to rely on > old data. The risk here is slower response time but guaranteed accurate > information. > > This is a question that each company must answer by performing a risk assessment > to determine their acceptable level of "pain", risk and exposure. > > I am not trying to be confrontational in my recent "typings". I am just trying > to bring added value to everyone here. As an auditor that has performed audits > on several PKI environments, I am just trying to help elevate certain risks that > sometimes get overlooked. > > Best regards, > > Tom > > Liaquat Khan wrote: > > > You have to assume that access to the server which issues CRLs is protected > > from denial of service attacks. For example, generally only trusted > > operators can authorise the generation of CRLs, after having their > > identities authenticated by the server. Also access to the CRL issuer has > > to be protected through firewalls, etc. > > > > If an attacker can perform a DoS attack on a CRL issuer, what is there to > > stop him/her launching a similar attack on an OCSP server (e.g. by issuing > > an extremely large amount of OCSP requests)? > > > > Regards, > > Liaquat Khan > > Technical Manager > > Global Trust Authority (GTA) > > > > ----- Original Message ----- > > From: Tom Strickland > > To: Ambarish Malpani > > Cc: ; > > Sent: Wednesday, August 23, 2000 5:11 AM > > Subject: Re: President Clinton digital signing > > > > > Hello Ambarish, > > > > > > Thanks for your reply. I agree that OCSP services are by far better than > > > CRLs. In general, as everyone knows, a CRL is a batch job that updates a > > > database over certain intervals. From an audit standpoint, one of the many > > > issues with CRLs is that they can be beat. For example, it is very easy to > > > perform any series of denial of service attacks against the server. This > > > could cause longer than expected delays in the execution of the batch job > > > or worse, prevent the batch job from running causing latent (or corrupted) > > > CRL publishing. Also, if someone is savvy enough, they could also issue > > > hundreds of back to back CRL job requests resulting in multiple jobs > > > waiting on shared services again causing problematic CRLs. I know this may > > > sound farfetched but they are risks to be considered. > > > > > > As you may guess I am not a proponent of CRLs for obvious reasons. I have > > > heard claims by some that their products are OCSP compliant. In reality it > > > is just a batch job publishing to a database but still they have inherent > > > CRL batch job latency. > > > > > > As for the CAM, I am not familiar enough with that to argue for or against > > > its use. I do know however that the Xcert product has a non proprietary > > > real time OCSP LDAP out of the box resulting in a more robust product. > > Note > > > that the Sentry CA product can publish CRLs to non OCSP products to offer > > > backwards compatibility when needed. Also, the Sentry product can import > > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > > > Also one of the several reasons that Sentry CA was chosen was due to its > > > ability to cross certify against other CAs (cross certification). It is > > > very easy to setup trust to another company's CA allowing multiple CAs or > > > PKI vendors within a central Sentry OCSP environment. > > > > > > Best regards, > > > > > > Tom > > > > > > > > > Ambarish Malpani wrote: > > > > > > > Hi Tom, > > > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > > create a new CRL whenever a new revocation happens. > > > > > > > > Think of this CRL as a snapshot of the CA's revocation database > > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > > server that the snapshot has changed. > > > > > > > > Really, an OCSP server can be set up to be as current as any other > > > > software to provide revocation information, either with or without > > > > CRLs. > > > > > > > > It is completely unclear to me why the CAM solution is any > > > > more real time than OCSP. I believe the real reason for the > > > > CAM solution was just that OCSP didn't exist as a standard till > > > > late in the ACES project as indicated by the mails from both > > > > Judith and Tim. I have a suspicion that it still might be faster > > > > and cheaper for ACES to go with OCSP, rather than try to stick to > > > > a non-standard protocol. > > > > > > > > Regards, > > > > Ambarish > > > > > > > > --------------------------------------------------------------------- > > > > Ambarish Malpani > > > > Architect 650.567.5457 > > > > ValiCert, Inc. ambarish@valicert.com > > > > 339 N. Bernardo Ave. http://www.valicert.com > > > > Mountain View, CA 94043 > > > > > > > > > -----Original Message----- > > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > > dosent seem to want to > > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > > programs)??". > > > > > You have to remember that ACES does have built in OCSP. The > > > > > product that they > > > > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > > > > > > > Please review the following URLs to see how and why Xcert was chosen: > > > > > > > > > > ACES announcement: > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > > > Reference to digital signature law: > > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > > > Sentry CA functionality: > > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > > > this is very interexting, can somebody please comment on > > > > > why the US govt > > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > > they call it sems > > > > > > to be an alternative mechanism....a duplication of much of > > > > > the work OCSP has > > > > > > already worked through... > > > > > > > > > > > > -j > > > > > > > > > > > > -----Original Message----- > > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > > To: ietf-pkix@imc.org > > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > > > Terri suggests that the real significance of the > > > > > certificate and smart card > > > > > > used by President Clinton is that they were obtained > > > > > through the Access > > > > > > Certificates for Electronic Services (ACES) contract at > > > > > GSA. Through the > > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > > effectively a parser > > > > > > and validation tool (offered to public domain by GSA), > > > > > multiple CA's are > > > > > > made available to the government applications. > > > > > > > > > > > > More info at > > > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > > > To me, though, the most significant thing is that the > > > > > E-Sign bill was > > > > > > signed, regardless of the technology utilized. > > > > > > > > > > > > Cheers, > > > > > > > > From owner-ietf-pkix@imc.org Wed Aug 23 09:17:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11058 for ; Wed, 23 Aug 2000 09:17:32 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA15065; Wed, 23 Aug 2000 06:16:50 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 06:16:45 -0700 Received: from crack.x509.com (root@crack.x509.com [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15033 for ; Wed, 23 Aug 2000 06:16:44 -0700 (PDT) Received: from xcert.com (home.x509.com [199.175.150.4]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e7NDGrS07724; Wed, 23 Aug 2000 06:16:54 -0700 (PDT) Message-ID: <39A3CFA2.8A6C9EFD@xcert.com> Date: Wed, 23 Aug 2000 09:20:34 -0400 From: Tom Strickland X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Schaen CC: Liaquat Khan , ietf-pkix@imc.org Subject: Re: President Clinton digital signing References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> <001c01c00cde$64c6d840$68bc01d5@vaio> <39A3C410.72912219@xcert.com> <39A3C6A0.6C3452C0@mitre.org> Content-Type: multipart/mixed; boundary="------------362C951FB7D16F1D7594D833" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. --------------362C951FB7D16F1D7594D833 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If you are using a mixture or hybrid OCSP environment to perform checking with an import of CRL data, yes the result could be the same. However, if you are using a true OCSP LDAP environment (i.e. no CRLs), part of your system may slow down due to the DoS but the validity would always be accurate. In the Sentry product, each Registration Authority (RA) has a built in real time OCSP LDAP. This allows a complete OCSP enterprise without the need for any CRLs (unless you want to cross certify a CRL from other non OCSP PKI vendors). This means that your risk of DoS attacks may only slow down one leg (RA) or department of your PKI environment, not the whole enterprise ensuring accurate real time information. Sam Schaen wrote: > If the DoS prevents the OCSP responder from receiving a CRL from which it determines > validity status, the result is the same. > > Tom Strickland wrote: > > > Liaquat, > > > > You bring up a very good point, DoS attacks are a risk in each environment. > > However if your environment has critical need for current data (such as a bank > > or government), then a CRL has a higher risk. > > > > Example: If a company does not have a requirement for current information, a CRL > > is sufficient. If a company requires real time data (i.e. a bank or government) > > due to high value transactions or security, then I would highly recommend OCSP. > > The risk is if you use CRLs for the latter, the company may get a false sense of > > security believing their "high value" transactions are guarded by real time > > data. If the batch CRL is latent, you may continue processing utilizing old > > data. The risk is a cert believed to be revoked may still be considered good in > > the system exposing the company to potential fraud or negligence. > > > > In an OCSP environment, if you must trust real time data and someone executes a > > DoS attack, the responder may slow down or worst case, stop working. This is an > > added value because I would rather slow down or stop processing than to rely on > > old data. The risk here is slower response time but guaranteed accurate > > information. > > > > This is a question that each company must answer by performing a risk assessment > > to determine their acceptable level of "pain", risk and exposure. > > > > I am not trying to be confrontational in my recent "typings". I am just trying > > to bring added value to everyone here. As an auditor that has performed audits > > on several PKI environments, I am just trying to help elevate certain risks that > > sometimes get overlooked. > > > > Best regards, > > > > Tom > > > > Liaquat Khan wrote: > > > > > You have to assume that access to the server which issues CRLs is protected > > > from denial of service attacks. For example, generally only trusted > > > operators can authorise the generation of CRLs, after having their > > > identities authenticated by the server. Also access to the CRL issuer has > > > to be protected through firewalls, etc. > > > > > > If an attacker can perform a DoS attack on a CRL issuer, what is there to > > > stop him/her launching a similar attack on an OCSP server (e.g. by issuing > > > an extremely large amount of OCSP requests)? > > > > > > Regards, > > > Liaquat Khan > > > Technical Manager > > > Global Trust Authority (GTA) > > > > > > ----- Original Message ----- > > > From: Tom Strickland > > > To: Ambarish Malpani > > > Cc: ; > > > Sent: Wednesday, August 23, 2000 5:11 AM > > > Subject: Re: President Clinton digital signing > > > > > > > Hello Ambarish, > > > > > > > > Thanks for your reply. I agree that OCSP services are by far better than > > > > CRLs. In general, as everyone knows, a CRL is a batch job that updates a > > > > database over certain intervals. From an audit standpoint, one of the many > > > > issues with CRLs is that they can be beat. For example, it is very easy to > > > > perform any series of denial of service attacks against the server. This > > > > could cause longer than expected delays in the execution of the batch job > > > > or worse, prevent the batch job from running causing latent (or corrupted) > > > > CRL publishing. Also, if someone is savvy enough, they could also issue > > > > hundreds of back to back CRL job requests resulting in multiple jobs > > > > waiting on shared services again causing problematic CRLs. I know this may > > > > sound farfetched but they are risks to be considered. > > > > > > > > As you may guess I am not a proponent of CRLs for obvious reasons. I have > > > > heard claims by some that their products are OCSP compliant. In reality it > > > > is just a batch job publishing to a database but still they have inherent > > > > CRL batch job latency. > > > > > > > > As for the CAM, I am not familiar enough with that to argue for or against > > > > its use. I do know however that the Xcert product has a non proprietary > > > > real time OCSP LDAP out of the box resulting in a more robust product. > > > Note > > > > that the Sentry CA product can publish CRLs to non OCSP products to offer > > > > backwards compatibility when needed. Also, the Sentry product can import > > > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > > > > > Also one of the several reasons that Sentry CA was chosen was due to its > > > > ability to cross certify against other CAs (cross certification). It is > > > > very easy to setup trust to another company's CA allowing multiple CAs or > > > > PKI vendors within a central Sentry OCSP environment. > > > > > > > > Best regards, > > > > > > > > Tom > > > > > > > > > > > > Ambarish Malpani wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > > > create a new CRL whenever a new revocation happens. > > > > > > > > > > Think of this CRL as a snapshot of the CA's revocation database > > > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > > > server that the snapshot has changed. > > > > > > > > > > Really, an OCSP server can be set up to be as current as any other > > > > > software to provide revocation information, either with or without > > > > > CRLs. > > > > > > > > > > It is completely unclear to me why the CAM solution is any > > > > > more real time than OCSP. I believe the real reason for the > > > > > CAM solution was just that OCSP didn't exist as a standard till > > > > > late in the ACES project as indicated by the mails from both > > > > > Judith and Tim. I have a suspicion that it still might be faster > > > > > and cheaper for ACES to go with OCSP, rather than try to stick to > > > > > a non-standard protocol. > > > > > > > > > > Regards, > > > > > Ambarish > > > > > > > > > > --------------------------------------------------------------------- > > > > > Ambarish Malpani > > > > > Architect 650.567.5457 > > > > > ValiCert, Inc. ambarish@valicert.com > > > > > 339 N. Bernardo Ave. http://www.valicert.com > > > > > Mountain View, CA 94043 > > > > > > > > > > > -----Original Message----- > > > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > > > dosent seem to want to > > > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > > > programs)??". > > > > > > You have to remember that ACES does have built in OCSP. The > > > > > > product that they > > > > > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > > > > > > > > > Please review the following URLs to see how and why Xcert was chosen: > > > > > > > > > > > > ACES announcement: > > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > > > > > Reference to digital signature law: > > > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > > > > > Sentry CA functionality: > > > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > > > > > this is very interexting, can somebody please comment on > > > > > > why the US govt > > > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > > > they call it sems > > > > > > > to be an alternative mechanism....a duplication of much of > > > > > > the work OCSP has > > > > > > > already worked through... > > > > > > > > > > > > > > -j > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > > > To: ietf-pkix@imc.org > > > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > > > > > Terri suggests that the real significance of the > > > > > > certificate and smart card > > > > > > > used by President Clinton is that they were obtained > > > > > > through the Access > > > > > > > Certificates for Electronic Services (ACES) contract at > > > > > > GSA. Through the > > > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > > > effectively a parser > > > > > > > and validation tool (offered to public domain by GSA), > > > > > > multiple CA's are > > > > > > > made available to the government applications. > > > > > > > > > > > > > > More info at > > > > > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > > > > > To me, though, the most significant thing is that the > > > > > > E-Sign bill was > > > > > > > signed, regardless of the technology utilized. > > > > > > > > > > > > > > Cheers, > > > > > > > > > > --------------362C951FB7D16F1D7594D833 Content-Type: text/x-vcard; charset=us-ascii; name="tstrickland.vcf" Content-Description: Card for Tom Strickland Content-Disposition: attachment; filename="tstrickland.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Strickland;Tom tel;cell:678 296-4866 x-mozilla-html:TRUE org:
Xcert International Inc. adr:;;;;;; version:2.1 email;internet:tstrickland@xcert.com fn:Tom Strickland end:vcard --------------362C951FB7D16F1D7594D833-- From owner-ietf-pkix@imc.org Wed Aug 23 09:35:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11348 for ; Wed, 23 Aug 2000 09:35:05 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA15702; Wed, 23 Aug 2000 06:34:24 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 06:34:20 -0700 Received: from osd.mil (firewall-user@gateway1.osd.mil [140.185.28.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15672 for ; Wed, 23 Aug 2000 06:34:19 -0700 (PDT) From: William.Flanigan@bmdo.osd.mil Received: by osd.mil; id JAA25207; Wed, 23 Aug 2000 09:47:45 GMT Received: from hqbmdofs03.bmdo.osd.mil(134.152.2.194) by gateway1.osd.mil via smap (V4.2) id xma025112; Wed, 23 Aug 00 09:47:39 GMT Received: from hqbmdofs03.bmdo.osd.mil (root@localhost) by hqbmdofs03.bmdo.osd.mil with ESMTP id JAA27892; Wed, 23 Aug 2000 09:29:41 -0400 (EDT) Received: from hqbmdomsg01.bmdo.osd.mil (hqbmdomsg01.bmdo.osd.mil [172.20.100.3]) by hqbmdofs03.bmdo.osd.mil with ESMTP id JAA27882; Wed, 23 Aug 2000 09:29:40 -0400 (EDT) Received: by hqbmdomsg01.bmdo.osd.mil with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 09:37:08 -0400 Message-ID: <516542F35571D31187C000A0C9DCD3300304729C@hqbmdomsg01.bmdo.osd.mil> To: pbaker@verisign.com Cc: terri.hobson@gsa.gov, judith.spencer@gsa.gov, marion.royal@gsa.gov, ietf-pkix@imc.org Subject: RE: President Clinton digital signing Date: Wed, 23 Aug 2000 09:37:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_0006_01C00CE5.BBB10AC0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C00CE5.BBB10AC0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C00CE5.BBA4D5C0" ------=_NextPart_000_0002_01C00CE5.BBA4D5C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Right on Philip (as usual)! But it seems unlikely that the bill was not "signed" twice, one being a wet signature (with no photo op). Does anyone know for sure? Bill Flanigan -----Original Message----- From: Philip Hallam-Baker [mailto:pbaker@verisign.com] Sent: Tuesday, August 22, 2000 9:08 PM To: 'marion.royal@gsa.gov'; ietf-pkix@imc.org Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov Subject: RE: President Clinton digital signing [snip] And it was totally illogical to use a digital signature for the purpose. The act is now effectively a self-signed cert! The validity of the authentication on the act is established through a circular reference to the act itself. Phill ------=_NextPart_000_0002_01C00CE5.BBA4D5C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Right on Philip (as usual)!  But it seems = unlikely that the bill was not "signed" twice, one being a wet = signature (with no photo op).  Does anyone know for = sure?

Bill Flanigan

-----Original Message-----
From: Philip Hallam-Baker [mailto:pbaker@verisign.com]
Sent: Tuesday, August 22, 2000 9:08 PM
To: 'marion.royal@gsa.gov'; ietf-pkix@imc.org
Cc: terri.hobson@gsa.gov; = judith.spencer@gsa.gov
Subject: RE: President Clinton digital signing

[snip]

And it was totally illogical to use a digital = signature for the purpose.

The act is now effectively a self-signed cert! The = validity of the
authentication on the act is established through a = circular reference
to the act itself.


        =       Phill

------=_NextPart_000_0002_01C00CE5.BBA4D5C0-- ------=_NextPart_000_0006_01C00CE5.BBB10AC0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHmTCCA6Iw ggMLoAMCAQICAiIxMA0GCSqGSIb3DQEBBQUAMFwxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRcwFQYDVQQDEw5NZWQgRW1h aWwgQ0EtMTAeFw0wMDAyMTAxNzExNTZaFw0wMjAyMTAxNzExNTZaMIGmMQswCQYDVQQGEwJVUzEY MBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTENMAsG A1UECxMEQk1ETzEkMCIGA1UEAxMbRmxhbmlnYW4uV2lsbGlhbS4wNTAyMDAwNTE0MSwwKgYJKoZI hvcNAQkBFh13aWxsaWFtLmZsYW5pZ2FuQGJtZG8ub3NkLm1pbDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA6nmxw86ZU1rXoE2Nqt0ybpt3s9A6mhp/vKzu6+Bfh91utH7KdcRxPBtMSefKFU/r a7atSrupNtXKQ0RAVJTrRPOvbNBTc0eMHDGs0/Rgsw3PrsgLKfFU/HVq8RaBVP9+/rDF1T6b63kY +aO/11/c31ri6yr2KOheAq2be/Lxln8CAwEAAaOCASYwggEiMBYGA1UdIAQPMA0wCwYJYIZIAWUC AQsDMB8GA1UdIwQYMBaAFPIju1ImGhS6CXJ9cNJe5ng8aBX8MB0GA1UdDgQWBBQt/YJY6m1bfbS3 9Imr42XFj1ZNDTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADCBqQYDVR0fBIGhMIGeMIGb oIGYoIGVhoGSbGRhcDovL2RzLTEuY2hhbWIuZGlzYS5taWw6MzkwL2NuJTNkTWVkJTIwRW1haWwl MjBDQSUyZDElMmNvdSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJj YyUzZFVTP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3QlM2JiaW5hcnkwDQYJKoZIhvcNAQEFBQAD gYEAFHiTOZWDZek4j7hscyL4mMo5koXySAnZcLVU6kuotwuuj4LOc8l/trrPTEVawcGw4Qx+evVR lSUPVrbGWvyho7NZ6W+l+6AArPYoO//GcfFJ2g9gx9k3m4W1fZ+hTRxAC4qJqYOi9tdJYSxocZld cketJQKa4IqSRmTMqAqktfYwggPvMIIDWKADAgECAgEjMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNV BAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMD UEtJMRwwGgYDVQQDExNEb0QgUEtJIE1lZCBSb290IENBMB4XDTk4MDgwNjE5NTQ1NFoXDTAzMDgw NjE5NTQ1NFowXDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UE CxMDRG9EMQwwCgYDVQQLEwNQS0kxFzAVBgNVBAMTDk1lZCBFbWFpbCBDQS0xMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQCqTd9bbYLOvC2mMX/fpiD+4MKcPiO7bCNi+6w6jGXsyVzEysRDUkOh OR77XJyU6PD/gRV1BgQC+tqLyVKku0u13m8hxAGLP4EXk5S2Egl6AzueBlVPQcFIpSAoeK3Q69py E/9WFGCf2VDWM/57IFcHmaBzUM7aWyybNw+VHo+1JwIDAQABo4IBujCCAbYwFgYDVR0gBA8wDTAL BglghkgBZQIBCwMwHwYDVR0jBBgwFoAUxVnSzvGYlVBmqG3eMkvWYTXiRrMwDAYDVR0kBAUwA4AB ADAdBgNVHQ4EFgQU8iO7UiYaFLoJcn1w0l7meDxoFfwwDgYDVR0PAQH/BAQDAgGGMH4GA1UdEgR3 MHWGc2xkYXA6Ly9kcy0xLmNoYW1iLmRpc2EubWlsL2NuJTNkRG9EJTIwUEtJJTIwTWVkJTIwUm9v dCUyMENBJTJjb3UlM2RQS0klMiBjb3UlM2REb0QlMmNvJTNkVS5TLiUyMEdvdmVybm1lbnQlMmNj JTNkVVMwDwYDVR0TAQH/BAUwAwEB/zCBrAYDVR0fBIGkMIGhMIGeoIGboIGYhoGVbGRhcDovL2Rz LTEuY2hhbWIuZGlzYS5taWwvY24lM2REb0QlMjBQS0klMjBNZWQlMjBSb290JTIwQ0ElMmNvdSUz ZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2NlcnRpZmlj YXRlUmV2b2NhdGlvbkxpc3QlM2JiaW5hcnkwDQYJKoZIhvcNAQEFBQADgYEAlQOnyvY3wBzBFqvQ maAJqUUpucy55ErAncWtLBJcNP3Q56vAk4/O4gf/0KUe+x8DovQAe5KIn3JMQUoxc98SxV2xj+/t PvUgxPV9d59Nl2lJEGq7eufOnhwE7NNFEDJNub6V2EIpH3VMmDsPqvFJzmqTTzxzrZISXr3vJR7S dFcxggI2MIICMgIBATBiMFwxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQx DDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRcwFQYDVQQDEw5NZWQgRW1haWwgQ0EtMQICIjEw CQYFKw4DAhoFAKCCASowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MDAwODIzMTMzNzIwWjAjBgkqhkiG9w0BCQQxFgQUAqB8IDKqmT45L4Yzxe+2j+cCzFAwWAYJKoZI hvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwcQYJKwYBBAGCNxAEMWQwYjBcMQswCQYDVQQGEwJV UzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEX MBUGA1UEAxMOTWVkIEVtYWlsIENBLTECAiIxMA0GCSqGSIb3DQEBAQUABIGALsF5XSF0uNyG2Vzd m3in9q3k0LMFCskAanLqShnqqyyo8pcAGqwxG3T36j/bflyNZEKCRUgI+NIgKaVVHJOQ2q6Yl+6R bSBxjXd6WoaB4D+9xtdeDwpwpzF2ykTt5tuCNUjVl0jTmbSvXHgiL2wh9Sb0maOLwV8lH7GehJn9 A7UAAAAAAAA= ------=_NextPart_000_0006_01C00CE5.BBB10AC0-- From owner-ietf-pkix@imc.org Wed Aug 23 09:58:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11706 for ; Wed, 23 Aug 2000 09:58:23 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA16934; Wed, 23 Aug 2000 06:57:32 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 06:57:20 -0700 Received: from neodymium.btinternet.com (neodymium.btinternet.com [194.73.73.83]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16899 for ; Wed, 23 Aug 2000 06:57:18 -0700 (PDT) Received: from [213.1.130.101] (helo=vaio) by neodymium.btinternet.com with smtp (Exim 3.03 #83) id 13Rb2D-000149-00 for ietf-pkix@imc.org; Wed, 23 Aug 2000 14:57:41 +0100 Message-ID: <002b01c00d0a$7ef392e0$ed3863c3@vaio> Reply-To: "Liaquat Khan" From: "Liaquat Khan" To: References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> <001c01c00cde$64c6d840$68bc01d5@vaio> <39A3C410.72912219@xcert.com> Subject: Re: President Clinton digital signing Date: Wed, 23 Aug 2000 15:00:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Tom, I generally agree with you, but I think the issue of launching a DoS attack on CRLs has been mixed in with the periodic nature of CRLs. There are two separate risks: 1) a CRL has expired and a new one has not been generated in time (e.g. due to a DoS attack). In this case the relying party should not really depend on the CRL as it should be obvious from reading the available CRL that it is out of date. Therefore, certificates may have been revoked in the meantime but there is no fresh CRL to check, so you abort the transaction. This is DoS. 2) a certificate is revoked but the next CRL is not due to be issued until later. Therefore, this scenario is not related to a DoS attack. To overcome this you need to ensure that CRLs are issued with a frequency which is acceptable. By using OCSP, it doesn't necessarily mean this issue goes away...you will still need to work out how long it will take from the time a decision is made to revoke a certificate to the time that the OCSP server becomes aware of this (e.g. note that the OCSP server may be fed using periodic CRLs). Regards, Liaquat Khan Technical Manager Global Trust Authority (GTA) A relying ----- Original Message ----- From: Tom Strickland To: Liaquat Khan Cc: Sent: Wednesday, August 23, 2000 1:31 PM Subject: Re: President Clinton digital signing > Liaquat, > > You bring up a very good point, DoS attacks are a risk in each environment. > However if your environment has critical need for current data (such as a bank > or government), then a CRL has a higher risk. > > Example: If a company does not have a requirement for current information, a CRL > is sufficient. If a company requires real time data (i.e. a bank or government) > due to high value transactions or security, then I would highly recommend OCSP. > The risk is if you use CRLs for the latter, the company may get a false sense of > security believing their "high value" transactions are guarded by real time > data. If the batch CRL is latent, you may continue processing utilizing old > data. The risk is a cert believed to be revoked may still be considered good in > the system exposing the company to potential fraud or negligence. > > In an OCSP environment, if you must trust real time data and someone executes a > DoS attack, the responder may slow down or worst case, stop working. This is an > added value because I would rather slow down or stop processing than to rely on > old data. The risk here is slower response time but guaranteed accurate > information. > > This is a question that each company must answer by performing a risk assessment > to determine their acceptable level of "pain", risk and exposure. > > I am not trying to be confrontational in my recent "typings". I am just trying > to bring added value to everyone here. As an auditor that has performed audits > on several PKI environments, I am just trying to help elevate certain risks that > sometimes get overlooked. > > Best regards, > > Tom > > Liaquat Khan wrote: > > > You have to assume that access to the server which issues CRLs is protected > > from denial of service attacks. For example, generally only trusted > > operators can authorise the generation of CRLs, after having their > > identities authenticated by the server. Also access to the CRL issuer has > > to be protected through firewalls, etc. > > > > If an attacker can perform a DoS attack on a CRL issuer, what is there to > > stop him/her launching a similar attack on an OCSP server (e.g. by issuing > > an extremely large amount of OCSP requests)? > > > > Regards, > > Liaquat Khan > > Technical Manager > > Global Trust Authority (GTA) > > > > ----- Original Message ----- > > From: Tom Strickland > > To: Ambarish Malpani > > Cc: ; > > Sent: Wednesday, August 23, 2000 5:11 AM > > Subject: Re: President Clinton digital signing > > > > > Hello Ambarish, > > > > > > Thanks for your reply. I agree that OCSP services are by far better than > > > CRLs. In general, as everyone knows, a CRL is a batch job that updates a > > > database over certain intervals. From an audit standpoint, one of the many > > > issues with CRLs is that they can be beat. For example, it is very easy to > > > perform any series of denial of service attacks against the server. This > > > could cause longer than expected delays in the execution of the batch job > > > or worse, prevent the batch job from running causing latent (or corrupted) > > > CRL publishing. Also, if someone is savvy enough, they could also issue > > > hundreds of back to back CRL job requests resulting in multiple jobs > > > waiting on shared services again causing problematic CRLs. I know this may > > > sound farfetched but they are risks to be considered. > > > > > > As you may guess I am not a proponent of CRLs for obvious reasons. I have > > > heard claims by some that their products are OCSP compliant. In reality it > > > is just a batch job publishing to a database but still they have inherent > > > CRL batch job latency. > > > > > > As for the CAM, I am not familiar enough with that to argue for or against > > > its use. I do know however that the Xcert product has a non proprietary > > > real time OCSP LDAP out of the box resulting in a more robust product. > > Note > > > that the Sentry CA product can publish CRLs to non OCSP products to offer > > > backwards compatibility when needed. Also, the Sentry product can import > > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > > > Also one of the several reasons that Sentry CA was chosen was due to its > > > ability to cross certify against other CAs (cross certification). It is > > > very easy to setup trust to another company's CA allowing multiple CAs or > > > PKI vendors within a central Sentry OCSP environment. > > > > > > Best regards, > > > > > > Tom > > > > > > > > > Ambarish Malpani wrote: > > > > > > > Hi Tom, > > > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > > create a new CRL whenever a new revocation happens. > > > > > > > > Think of this CRL as a snapshot of the CA's revocation database > > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > > server that the snapshot has changed. > > > > > > > > Really, an OCSP server can be set up to be as current as any other > > > > software to provide revocation information, either with or without > > > > CRLs. > > > > > > > > It is completely unclear to me why the CAM solution is any > > > > more real time than OCSP. I believe the real reason for the > > > > CAM solution was just that OCSP didn't exist as a standard till > > > > late in the ACES project as indicated by the mails from both > > > > Judith and Tim. I have a suspicion that it still might be faster > > > > and cheaper for ACES to go with OCSP, rather than try to stick to > > > > a non-standard protocol. > > > > > > > > Regards, > > > > Ambarish > > > > > > > > --------------------------------------------------------------------- > > > > Ambarish Malpani > > > > Architect 650.567.5457 > > > > ValiCert, Inc. ambarish@valicert.com > > > > 339 N. Bernardo Ave. http://www.valicert.com > > > > Mountain View, CA 94043 > > > > > > > > > -----Original Message----- > > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > > dosent seem to want to > > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > > programs)??". > > > > > You have to remember that ACES does have built in OCSP. The > > > > > product that they > > > > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > > > > > > > Please review the following URLs to see how and why Xcert was chosen: > > > > > > > > > > ACES announcement: > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > > > Reference to digital signature law: > > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > > > Sentry CA functionality: > > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > > > this is very interexting, can somebody please comment on > > > > > why the US govt > > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > > they call it sems > > > > > > to be an alternative mechanism....a duplication of much of > > > > > the work OCSP has > > > > > > already worked through... > > > > > > > > > > > > -j > > > > > > > > > > > > -----Original Message----- > > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > > To: ietf-pkix@imc.org > > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > > > Terri suggests that the real significance of the > > > > > certificate and smart card > > > > > > used by President Clinton is that they were obtained > > > > > through the Access > > > > > > Certificates for Electronic Services (ACES) contract at > > > > > GSA. Through the > > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > > effectively a parser > > > > > > and validation tool (offered to public domain by GSA), > > > > > multiple CA's are > > > > > > made available to the government applications. > > > > > > > > > > > > More info at > > > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > > > To me, though, the most significant thing is that the > > > > > E-Sign bill was > > > > > > signed, regardless of the technology utilized. > > > > > > > > > > > > Cheers, > > > > > > > > > From owner-ietf-pkix@imc.org Wed Aug 23 10:04:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11894 for ; Wed, 23 Aug 2000 10:04:40 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA17418; Wed, 23 Aug 2000 07:04:01 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 07:03:59 -0700 Received: from c014.sfo.cp.net (c014-h022.c014.sfo.cp.net [209.228.12.86]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA17386 for ; Wed, 23 Aug 2000 07:03:59 -0700 (PDT) Received: (cpmta 27108 invoked from network); 23 Aug 2000 07:03:54 -0700 Received: from 3ff8359b.dsl.flashcom.net (HELO concord) (63.248.53.155) by smtp.flashcom.net with SMTP; 23 Aug 2000 07:03:54 -0700 X-Sent: 23 Aug 2000 14:03:54 GMT Reply-To: From: "Jeff Spinney" To: "'Tom Strickland'" , "'Sam Schaen'" Cc: "'Liaquat Khan'" , Subject: RE: President Clinton digital signing Date: Wed, 23 Aug 2000 10:00:09 -0400 Message-ID: <003d01c00d0a$736f9360$6501010a@jeffshouse.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <39A3CFA2.8A6C9EFD@xcert.com> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit I am uncertain that I would refer to an OCSP responder which imports CRL data in order to give out real time cert status a 'hybrid'....CRLs wont be going away completely anytime soon (nor do i think they were they intended to), rather the 'audience' for them has changed ...from each individual user to the OCSP responder. The OCSP responder is intended to be the public interface, speaking for the status of certificates that have been issued on behalf of the CA. It should be closely related to the CA, that is there should be a secure channel for publication of CRLs...however, it shouldn't necessarily be the CA itself. Having an interface that only the CA can talk to minimizes a potential DoS attack on that interface. In addition, it is beneficial to have some sort of 'secure' LDAP storage for issued certificates and crls, whether it is an integral part of the OCSP responder (such as CertCo's CertValidator) or a separate directory. Having some sort of central storage that can be accessed by end users in the PKI (or their applications) is critical in having encrypted email.... Picture the environment where you wish to be able to take the CA offline for either security or policy reasons. The OCSP responder should be able to speak for certificate status until the next update from the CA comes along, it has the ability to keep the PKI operational while the CA is offline. In a high value PKI, where it potentially takes some amount of time to bring together those individuals who possess the distributed private information needed to operate the CA, the OCSP responder should have the ability to place the operational status of a certificate within its PKI on 'hold' as defined in the rfc2560. This hold status is nearly instantaneous, for all OCSP queries afterwards the status will be 'revoked' with a reason code of 'on hold'. Once the proper resources are brought together and the CA is brought online, the certificate may be officially revoked by the entity which originally issued it. When the CRL is issued, the status of this certificate is moved to a permanently revoked state. -j -----Original Message----- From: Tom Strickland [mailto:tstrickland@xcert.com] Sent: Wednesday, August 23, 2000 9:21 AM To: Sam Schaen Cc: Liaquat Khan; ietf-pkix@imc.org Subject: Re: President Clinton digital signing If you are using a mixture or hybrid OCSP environment to perform checking with an import of CRL data, yes the result could be the same. However, if you are using a true OCSP LDAP environment (i.e. no CRLs), part of your system may slow down due to the DoS but the validity would always be accurate. In the Sentry product, each Registration Authority (RA) has a built in real time OCSP LDAP. This allows a complete OCSP enterprise without the need for any CRLs (unless you want to cross certify a CRL from other non OCSP PKI vendors). This means that your risk of DoS attacks may only slow down one leg (RA) or department of your PKI environment, not the whole enterprise ensuring accurate real time information. Sam Schaen wrote: > If the DoS prevents the OCSP responder from receiving a CRL from which it determines > validity status, the result is the same. > > Tom Strickland wrote: > > > Liaquat, > > > > You bring up a very good point, DoS attacks are a risk in each environment. > > However if your environment has critical need for current data (such as a bank > > or government), then a CRL has a higher risk. > > > > Example: If a company does not have a requirement for current information, a CRL > > is sufficient. If a company requires real time data (i.e. a bank or government) > > due to high value transactions or security, then I would highly recommend OCSP. > > The risk is if you use CRLs for the latter, the company may get a false sense of > > security believing their "high value" transactions are guarded by real time > > data. If the batch CRL is latent, you may continue processing utilizing old > > data. The risk is a cert believed to be revoked may still be considered good in > > the system exposing the company to potential fraud or negligence. > > > > In an OCSP environment, if you must trust real time data and someone executes a > > DoS attack, the responder may slow down or worst case, stop working. This is an > > added value because I would rather slow down or stop processing than to rely on > > old data. The risk here is slower response time but guaranteed accurate > > information. > > > > This is a question that each company must answer by performing a risk assessment > > to determine their acceptable level of "pain", risk and exposure. > > > > I am not trying to be confrontational in my recent "typings". I am just trying > > to bring added value to everyone here. As an auditor that has performed audits > > on several PKI environments, I am just trying to help elevate certain risks that > > sometimes get overlooked. > > > > Best regards, > > > > Tom > > > > Liaquat Khan wrote: > > > > > You have to assume that access to the server which issues CRLs is protected > > > from denial of service attacks. For example, generally only trusted > > > operators can authorise the generation of CRLs, after having their > > > identities authenticated by the server. Also access to the CRL issuer has > > > to be protected through firewalls, etc. > > > > > > If an attacker can perform a DoS attack on a CRL issuer, what is there to > > > stop him/her launching a similar attack on an OCSP server (e.g. by issuing > > > an extremely large amount of OCSP requests)? > > > > > > Regards, > > > Liaquat Khan > > > Technical Manager > > > Global Trust Authority (GTA) > > > > > > ----- Original Message ----- > > > From: Tom Strickland > > > To: Ambarish Malpani > > > Cc: ; > > > Sent: Wednesday, August 23, 2000 5:11 AM > > > Subject: Re: President Clinton digital signing > > > > > > > Hello Ambarish, > > > > > > > > Thanks for your reply. I agree that OCSP services are by far better than > > > > CRLs. In general, as everyone knows, a CRL is a batch job that updates a > > > > database over certain intervals. From an audit standpoint, one of the many > > > > issues with CRLs is that they can be beat. For example, it is very easy to > > > > perform any series of denial of service attacks against the server. This > > > > could cause longer than expected delays in the execution of the batch job > > > > or worse, prevent the batch job from running causing latent (or corrupted) > > > > CRL publishing. Also, if someone is savvy enough, they could also issue > > > > hundreds of back to back CRL job requests resulting in multiple jobs > > > > waiting on shared services again causing problematic CRLs. I know this may > > > > sound farfetched but they are risks to be considered. > > > > > > > > As you may guess I am not a proponent of CRLs for obvious reasons. I have > > > > heard claims by some that their products are OCSP compliant. In reality it > > > > is just a batch job publishing to a database but still they have inherent > > > > CRL batch job latency. > > > > > > > > As for the CAM, I am not familiar enough with that to argue for or against > > > > its use. I do know however that the Xcert product has a non proprietary > > > > real time OCSP LDAP out of the box resulting in a more robust product. > > > Note > > > > that the Sentry CA product can publish CRLs to non OCSP products to offer > > > > backwards compatibility when needed. Also, the Sentry product can import > > > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > > > > > Also one of the several reasons that Sentry CA was chosen was due to its > > > > ability to cross certify against other CAs (cross certification). It is > > > > very easy to setup trust to another company's CA allowing multiple CAs or > > > > PKI vendors within a central Sentry OCSP environment. > > > > > > > > Best regards, > > > > > > > > Tom > > > > > > > > > > > > Ambarish Malpani wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > > > create a new CRL whenever a new revocation happens. > > > > > > > > > > Think of this CRL as a snapshot of the CA's revocation database > > > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > > > server that the snapshot has changed. > > > > > > > > > > Really, an OCSP server can be set up to be as current as any other > > > > > software to provide revocation information, either with or without > > > > > CRLs. > > > > > > > > > > It is completely unclear to me why the CAM solution is any > > > > > more real time than OCSP. I believe the real reason for the > > > > > CAM solution was just that OCSP didn't exist as a standard till > > > > > late in the ACES project as indicated by the mails from both > > > > > Judith and Tim. I have a suspicion that it still might be faster > > > > > and cheaper for ACES to go with OCSP, rather than try to stick to > > > > > a non-standard protocol. > > > > > > > > > > Regards, > > > > > Ambarish > > > > > > > > > > --------------------------------------------------------------------- > > > > > Ambarish Malpani > > > > > Architect 650.567.5457 > > > > > ValiCert, Inc. ambarish@valicert.com > > > > > 339 N. Bernardo Ave. http://www.valicert.com > > > > > Mountain View, CA 94043 > > > > > > > > > > > -----Original Message----- > > > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > > > dosent seem to want to > > > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > > > programs)??". > > > > > > You have to remember that ACES does have built in OCSP. The > > > > > > product that they > > > > > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > > > > > > > > > Please review the following URLs to see how and why Xcert was chosen: > > > > > > > > > > > > ACES announcement: > > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > > > > > Reference to digital signature law: > > > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > > > > > Sentry CA functionality: > > > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > > > > > this is very interexting, can somebody please comment on > > > > > > why the US govt > > > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > > > they call it sems > > > > > > > to be an alternative mechanism....a duplication of much of > > > > > > the work OCSP has > > > > > > > already worked through... > > > > > > > > > > > > > > -j > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > > > To: ietf-pkix@imc.org > > > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > > > > > Terri suggests that the real significance of the > > > > > > certificate and smart card > > > > > > > used by President Clinton is that they were obtained > > > > > > through the Access > > > > > > > Certificates for Electronic Services (ACES) contract at > > > > > > GSA. Through the > > > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > > > effectively a parser > > > > > > > and validation tool (offered to public domain by GSA), > > > > > > multiple CA's are > > > > > > > made available to the government applications. > > > > > > > > > > > > > > More info at > > > > > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > > > > > To me, though, the most significant thing is that the > > > > > > E-Sign bill was > > > > > > > signed, regardless of the technology utilized. > > > > > > > > > > > > > > Cheers, > > > > > > > > > > From owner-ietf-pkix@imc.org Wed Aug 23 10:09:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11958 for ; Wed, 23 Aug 2000 10:09:13 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA17889; Wed, 23 Aug 2000 07:08:32 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 07:08:30 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17859 for ; Wed, 23 Aug 2000 07:08:29 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA05281; Wed, 23 Aug 2000 10:08:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <39A34EFD.2DE9A602@xcert.com> References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> Date: Wed, 23 Aug 2000 10:03:07 -0400 To: Tom Strickland From: Stephen Kent Subject: Re: President Clinton digital signing Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Tom, >Hello Ambarish, > >Thanks for your reply. I agree that OCSP services are by far better than >CRLs. I think this is an over generalization, i.e., OCSP is bettr in some cases, but not in all cases. >In general, as everyone knows, a CRL is a batch job that updates a >database over certain intervals. From an audit standpoint, one of the many >issues with CRLs is that they can be beat. For example, it is very easy to >perform any series of denial of service attacks against the server. Which server? A directory? A CRL has the advantage that it can be replicated at any numnber of servers, without imbuing these serves with trust (re integrity and authenticity). While it is certainly true that one can engage in a DoS attack against directories, the same is also true for OCSP servers. I don't think we have enough experience with both types of servers to determine if one is more susceptible than the other, as a class, or if it's just an issue of implementation and local management quality. >This >could cause longer than expected delays in the execution of the batch job >or worse, prevent the batch job from running causing latent (or corrupted) >CRL publishing. Batch job? Now it sounds like your talking about a CA preparing a CRL. A CA component generating a CRL need not be online and thus need not be very susceptible to DoS attacks, so I'm puzzled by this line of reasoning. >Also, if someone is savvy enough, they could also issue >hundreds of back to back CRL job requests resulting in multiple jobs >waiting on shared services again causing problematic CRLs. I know this may >sound farfetched but they are risks to be considered. CRL job requests? I've been involved with the design of several CAs over time and none offered an external interface which could be manipulated inthe fashion you suggest. >As you may guess I am not a proponent of CRLs for obvious reasons. I have >heard claims by some that their products are OCSP compliant. In reality it >is just a batch job publishing to a database but still they have inherent >CRL batch job latency. The latency issue re CRLs is a red herring, in almost all cases. The time required to generate a CRL is fairly small for almost any PKI of a reasonable size. The external, non-technical factors associated with deciding that a compromise has occurred or that an attribute has changed and thus a cert should be revoked almost always swamp the CRL production activity. >As for the CAM, I am not familiar enough with that to argue for or against >its use. I do know however that the Xcert product has a non proprietary >real time OCSP LDAP out of the box resulting in a more robust product. Note >that the Sentry CA product can publish CRLs to non OCSP products to offer >backwards compatibility when needed. Also, the Sentry product can import >other vendors CRLs and place them in the real time OCSP LDAP. Oh, OCSp and LDAP? That combination suggests an DoS opportunity that might be the sum of the two server interfaces :-). >Also one of the several reasons that Sentry CA was chosen was due to its >ability to cross certify against other CAs (cross certification). It is >very easy to setup trust to another company's CA allowing multiple CAs or >PKI vendors within a central Sentry OCSP environment. No more product endorsements, OK? Steve From owner-ietf-pkix@imc.org Wed Aug 23 10:19:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12257 for ; Wed, 23 Aug 2000 10:19:26 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA18626; Wed, 23 Aug 2000 07:18:44 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 07:18:43 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18594 for ; Wed, 23 Aug 2000 07:18:41 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA07228; Wed, 23 Aug 2000 10:19:05 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <39A3CFA2.8A6C9EFD@xcert.com> References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> <001c01c00cde$64c6d840$68bc01d5@vaio> <39A3C410.72912219@xcert.com> <39A3C6A0.6C3452C0@mitre.org> <39A3CFA2.8A6C9EFD@xcert.com> Date: Wed, 23 Aug 2000 10:13:05 -0400 To: Tom Strickland From: Stephen Kent Subject: Re: President Clinton digital signing Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Tom, >If you are using a mixture or hybrid OCSP environment to perform >checking with an import >of CRL data, yes the result could be the same. OCSP does not say how an OCSp server acquires the revocation information it relies on. Unless the server is tightly tied to a CA, CRLs would probably be the basis for the data. Also, CRLs are the only standard means of acquiring such data from multiple CAs. > >However, if you are using a true OCSP LDAP environment (i.e. no >CRLs), part of your >system may slow down due to the DoS but the validity would always be accurate. > >In the Sentry product, each Registration Authority (RA) has a built >in real time OCSP >LDAP. This allows a complete OCSP enterprise without the need for >any CRLs (unless you >want to cross certify a CRL from other non OCSP PKI vendors). This >means that your risk >of DoS attacks may only slow down one leg (RA) or department of your >PKI environment, >not the whole enterprise ensuring accurate real time information. In the model you describe, there would also seem to be a robustness issue, i.e., unless each RA replicates the OCSP server function, a portion of the cert space cannot be checked if the cognizant RA is offline. This also seems a bit odd, as the usual model for a PKI assigns the task of revocation to the CA, not the RA. Steve From owner-ietf-pkix@imc.org Wed Aug 23 10:32:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12912 for ; Wed, 23 Aug 2000 10:32:08 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA19597; Wed, 23 Aug 2000 07:31:27 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 07:31:23 -0700 Received: from unimur.um.es (unimur.um.es [155.54.1.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19562 for ; Wed, 23 Aug 2000 07:31:21 -0700 (PDT) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by unimur.um.es (8.9.1b+Sun/8.9.1) with ESMTP id QAA10841 for ; Wed, 23 Aug 2000 16:31:44 +0200 (MET DST) Received: from dif.um.es (pirania.dif.um.es [155.54.210.33]) by aries.dif.um.es (Postfix) with ESMTP id A39B2EC1A for ; Wed, 23 Aug 2000 16:30:39 +0200 (MET DST) Message-ID: <39A3E05D.72283049@dif.um.es> Date: Wed, 23 Aug 2000 16:31:57 +0200 From: Gabriel Lopez Millan X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Policy Representation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi all. I'm working in a PKI and I have a little question. I want to create Policies (RSA Key Length Size, Key Algorithm Type, etc). Similar to X509Extension, each extension has a OID (unique identifier) and have a ASN1 representation. There is OIDs for Policies? There is a document where I can find documentation? Should I define my own OID and my own ASN1 representation? Thanks, Gabi. From owner-ietf-pkix@imc.org Wed Aug 23 11:09:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14148 for ; Wed, 23 Aug 2000 11:09:50 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA22696; Wed, 23 Aug 2000 08:09:07 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 08:09:01 -0700 Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22659 for ; Wed, 23 Aug 2000 08:09:00 -0700 (PDT) Received: from [62.6.95.151] (helo=vaio) by tungsten.btinternet.com with smtp (Exim 3.03 #83) id 13Rc9Y-0006IB-00 for ietf-pkix@imc.org; Wed, 23 Aug 2000 16:09:21 +0100 Message-ID: <005001c00d14$81ca4e00$ed3863c3@vaio> Reply-To: "Liaquat Khan" From: "Liaquat Khan" To: References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> <001c01c00cde$64c6d840$68bc01d5@vaio> <39A3C410.72912219@xcert.com> <39A3C6A0.6C3452C0@mitre.org> <39A3CFA2.8A6C9EFD@xcert.com> Subject: Re: President Clinton digital signing Date: Wed, 23 Aug 2000 16:01:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Tom, Isn't it a good idea to generate CRLs anyway, even if you are using OCSP? The main reason I have in mind is so that the CRL acts as a historical record of when the certificate was revoked. On the other hand, an OCSP response would only be sent subsequent to receiving an appropriate OCSP request message. Regards, Liaquat Khan Technical Manager Global Trust Authority (GTA) ----- Original Message ----- From: Tom Strickland To: Sam Schaen Cc: Liaquat Khan ; Sent: Wednesday, August 23, 2000 2:20 PM Subject: Re: President Clinton digital signing > If you are using a mixture or hybrid OCSP environment to perform checking with an import > of CRL data, yes the result could be the same. > > However, if you are using a true OCSP LDAP environment (i.e. no CRLs), part of your > system may slow down due to the DoS but the validity would always be accurate. > > In the Sentry product, each Registration Authority (RA) has a built in real time OCSP > LDAP. This allows a complete OCSP enterprise without the need for any CRLs (unless you > want to cross certify a CRL from other non OCSP PKI vendors). This means that your risk > of DoS attacks may only slow down one leg (RA) or department of your PKI environment, > not the whole enterprise ensuring accurate real time information. > > Sam Schaen wrote: > > > If the DoS prevents the OCSP responder from receiving a CRL from which it determines > > validity status, the result is the same. > > > > Tom Strickland wrote: > > > > > Liaquat, > > > > > > You bring up a very good point, DoS attacks are a risk in each environment. > > > However if your environment has critical need for current data (such as a bank > > > or government), then a CRL has a higher risk. > > > > > > Example: If a company does not have a requirement for current information, a CRL > > > is sufficient. If a company requires real time data (i.e. a bank or government) > > > due to high value transactions or security, then I would highly recommend OCSP. > > > The risk is if you use CRLs for the latter, the company may get a false sense of > > > security believing their "high value" transactions are guarded by real time > > > data. If the batch CRL is latent, you may continue processing utilizing old > > > data. The risk is a cert believed to be revoked may still be considered good in > > > the system exposing the company to potential fraud or negligence. > > > > > > In an OCSP environment, if you must trust real time data and someone executes a > > > DoS attack, the responder may slow down or worst case, stop working. This is an > > > added value because I would rather slow down or stop processing than to rely on > > > old data. The risk here is slower response time but guaranteed accurate > > > information. > > > > > > This is a question that each company must answer by performing a risk assessment > > > to determine their acceptable level of "pain", risk and exposure. > > > > > > I am not trying to be confrontational in my recent "typings". I am just trying > > > to bring added value to everyone here. As an auditor that has performed audits > > > on several PKI environments, I am just trying to help elevate certain risks that > > > sometimes get overlooked. > > > > > > Best regards, > > > > > > Tom > > > > > > Liaquat Khan wrote: > > > > > > > You have to assume that access to the server which issues CRLs is protected > > > > from denial of service attacks. For example, generally only trusted > > > > operators can authorise the generation of CRLs, after having their > > > > identities authenticated by the server. Also access to the CRL issuer has > > > > to be protected through firewalls, etc. > > > > > > > > If an attacker can perform a DoS attack on a CRL issuer, what is there to > > > > stop him/her launching a similar attack on an OCSP server (e.g. by issuing > > > > an extremely large amount of OCSP requests)? > > > > > > > > Regards, > > > > Liaquat Khan > > > > Technical Manager > > > > Global Trust Authority (GTA) > > > > > > > > ----- Original Message ----- > > > > From: Tom Strickland > > > > To: Ambarish Malpani > > > > Cc: ; > > > > Sent: Wednesday, August 23, 2000 5:11 AM > > > > Subject: Re: President Clinton digital signing > > > > > > > > > Hello Ambarish, > > > > > > > > > > Thanks for your reply. I agree that OCSP services are by far better than > > > > > CRLs. In general, as everyone knows, a CRL is a batch job that updates a > > > > > database over certain intervals. From an audit standpoint, one of the many > > > > > issues with CRLs is that they can be beat. For example, it is very easy to > > > > > perform any series of denial of service attacks against the server. This > > > > > could cause longer than expected delays in the execution of the batch job > > > > > or worse, prevent the batch job from running causing latent (or corrupted) > > > > > CRL publishing. Also, if someone is savvy enough, they could also issue > > > > > hundreds of back to back CRL job requests resulting in multiple jobs > > > > > waiting on shared services again causing problematic CRLs. I know this may > > > > > sound farfetched but they are risks to be considered. > > > > > > > > > > As you may guess I am not a proponent of CRLs for obvious reasons. I have > > > > > heard claims by some that their products are OCSP compliant. In reality it > > > > > is just a batch job publishing to a database but still they have inherent > > > > > CRL batch job latency. > > > > > > > > > > As for the CAM, I am not familiar enough with that to argue for or against > > > > > its use. I do know however that the Xcert product has a non proprietary > > > > > real time OCSP LDAP out of the box resulting in a more robust product. > > > > Note > > > > > that the Sentry CA product can publish CRLs to non OCSP products to offer > > > > > backwards compatibility when needed. Also, the Sentry product can import > > > > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > > > > > > > Also one of the several reasons that Sentry CA was chosen was due to its > > > > > ability to cross certify against other CAs (cross certification). It is > > > > > very easy to setup trust to another company's CA allowing multiple CAs or > > > > > PKI vendors within a central Sentry OCSP environment. > > > > > > > > > > Best regards, > > > > > > > > > > Tom > > > > > > > > > > > > > > > Ambarish Malpani wrote: > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > > > > create a new CRL whenever a new revocation happens. > > > > > > > > > > > > Think of this CRL as a snapshot of the CA's revocation database > > > > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > > > > server that the snapshot has changed. > > > > > > > > > > > > Really, an OCSP server can be set up to be as current as any other > > > > > > software to provide revocation information, either with or without > > > > > > CRLs. > > > > > > > > > > > > It is completely unclear to me why the CAM solution is any > > > > > > more real time than OCSP. I believe the real reason for the > > > > > > CAM solution was just that OCSP didn't exist as a standard till > > > > > > late in the ACES project as indicated by the mails from both > > > > > > Judith and Tim. I have a suspicion that it still might be faster > > > > > > and cheaper for ACES to go with OCSP, rather than try to stick to > > > > > > a non-standard protocol. > > > > > > > > > > > > Regards, > > > > > > Ambarish > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > Ambarish Malpani > > > > > > Architect 650.567.5457 > > > > > > ValiCert, Inc. ambarish@valicert.com > > > > > > 339 N. Bernardo Ave. http://www.valicert.com > > > > > > Mountain View, CA 94043 > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > > > > dosent seem to want to > > > > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > > > > programs)??". > > > > > > > You have to remember that ACES does have built in OCSP. The > > > > > > > product that they > > > > > > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > > > > > > > > > > > Please review the following URLs to see how and why Xcert was chosen: > > > > > > > > > > > > > > ACES announcement: > > > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > > > > > > > Reference to digital signature law: > > > > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > > > > > > > Sentry CA functionality: > > > > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > > > > > > > this is very interexting, can somebody please comment on > > > > > > > why the US govt > > > > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > > > > they call it sems > > > > > > > > to be an alternative mechanism....a duplication of much of > > > > > > > the work OCSP has > > > > > > > > already worked through... > > > > > > > > > > > > > > > > -j > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > > > > To: ietf-pkix@imc.org > > > > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > > > > > > > Terri suggests that the real significance of the > > > > > > > certificate and smart card > > > > > > > > used by President Clinton is that they were obtained > > > > > > > through the Access > > > > > > > > Certificates for Electronic Services (ACES) contract at > > > > > > > GSA. Through the > > > > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > > > > effectively a parser > > > > > > > > and validation tool (offered to public domain by GSA), > > > > > > > multiple CA's are > > > > > > > > made available to the government applications. > > > > > > > > > > > > > > > > More info at > > > > > > > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > > > > > > > To me, though, the most significant thing is that the > > > > > > > E-Sign bill was > > > > > > > > signed, regardless of the technology utilized. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > From owner-ietf-pkix@imc.org Wed Aug 23 11:52:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15806 for ; Wed, 23 Aug 2000 11:52:02 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA29631; Wed, 23 Aug 2000 08:51:13 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 08:50:40 -0700 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29591 for ; Wed, 23 Aug 2000 08:50:39 -0700 (PDT) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0FZR009015D0KT@ext-mail.valicert.com> for ietf-pkix@imc.org; Wed, 23 Aug 2000 08:51:00 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0FZR008J65D0QP@ext-mail.valicert.com>; Wed, 23 Aug 2000 08:51:00 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 08:40:53 -0700 Content-return: allowed Date: Wed, 23 Aug 2000 08:40:49 -0700 From: Ambarish Malpani Subject: RE: President Clinton digital signing To: "'Liaquat Khan'" , ietf-pkix@imc.org, "'tstrickland@xcert.com'" Message-id: <27FF4FAEA8CDD211B97E00902745CBE201B83116@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hi Liaquat, CRLs *don't* have to only be issued periodically. It is perfectly reasonable to issue new CRLs on demand (i.e. whenever a new revocation even happens) in addition to issuing the regular periodic CRLs. Regards, Ambarish Hi Tom, I am not sure I buy the DoS attack. There are a few ways around it: a. Make sure the OCSP server and CA are both behind a firewall with a fat pipe between them. b. You can have the OCSP server ping the CRL database periodically and stop responding if it can't reach it within say a 5 second interval. This still allows you to ensure that you have the latest data (within 5 seconds), but still allows you to process pretty large numbers of OCSP requests. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Liaquat Khan [mailto:liaquat.khan@gta.multicert.org] > Sent: Wednesday, August 23, 2000 7:00 AM > To: ietf-pkix@imc.org > Subject: Re: President Clinton digital signing > > > Tom, > > I generally agree with you, but I think the issue of > launching a DoS attack > on CRLs has been mixed in with the periodic nature of CRLs. > There are two > separate risks: > > 1) a CRL has expired and a new one has not been generated in > time (e.g. due > to a DoS attack). In this case the relying party should not > really depend > on the CRL as it should be obvious from reading the available > CRL that it is > out of date. Therefore, certificates may have been revoked > in the meantime > but there is no fresh CRL to check, so you abort the > transaction. This is > DoS. > > 2) a certificate is revoked but the next CRL is not due to be > issued until > later. Therefore, this scenario is not related to a DoS attack. To > overcome this you need to ensure that CRLs are issued with a > frequency which > is acceptable. By using OCSP, it doesn't necessarily mean > this issue goes > away...you will still need to work out how long it will take > from the time a > decision is made to revoke a certificate to the time that the > OCSP server > becomes aware of this (e.g. note that the OCSP server may be fed using > periodic CRLs). > > Regards, > Liaquat Khan > Technical Manager > Global Trust Authority (GTA) > > > > A relying > ----- Original Message ----- > From: Tom Strickland > To: Liaquat Khan > Cc: > Sent: Wednesday, August 23, 2000 1:31 PM > Subject: Re: President Clinton digital signing > > > > Liaquat, > > > > You bring up a very good point, DoS attacks are a risk in each > environment. > > However if your environment has critical need for current > data (such as a > bank > > or government), then a CRL has a higher risk. > > > > Example: If a company does not have a requirement for > current information, > a CRL > > is sufficient. If a company requires real time data (i.e. a bank or > government) > > due to high value transactions or security, then I would > highly recommend > OCSP. > > The risk is if you use CRLs for the latter, the company may > get a false > sense of > > security believing their "high value" transactions are > guarded by real > time > > data. If the batch CRL is latent, you may continue > processing utilizing > old > > data. The risk is a cert believed to be revoked may still > be considered > good in > > the system exposing the company to potential fraud or negligence. > > > > In an OCSP environment, if you must trust real time data and someone > executes a > > DoS attack, the responder may slow down or worst case, stop > working. This > is an > > added value because I would rather slow down or stop > processing than to > rely on > > old data. The risk here is slower response time but > guaranteed accurate > > information. > > > > This is a question that each company must answer by > performing a risk > assessment > > to determine their acceptable level of "pain", risk and exposure. > > > > I am not trying to be confrontational in my recent > "typings". I am just > trying > > to bring added value to everyone here. As an auditor that > has performed > audits > > on several PKI environments, I am just trying to help > elevate certain > risks that > > sometimes get overlooked. > > > > Best regards, > > > > Tom > > > > Liaquat Khan wrote: > > > > > You have to assume that access to the server which issues CRLs is > protected > > > from denial of service attacks. For example, generally > only trusted > > > operators can authorise the generation of CRLs, after having their > > > identities authenticated by the server. Also access to > the CRL issuer > has > > > to be protected through firewalls, etc. > > > > > > If an attacker can perform a DoS attack on a CRL issuer, > what is there > to > > > stop him/her launching a similar attack on an OCSP server (e.g. by > issuing > > > an extremely large amount of OCSP requests)? > > > > > > Regards, > > > Liaquat Khan > > > Technical Manager > > > Global Trust Authority (GTA) > > > > > > ----- Original Message ----- > > > From: Tom Strickland > > > To: Ambarish Malpani > > > Cc: ; > > > Sent: Wednesday, August 23, 2000 5:11 AM > > > Subject: Re: President Clinton digital signing > > > > > > > Hello Ambarish, > > > > > > > > Thanks for your reply. I agree that OCSP services are > by far better > than > > > > CRLs. In general, as everyone knows, a CRL is a batch > job that updates > a > > > > database over certain intervals. From an audit > standpoint, one of the > many > > > > issues with CRLs is that they can be beat. For example, > it is very > easy to > > > > perform any series of denial of service attacks against > the server. > This > > > > could cause longer than expected delays in the > execution of the batch > job > > > > or worse, prevent the batch job from running causing latent (or > corrupted) > > > > CRL publishing. Also, if someone is savvy enough, they > could also > issue > > > > hundreds of back to back CRL job requests resulting in > multiple jobs > > > > waiting on shared services again causing problematic > CRLs. I know this > may > > > > sound farfetched but they are risks to be considered. > > > > > > > > As you may guess I am not a proponent of CRLs for > obvious reasons. I > have > > > > heard claims by some that their products are OCSP compliant. In > reality it > > > > is just a batch job publishing to a database but still they have > inherent > > > > CRL batch job latency. > > > > > > > > As for the CAM, I am not familiar enough with that to > argue for or > against > > > > its use. I do know however that the Xcert product has a non > proprietary > > > > real time OCSP LDAP out of the box resulting in a more > robust product. > > > Note > > > > that the Sentry CA product can publish CRLs to non OCSP > products to > offer > > > > backwards compatibility when needed. Also, the Sentry > product can > import > > > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > > > > > Also one of the several reasons that Sentry CA was > chosen was due to > its > > > > ability to cross certify against other CAs (cross > certification). It > is > > > > very easy to setup trust to another company's CA > allowing multiple CAs > or > > > > PKI vendors within a central Sentry OCSP environment. > > > > > > > > Best regards, > > > > > > > > Tom > > > > > > > > > > > > Ambarish Malpani wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > > > create a new CRL whenever a new revocation happens. > > > > > > > > > > Think of this CRL as a snapshot of the CA's > revocation database > > > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > > > server that the snapshot has changed. > > > > > > > > > > Really, an OCSP server can be set up to be as current > as any other > > > > > software to provide revocation information, either > with or without > > > > > CRLs. > > > > > > > > > > It is completely unclear to me why the CAM solution is any > > > > > more real time than OCSP. I believe the real reason for the > > > > > CAM solution was just that OCSP didn't exist as a > standard till > > > > > late in the ACES project as indicated by the mails from both > > > > > Judith and Tim. I have a suspicion that it still > might be faster > > > > > and cheaper for ACES to go with OCSP, rather than try > to stick to > > > > > a non-standard protocol. > > > > > > > > > > Regards, > > > > > Ambarish > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > Ambarish Malpani > > > > > Architect > 650.567.5457 > > > > > ValiCert, Inc. > ambarish@valicert.com > > > > > 339 N. Bernardo Ave. > http://www.valicert.com > > > > > Mountain View, CA 94043 > > > > > > > > > > > -----Original Message----- > > > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > > > dosent seem to want to > > > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > > > programs)??". > > > > > > You have to remember that ACES does have built in OCSP. The > > > > > > product that they > > > > > > chose includes an OCSP "real time" responder, not > antiquated CRLs. > > > > > > > > > > > > Please review the following URLs to see how and why > Xcert was > chosen: > > > > > > > > > > > > ACES announcement: > > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > > > Reference to digital signature law: > > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > > > Sentry CA functionality: > > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > > > this is very interexting, can somebody please comment on > > > > > why the US govt > > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > > they call it sems > > > > > > to be an alternative mechanism....a duplication of much of > > > > > the work OCSP has > > > > > > already worked through... > > > > > > > > > > > > -j > > > > > > > > > > > > -----Original Message----- > > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > > To: ietf-pkix@imc.org > > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > > > Terri suggests that the real significance of the > > > > > certificate and smart card > > > > > > used by President Clinton is that they were obtained > > > > > through the Access > > > > > > Certificates for Electronic Services (ACES) contract at > > > > > GSA. Through the > > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > > effectively a parser > > > > > > and validation tool (offered to public domain by GSA), > > > > > multiple CA's are > > > > > > made available to the government applications. > > > > > > > > > > > > More info at > > > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > > > To me, though, the most significant thing is that the > > > > > E-Sign bill was > > > > > > signed, regardless of the technology utilized. > > > > > > > > > > > > Cheers, > > > > > > > > > From owner-ietf-pkix@imc.org Wed Aug 23 12:19:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17462 for ; Wed, 23 Aug 2000 12:19:36 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA02141; Wed, 23 Aug 2000 09:18:41 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 09:18:37 -0700 Received: from crack.x509.com (root@crack.x509.com [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02098 for ; Wed, 23 Aug 2000 09:18:36 -0700 (PDT) Received: from xcert.com (home.x509.com [199.175.150.4]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e7NGItS15454; Wed, 23 Aug 2000 09:18:55 -0700 (PDT) Message-ID: <39A3FA4C.8AD321EE@xcert.com> Date: Wed, 23 Aug 2000 12:22:36 -0400 From: Tom Strickland X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Liaquat Khan CC: ietf-pkix@imc.org Subject: Re: President Clinton digital signing References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> <001c01c00cde$64c6d840$68bc01d5@vaio> <39A3C410.72912219@xcert.com> <39A3C6A0.6C3452C0@mitre.org> <39A3CFA2.8A6C9EFD@xcert.com> <005001c00d14$81ca4e00$ed3863c3@vaio> Content-Type: multipart/mixed; boundary="------------9EAA4070E2095006216FFD92" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. --------------9EAA4070E2095006216FFD92 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Liaquat, Yes it is a good idea to save CRL data for historical purposes. My two cents, for high availability cert checking, I would want to rely on an OCSP SSL-LDAP instead of a CRL. In a "best case" high availability OCSP environment, it would be even better to have a mirror image server backing up the SSL-LDAP in real time. While this is not needed (due to cost) by everyone, once again this depends on a company's risk assessment. Liaquat Khan wrote: > Tom, > > Isn't it a good idea to generate CRLs anyway, even if you are using OCSP? > The main reason I have in mind is so that the CRL acts as a historical > record of when the certificate was revoked. > On the other hand, an OCSP response would only be sent subsequent to > receiving an appropriate OCSP request message. > > Regards, > Liaquat Khan > Technical Manager > Global Trust Authority (GTA) > > ----- Original Message ----- > From: Tom Strickland > To: Sam Schaen > Cc: Liaquat Khan ; > Sent: Wednesday, August 23, 2000 2:20 PM > Subject: Re: President Clinton digital signing > > > If you are using a mixture or hybrid OCSP environment to perform checking > with an import > > of CRL data, yes the result could be the same. > > > > However, if you are using a true OCSP LDAP environment (i.e. no CRLs), > part of your > > system may slow down due to the DoS but the validity would always be > accurate. > > > > In the Sentry product, each Registration Authority (RA) has a built in > real time OCSP > > LDAP. This allows a complete OCSP enterprise without the need for any CRLs > (unless you > > want to cross certify a CRL from other non OCSP PKI vendors). This means > that your risk > > of DoS attacks may only slow down one leg (RA) or department of your PKI > environment, > > not the whole enterprise ensuring accurate real time information. > > > > Sam Schaen wrote: > > > > > If the DoS prevents the OCSP responder from receiving a CRL from which > it determines > > > validity status, the result is the same. > > > > > > Tom Strickland wrote: > > > > > > > Liaquat, > > > > > > > > You bring up a very good point, DoS attacks are a risk in each > environment. > > > > However if your environment has critical need for current data (such > as a bank > > > > or government), then a CRL has a higher risk. > > > > > > > > Example: If a company does not have a requirement for current > information, a CRL > > > > is sufficient. If a company requires real time data (i.e. a bank or > government) > > > > due to high value transactions or security, then I would highly > recommend OCSP. > > > > The risk is if you use CRLs for the latter, the company may get a > false sense of > > > > security believing their "high value" transactions are guarded by real > time > > > > data. If the batch CRL is latent, you may continue processing > utilizing old > > > > data. The risk is a cert believed to be revoked may still be > considered good in > > > > the system exposing the company to potential fraud or negligence. > > > > > > > > In an OCSP environment, if you must trust real time data and someone > executes a > > > > DoS attack, the responder may slow down or worst case, stop working. > This is an > > > > added value because I would rather slow down or stop processing than > to rely on > > > > old data. The risk here is slower response time but guaranteed > accurate > > > > information. > > > > > > > > This is a question that each company must answer by performing a risk > assessment > > > > to determine their acceptable level of "pain", risk and exposure. > > > > > > > > I am not trying to be confrontational in my recent "typings". I am > just trying > > > > to bring added value to everyone here. As an auditor that has > performed audits > > > > on several PKI environments, I am just trying to help elevate certain > risks that > > > > sometimes get overlooked. > > > > > > > > Best regards, > > > > > > > > Tom > > > > > > > > Liaquat Khan wrote: > > > > > > > > > You have to assume that access to the server which issues CRLs is > protected > > > > > from denial of service attacks. For example, generally only trusted > > > > > operators can authorise the generation of CRLs, after having their > > > > > identities authenticated by the server. Also access to the CRL > issuer has > > > > > to be protected through firewalls, etc. > > > > > > > > > > If an attacker can perform a DoS attack on a CRL issuer, what is > there to > > > > > stop him/her launching a similar attack on an OCSP server (e.g. by > issuing > > > > > an extremely large amount of OCSP requests)? > > > > > > > > > > Regards, > > > > > Liaquat Khan > > > > > Technical Manager > > > > > Global Trust Authority (GTA) > > > > > > > > > > ----- Original Message ----- > > > > > From: Tom Strickland > > > > > To: Ambarish Malpani > > > > > Cc: ; > > > > > Sent: Wednesday, August 23, 2000 5:11 AM > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > Hello Ambarish, > > > > > > > > > > > > Thanks for your reply. I agree that OCSP services are by far > better than > > > > > > CRLs. In general, as everyone knows, a CRL is a batch job that > updates a > > > > > > database over certain intervals. From an audit standpoint, one of > the many > > > > > > issues with CRLs is that they can be beat. For example, it is very > easy to > > > > > > perform any series of denial of service attacks against the > server. This > > > > > > could cause longer than expected delays in the execution of the > batch job > > > > > > or worse, prevent the batch job from running causing latent (or > corrupted) > > > > > > CRL publishing. Also, if someone is savvy enough, they could also > issue > > > > > > hundreds of back to back CRL job requests resulting in multiple > jobs > > > > > > waiting on shared services again causing problematic CRLs. I know > this may > > > > > > sound farfetched but they are risks to be considered. > > > > > > > > > > > > As you may guess I am not a proponent of CRLs for obvious reasons. > I have > > > > > > heard claims by some that their products are OCSP compliant. In > reality it > > > > > > is just a batch job publishing to a database but still they have > inherent > > > > > > CRL batch job latency. > > > > > > > > > > > > As for the CAM, I am not familiar enough with that to argue for or > against > > > > > > its use. I do know however that the Xcert product has a non > proprietary > > > > > > real time OCSP LDAP out of the box resulting in a more robust > product. > > > > > Note > > > > > > that the Sentry CA product can publish CRLs to non OCSP products > to offer > > > > > > backwards compatibility when needed. Also, the Sentry product can > import > > > > > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > > > > > > > > > Also one of the several reasons that Sentry CA was chosen was due > to its > > > > > > ability to cross certify against other CAs (cross certification). > It is > > > > > > very easy to setup trust to another company's CA allowing multiple > CAs or > > > > > > PKI vendors within a central Sentry OCSP environment. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Tom > > > > > > > > > > > > > > > > > > Ambarish Malpani wrote: > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > > > > > create a new CRL whenever a new revocation happens. > > > > > > > > > > > > > > Think of this CRL as a snapshot of the CA's revocation database > > > > > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > > > > > server that the snapshot has changed. > > > > > > > > > > > > > > Really, an OCSP server can be set up to be as current as any > other > > > > > > > software to provide revocation information, either with or > without > > > > > > > CRLs. > > > > > > > > > > > > > > It is completely unclear to me why the CAM solution is any > > > > > > > more real time than OCSP. I believe the real reason for the > > > > > > > CAM solution was just that OCSP didn't exist as a standard till > > > > > > > late in the ACES project as indicated by the mails from both > > > > > > > Judith and Tim. I have a suspicion that it still might be faster > > > > > > > and cheaper for ACES to go with OCSP, rather than try to stick > to > > > > > > > a non-standard protocol. > > > > > > > > > > > > > > Regards, > > > > > > > Ambarish > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > Ambarish Malpani > > > > > > > Architect > 650.567.5457 > > > > > > > ValiCert, Inc. > ambarish@valicert.com > > > > > > > 339 N. Bernardo Ave. > http://www.valicert.com > > > > > > > Mountain View, CA 94043 > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > > > > > dosent seem to want to > > > > > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > > > > > programs)??". > > > > > > > > You have to remember that ACES does have built in OCSP. The > > > > > > > > product that they > > > > > > > > chose includes an OCSP "real time" responder, not antiquated > CRLs. > > > > > > > > > > > > > > > > Please review the following URLs to see how and why Xcert was > chosen: > > > > > > > > > > > > > > > > ACES announcement: > > > > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > > > > > > > > > Reference to digital signature law: > > > > > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > > > > > > > > > Sentry CA functionality: > > > > > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > > > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > > > > > > > > > this is very interexting, can somebody please comment on > > > > > > > > why the US govt > > > > > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a > validation > > > > > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > > > > > they call it sems > > > > > > > > > to be an alternative mechanism....a duplication of much of > > > > > > > > the work OCSP has > > > > > > > > > already worked through... > > > > > > > > > > > > > > > > > > -j > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > > > > > To: ietf-pkix@imc.org > > > > > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > > > > > > > > > Terri suggests that the real significance of the > > > > > > > > certificate and smart card > > > > > > > > > used by President Clinton is that they were obtained > > > > > > > > through the Access > > > > > > > > > Certificates for Electronic Services (ACES) contract at > > > > > > > > GSA. Through the > > > > > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > > > > > effectively a parser > > > > > > > > > and validation tool (offered to public domain by GSA), > > > > > > > > multiple CA's are > > > > > > > > > made available to the government applications. > > > > > > > > > > > > > > > > > > More info at > > > > > > > > > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > > > > > > > > > To me, though, the most significant thing is that the > > > > > > > > E-Sign bill was > > > > > > > > > signed, regardless of the technology utilized. > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > --------------9EAA4070E2095006216FFD92 Content-Type: text/x-vcard; charset=us-ascii; name="tstrickland.vcf" Content-Description: Card for Tom Strickland Content-Disposition: attachment; filename="tstrickland.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Strickland;Tom tel;cell:678 296-4866 x-mozilla-html:TRUE org:
Xcert International Inc. adr:;;;;;; version:2.1 email;internet:tstrickland@xcert.com fn:Tom Strickland end:vcard --------------9EAA4070E2095006216FFD92-- From owner-ietf-pkix@imc.org Wed Aug 23 12:37:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18007 for ; Wed, 23 Aug 2000 12:37:02 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA03573; Wed, 23 Aug 2000 09:36:20 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 09:36:14 -0700 Received: from serv1.is1.u-net.net (serv1.is1.u-net.net [195.102.240.129]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03542 for ; Wed, 23 Aug 2000 09:36:12 -0700 (PDT) Received: from [195.232.106.167] (helo=dwc-acer) by serv1.is1.u-net.net with esmtp (Exim 3.12 #1) id 13RdVs-0002o4-00; Wed, 23 Aug 2000 17:36:29 +0100 From: "David Chadwick" Organization: University of Salford To: ietf-pkix@imc.org Date: Wed, 23 Aug 2000 17:35:40 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Undefined combinations of extensions Reply-to: d.w.chadwick@salford.ac.uk CC: "Kurt D. Zeilenga" , osidirectory@az05.bull.com Message-ID: <39A40B6C.20716.17FCDF7@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12c) Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7BIT On the LDAPExt list we have been discussing the effects of combinations of extensions (controls in LDAP jargon) on the LDAP server performing an LDAP operation, when the effects of the combination of one or more extensions is not understood by the server. The server may understand each separate extension, but not the semantics of them in combination. It seems to me that PKIX/X.509 will have (or already may have encountered) this same problem for COMBINATIONS of certificate extensions (some of which may be private, some de-facto, some critical, some not) that are thought to be understood by the issuing CA, but are not fully understood by the relying party / validation engine. What text does anyone have for this situation? I believe the recently issued X.509 defect report 244, raised by Sharon, only discusses the case of a single extension in isolation, and does not discuss the effects of combinations of extensions. The most interesting cases are when the RP finds combinations of extensions, where each extension on its own is understood, but where the combined semantics are not fully understood (possibly due to incomplete or ambiguous specification of extension interactions when the extensions are written by different groups). In this case, LDAP is suggesting that a receiver may ignore non- critical extensions (even those it recognizes) to establish the semantics of the operation. This is in direct contrast to the wording of defect report 244, which states that an understood non-critical extension must be obeyed. The LDAP work would suggest an addition to DR244 along the lines of " A validation engine that does not understand the interaction of a non-critical extension with another extension (critical or non-critical), may ignore the non-critical extension (even if it understands the semantics of the extension in isolation to the others), and accept the certificate (unless factors other than this extension cause it to be rejected). A validation engine that does not understand the interaction of two critical extensions, must reject the certificate (even if it understands the semantics of both extensions in isolation to each other)." David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From owner-ietf-pkix@imc.org Wed Aug 23 12:41:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18116 for ; Wed, 23 Aug 2000 12:41:53 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA04179; Wed, 23 Aug 2000 09:41:07 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 09:41:05 -0700 Received: from crack.x509.com (root@crack.x509.com [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA04145 for ; Wed, 23 Aug 2000 09:41:04 -0700 (PDT) Received: from xcert.com (home.x509.com [199.175.150.4]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e7NGfQS16832; Wed, 23 Aug 2000 09:41:26 -0700 (PDT) Message-ID: <39A3FF92.A556AE47@xcert.com> Date: Wed, 23 Aug 2000 12:45:07 -0400 From: Tom Strickland X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Liaquat Khan CC: ietf-pkix@imc.org Subject: Re: President Clinton digital signing References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> <001c01c00cde$64c6d840$68bc01d5@vaio> <39A3C410.72912219@xcert.com> <002b01c00d0a$7ef392e0$ed3863c3@vaio> Content-Type: multipart/mixed; boundary="------------1682A732A9CBD0CA1EED02F1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. --------------1682A732A9CBD0CA1EED02F1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Liaquat Khan wrote: > Tom, > > I generally agree with you, but I think the issue of launching a DoS attack > on CRLs has been mixed in with the periodic nature of CRLs. There are two > separate risks: > > 1) a CRL has expired and a new one has not been generated in time (e.g. due > to a DoS attack). In this case the relying party should not really depend > on the CRL as it should be obvious from reading the available CRL that it is > out of date. Therefore, certificates may have been revoked in the meantime > but there is no fresh CRL to check, so you abort the transaction. This is > DoS. I agree. However in several audit reviews of PKI infrastructures, I have always seen the most recent CRL utilized as "good" regardless of the age. If all enterprises mitigated this risk by checking and aborting transactions according to age restrictions, this would be an adequate practice (until OCSP was the standard, not the exception.) > > > 2) a certificate is revoked but the next CRL is not due to be issued until > later. Therefore, this scenario is not related to a DoS attack. To > overcome this you need to ensure that CRLs are issued with a frequency which > is acceptable. By using OCSP, it doesn't necessarily mean this issue goes > away...you will still need to work out how long it will take from the time a > decision is made to revoke a certificate to the time that the OCSP server > becomes aware of this (e.g. note that the OCSP server may be fed using > periodic CRLs). Once again you are correct. However "certain PKI products" have the OCSP SSL-LDAP server integrated within the CA and RA. This ensures that once the cert is revoked or suspended, the next instance that it is checked for validity (even within seconds), it gives an accurate reflection of status without latency. Best regards, Tom > > > Regards, > Liaquat Khan > Technical Manager > Global Trust Authority (GTA) > > A relying > ----- Original Message ----- > From: Tom Strickland > To: Liaquat Khan > Cc: > Sent: Wednesday, August 23, 2000 1:31 PM > Subject: Re: President Clinton digital signing > > > Liaquat, > > > > You bring up a very good point, DoS attacks are a risk in each > environment. > > However if your environment has critical need for current data (such as a > bank > > or government), then a CRL has a higher risk. > > > > Example: If a company does not have a requirement for current information, > a CRL > > is sufficient. If a company requires real time data (i.e. a bank or > government) > > due to high value transactions or security, then I would highly recommend > OCSP. > > The risk is if you use CRLs for the latter, the company may get a false > sense of > > security believing their "high value" transactions are guarded by real > time > > data. If the batch CRL is latent, you may continue processing utilizing > old > > data. The risk is a cert believed to be revoked may still be considered > good in > > the system exposing the company to potential fraud or negligence. > > > > In an OCSP environment, if you must trust real time data and someone > executes a > > DoS attack, the responder may slow down or worst case, stop working. This > is an > > added value because I would rather slow down or stop processing than to > rely on > > old data. The risk here is slower response time but guaranteed accurate > > information. > > > > This is a question that each company must answer by performing a risk > assessment > > to determine their acceptable level of "pain", risk and exposure. > > > > I am not trying to be confrontational in my recent "typings". I am just > trying > > to bring added value to everyone here. As an auditor that has performed > audits > > on several PKI environments, I am just trying to help elevate certain > risks that > > sometimes get overlooked. > > > > Best regards, > > > > Tom > > > > Liaquat Khan wrote: > > > > > You have to assume that access to the server which issues CRLs is > protected > > > from denial of service attacks. For example, generally only trusted > > > operators can authorise the generation of CRLs, after having their > > > identities authenticated by the server. Also access to the CRL issuer > has > > > to be protected through firewalls, etc. > > > > > > If an attacker can perform a DoS attack on a CRL issuer, what is there > to > > > stop him/her launching a similar attack on an OCSP server (e.g. by > issuing > > > an extremely large amount of OCSP requests)? > > > > > > Regards, > > > Liaquat Khan > > > Technical Manager > > > Global Trust Authority (GTA) > > > > > > ----- Original Message ----- > > > From: Tom Strickland > > > To: Ambarish Malpani > > > Cc: ; > > > Sent: Wednesday, August 23, 2000 5:11 AM > > > Subject: Re: President Clinton digital signing > > > > > > > Hello Ambarish, > > > > > > > > Thanks for your reply. I agree that OCSP services are by far better > than > > > > CRLs. In general, as everyone knows, a CRL is a batch job that updates > a > > > > database over certain intervals. From an audit standpoint, one of the > many > > > > issues with CRLs is that they can be beat. For example, it is very > easy to > > > > perform any series of denial of service attacks against the server. > This > > > > could cause longer than expected delays in the execution of the batch > job > > > > or worse, prevent the batch job from running causing latent (or > corrupted) > > > > CRL publishing. Also, if someone is savvy enough, they could also > issue > > > > hundreds of back to back CRL job requests resulting in multiple jobs > > > > waiting on shared services again causing problematic CRLs. I know this > may > > > > sound farfetched but they are risks to be considered. > > > > > > > > As you may guess I am not a proponent of CRLs for obvious reasons. I > have > > > > heard claims by some that their products are OCSP compliant. In > reality it > > > > is just a batch job publishing to a database but still they have > inherent > > > > CRL batch job latency. > > > > > > > > As for the CAM, I am not familiar enough with that to argue for or > against > > > > its use. I do know however that the Xcert product has a non > proprietary > > > > real time OCSP LDAP out of the box resulting in a more robust product. > > > Note > > > > that the Sentry CA product can publish CRLs to non OCSP products to > offer > > > > backwards compatibility when needed. Also, the Sentry product can > import > > > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > > > > > Also one of the several reasons that Sentry CA was chosen was due to > its > > > > ability to cross certify against other CAs (cross certification). It > is > > > > very easy to setup trust to another company's CA allowing multiple CAs > or > > > > PKI vendors within a central Sentry OCSP environment. > > > > > > > > Best regards, > > > > > > > > Tom > > > > > > > > > > > > Ambarish Malpani wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > > > create a new CRL whenever a new revocation happens. > > > > > > > > > > Think of this CRL as a snapshot of the CA's revocation database > > > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > > > server that the snapshot has changed. > > > > > > > > > > Really, an OCSP server can be set up to be as current as any other > > > > > software to provide revocation information, either with or without > > > > > CRLs. > > > > > > > > > > It is completely unclear to me why the CAM solution is any > > > > > more real time than OCSP. I believe the real reason for the > > > > > CAM solution was just that OCSP didn't exist as a standard till > > > > > late in the ACES project as indicated by the mails from both > > > > > Judith and Tim. I have a suspicion that it still might be faster > > > > > and cheaper for ACES to go with OCSP, rather than try to stick to > > > > > a non-standard protocol. > > > > > > > > > > Regards, > > > > > Ambarish > > > > > > > > > > > --------------------------------------------------------------------- > > > > > Ambarish Malpani > > > > > Architect > 650.567.5457 > > > > > ValiCert, Inc. > ambarish@valicert.com > > > > > 339 N. Bernardo Ave. > http://www.valicert.com > > > > > Mountain View, CA 94043 > > > > > > > > > > > -----Original Message----- > > > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > > > dosent seem to want to > > > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > > > programs)??". > > > > > > You have to remember that ACES does have built in OCSP. The > > > > > > product that they > > > > > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > > > > > > > > > Please review the following URLs to see how and why Xcert was > chosen: > > > > > > > > > > > > ACES announcement: > > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > > > > > Reference to digital signature law: > > > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > > > > > Sentry CA functionality: > > > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > > > > > this is very interexting, can somebody please comment on > > > > > > why the US govt > > > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a > validation > > > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > > > they call it sems > > > > > > > to be an alternative mechanism....a duplication of much of > > > > > > the work OCSP has > > > > > > > already worked through... > > > > > > > > > > > > > > -j > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > > > To: ietf-pkix@imc.org > > > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > > > > > Terri suggests that the real significance of the > > > > > > certificate and smart card > > > > > > > used by President Clinton is that they were obtained > > > > > > through the Access > > > > > > > Certificates for Electronic Services (ACES) contract at > > > > > > GSA. Through the > > > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > > > effectively a parser > > > > > > > and validation tool (offered to public domain by GSA), > > > > > > multiple CA's are > > > > > > > made available to the government applications. > > > > > > > > > > > > > > More info at > > > > > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > > > > > To me, though, the most significant thing is that the > > > > > > E-Sign bill was > > > > > > > signed, regardless of the technology utilized. > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > --------------1682A732A9CBD0CA1EED02F1 Content-Type: text/x-vcard; charset=us-ascii; name="tstrickland.vcf" Content-Description: Card for Tom Strickland Content-Disposition: attachment; filename="tstrickland.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Strickland;Tom tel;cell:678 296-4866 x-mozilla-html:TRUE org:
Xcert International Inc. adr:;;;;;; version:2.1 email;internet:tstrickland@xcert.com fn:Tom Strickland end:vcard --------------1682A732A9CBD0CA1EED02F1-- From owner-ietf-pkix@imc.org Wed Aug 23 12:46:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18238 for ; Wed, 23 Aug 2000 12:46:08 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA04550; Wed, 23 Aug 2000 09:44:54 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 09:44:50 -0700 Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA04520 for ; Wed, 23 Aug 2000 09:44:48 -0700 (PDT) Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 12:44:25 -0400 Message-ID: From: Khaja Ahmed To: "'Liaquat Khan'" , ietf-pkix@imc.org Subject: RE: President Clinton digital signing Date: Wed, 23 Aug 2000 12:44:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00D21.64BA2AB0" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C00D21.64BA2AB0 Content-Type: text/plain; charset="iso-8859-1" Liaquat, You are quite right. In fact, this is the easiest (perhaps only standard based) way of capturing authoritative snapshots that can then be used for archiving - for 7 yr record keeping requirements, etc. If a certificate was suspended for a week and during that period no OCSP request was made on the status of this certificate you would still have a record of this in archives. This can be invaluable for future dispute resolution proceedings for example. For this reason many PKIs mandate that CRLs be generated on every revocation event in addition to periodic CRL publishing. Khaja =========================================== Khaja E. Ahmed Chief Technology Officer Identrus, LLC. 16th Floor 140 E 45th St. New York, NY 10017 USA Telephone: 01.212.622.0673 Fax: 01.212.622.9196 Khaja.ahmed@identrus.com Cell Phone: 01.925.989.6564 Home office: 01.925.462.0453 ============================================ -----Original Message----- From: Liaquat Khan [mailto:liaquat.khan@gta.multicert.org] Sent: Wednesday, August 23, 2000 8:02 AM To: ietf-pkix@imc.org Subject: Re: President Clinton digital signing Tom, Isn't it a good idea to generate CRLs anyway, even if you are using OCSP? The main reason I have in mind is so that the CRL acts as a historical record of when the certificate was revoked. On the other hand, an OCSP response would only be sent subsequent to receiving an appropriate OCSP request message. Regards, Liaquat Khan Technical Manager Global Trust Authority (GTA) ----- Original Message ----- From: Tom Strickland To: Sam Schaen Cc: Liaquat Khan ; Sent: Wednesday, August 23, 2000 2:20 PM Subject: Re: President Clinton digital signing > If you are using a mixture or hybrid OCSP environment to perform checking with an import > of CRL data, yes the result could be the same. > > However, if you are using a true OCSP LDAP environment (i.e. no CRLs), part of your > system may slow down due to the DoS but the validity would always be accurate. > > In the Sentry product, each Registration Authority (RA) has a built in real time OCSP > LDAP. This allows a complete OCSP enterprise without the need for any CRLs (unless you > want to cross certify a CRL from other non OCSP PKI vendors). This means that your risk > of DoS attacks may only slow down one leg (RA) or department of your PKI environment, > not the whole enterprise ensuring accurate real time information. > > Sam Schaen wrote: > > > If the DoS prevents the OCSP responder from receiving a CRL from which it determines > > validity status, the result is the same. > > > > Tom Strickland wrote: > > > > > Liaquat, > > > > > > You bring up a very good point, DoS attacks are a risk in each environment. > > > However if your environment has critical need for current data (such as a bank > > > or government), then a CRL has a higher risk. > > > > > > Example: If a company does not have a requirement for current information, a CRL > > > is sufficient. If a company requires real time data (i.e. a bank or government) > > > due to high value transactions or security, then I would highly recommend OCSP. > > > The risk is if you use CRLs for the latter, the company may get a false sense of > > > security believing their "high value" transactions are guarded by real time > > > data. If the batch CRL is latent, you may continue processing utilizing old > > > data. The risk is a cert believed to be revoked may still be considered good in > > > the system exposing the company to potential fraud or negligence. > > > > > > In an OCSP environment, if you must trust real time data and someone executes a > > > DoS attack, the responder may slow down or worst case, stop working. This is an > > > added value because I would rather slow down or stop processing than to rely on > > > old data. The risk here is slower response time but guaranteed accurate > > > information. > > > > > > This is a question that each company must answer by performing a risk assessment > > > to determine their acceptable level of "pain", risk and exposure. > > > > > > I am not trying to be confrontational in my recent "typings". I am just trying > > > to bring added value to everyone here. As an auditor that has performed audits > > > on several PKI environments, I am just trying to help elevate certain risks that > > > sometimes get overlooked. > > > > > > Best regards, > > > > > > Tom > > > > > > Liaquat Khan wrote: > > > > > > > You have to assume that access to the server which issues CRLs is protected > > > > from denial of service attacks. For example, generally only trusted > > > > operators can authorise the generation of CRLs, after having their > > > > identities authenticated by the server. Also access to the CRL issuer has > > > > to be protected through firewalls, etc. > > > > > > > > If an attacker can perform a DoS attack on a CRL issuer, what is there to > > > > stop him/her launching a similar attack on an OCSP server (e.g. by issuing > > > > an extremely large amount of OCSP requests)? > > > > > > > > Regards, > > > > Liaquat Khan > > > > Technical Manager > > > > Global Trust Authority (GTA) > > > > > > > > ----- Original Message ----- > > > > From: Tom Strickland > > > > To: Ambarish Malpani > > > > Cc: ; > > > > Sent: Wednesday, August 23, 2000 5:11 AM > > > > Subject: Re: President Clinton digital signing > > > > > > > > > Hello Ambarish, > > > > > > > > > > Thanks for your reply. I agree that OCSP services are by far better than > > > > > CRLs. In general, as everyone knows, a CRL is a batch job that updates a > > > > > database over certain intervals. From an audit standpoint, one of the many > > > > > issues with CRLs is that they can be beat. For example, it is very easy to > > > > > perform any series of denial of service attacks against the server. This > > > > > could cause longer than expected delays in the execution of the batch job > > > > > or worse, prevent the batch job from running causing latent (or corrupted) > > > > > CRL publishing. Also, if someone is savvy enough, they could also issue > > > > > hundreds of back to back CRL job requests resulting in multiple jobs > > > > > waiting on shared services again causing problematic CRLs. I know this may > > > > > sound farfetched but they are risks to be considered. > > > > > > > > > > As you may guess I am not a proponent of CRLs for obvious reasons. I have > > > > > heard claims by some that their products are OCSP compliant. In reality it > > > > > is just a batch job publishing to a database but still they have inherent > > > > > CRL batch job latency. > > > > > > > > > > As for the CAM, I am not familiar enough with that to argue for or against > > > > > its use. I do know however that the Xcert product has a non proprietary > > > > > real time OCSP LDAP out of the box resulting in a more robust product. > > > > Note > > > > > that the Sentry CA product can publish CRLs to non OCSP products to offer > > > > > backwards compatibility when needed. Also, the Sentry product can import > > > > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > > > > > > > Also one of the several reasons that Sentry CA was chosen was due to its > > > > > ability to cross certify against other CAs (cross certification). It is > > > > > very easy to setup trust to another company's CA allowing multiple CAs or > > > > > PKI vendors within a central Sentry OCSP environment. > > > > > > > > > > Best regards, > > > > > > > > > > Tom > > > > > > > > > > > > > > > Ambarish Malpani wrote: > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > > > > create a new CRL whenever a new revocation happens. > > > > > > > > > > > > Think of this CRL as a snapshot of the CA's revocation database > > > > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > > > > server that the snapshot has changed. > > > > > > > > > > > > Really, an OCSP server can be set up to be as current as any other > > > > > > software to provide revocation information, either with or without > > > > > > CRLs. > > > > > > > > > > > > It is completely unclear to me why the CAM solution is any > > > > > > more real time than OCSP. I believe the real reason for the > > > > > > CAM solution was just that OCSP didn't exist as a standard till > > > > > > late in the ACES project as indicated by the mails from both > > > > > > Judith and Tim. I have a suspicion that it still might be faster > > > > > > and cheaper for ACES to go with OCSP, rather than try to stick to > > > > > > a non-standard protocol. > > > > > > > > > > > > Regards, > > > > > > Ambarish > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > Ambarish Malpani > > > > > > Architect 650.567.5457 > > > > > > ValiCert, Inc. ambarish@valicert.com > > > > > > 339 N. Bernardo Ave. http://www.valicert.com > > > > > > Mountain View, CA 94043 > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > > > > dosent seem to want to > > > > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > > > > programs)??". > > > > > > > You have to remember that ACES does have built in OCSP. The > > > > > > > product that they > > > > > > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > > > > > > > > > > > Please review the following URLs to see how and why Xcert was chosen: > > > > > > > > > > > > > > ACES announcement: > > > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > > > > > > > Reference to digital signature law: > > > > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > > > > > > > Sentry CA functionality: > > > > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > > > > > > > this is very interexting, can somebody please comment on > > > > > > > why the US govt > > > > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > > > > they call it sems > > > > > > > > to be an alternative mechanism....a duplication of much of > > > > > > > the work OCSP has > > > > > > > > already worked through... > > > > > > > > > > > > > > > > -j > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > > > > To: ietf-pkix@imc.org > > > > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > > > > > > > Terri suggests that the real significance of the > > > > > > > certificate and smart card > > > > > > > > used by President Clinton is that they were obtained > > > > > > > through the Access > > > > > > > > Certificates for Electronic Services (ACES) contract at > > > > > > > GSA. Through the > > > > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > > > > effectively a parser > > > > > > > > and validation tool (offered to public domain by GSA), > > > > > > > multiple CA's are > > > > > > > > made available to the government applications. > > > > > > > > > > > > > > > > More info at > > > > > > > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > > > > > > > To me, though, the most significant thing is that the > > > > > > > E-Sign bill was > > > > > > > > signed, regardless of the technology utilized. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > ------_=_NextPart_001_01C00D21.64BA2AB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: President Clinton digital signing

Liaquat,

You are quite right.  In fact, this is the = easiest (perhaps only standard based) way of capturing authoritative = snapshots that can then be used for archiving - for 7 yr record keeping = requirements, etc.  If a certificate was suspended for a week and = during that period no OCSP request was made on the status of this = certificate you would still have a record of this in archives.  = This can be invaluable for future dispute resolution proceedings for = example.

For this reason many PKIs mandate that CRLs be = generated on every revocation event in addition to periodic CRL = publishing.

Khaja
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =

Khaja E. Ahmed
Chief Technology Officer

Identrus, LLC.
16th Floor
140 E 45th St.
New York, NY 10017 USA
Telephone: 01.212.622.0673
Fax: 01.212.622.9196

Khaja.ahmed@identrus.com
Cell Phone: 01.925.989.6564
Home office: 01.925.462.0453
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =



-----Original Message-----
From: Liaquat Khan [mailto:liaquat.khan@gta.m= ulticert.org]
Sent: Wednesday, August 23, 2000 8:02 AM
To: ietf-pkix@imc.org
Subject: Re: President Clinton digital = signing


Tom,

Isn't it a good idea to generate CRLs anyway, even if = you are using OCSP?
The main reason I have in mind is so that the CRL = acts as a historical
record of when the certificate was revoked.
On the other hand, an OCSP response would only be = sent subsequent to
receiving an appropriate OCSP request = message.

Regards,
Liaquat Khan
Technical Manager
Global Trust Authority (GTA)

----- Original Message -----
From: Tom Strickland = <tstrickland@xcert.com>
To: Sam Schaen <schaen@mitre.org>
Cc: Liaquat Khan = <liaquat.khan@gta.multicert.org>; = <ietf-pkix@imc.org>
Sent: Wednesday, August 23, 2000 2:20 PM
Subject: Re: President Clinton digital = signing


> If you are using a mixture or hybrid OCSP = environment to perform checking
with an import
> of CRL data, yes the result could be the = same.
>
> However, if you are using a true OCSP LDAP = environment (i.e. no CRLs),
part of your
> system may slow down due to the DoS but the = validity would always be
accurate.
>
> In the Sentry product, each Registration = Authority (RA) has a built in
real time OCSP
> LDAP. This allows a complete OCSP enterprise = without the need for any CRLs
(unless you
> want to cross certify a CRL from other non OCSP = PKI vendors). This means
that your risk
> of DoS attacks may only slow down one leg (RA) = or department of your PKI
environment,
> not the whole enterprise ensuring accurate real = time information.
>
> Sam Schaen wrote:
>
> > If the DoS prevents the OCSP responder = from receiving a CRL from which
it determines
> > validity status, the result is the = same.
> >
> > Tom Strickland wrote:
> >
> > > Liaquat,
> > >
> > > You bring up a very good point, DoS = attacks are a risk in each
environment.
> > > However if your environment has = critical need for current data (such
as a bank
> > > or government), then a CRL has a = higher risk.
> > >
> > > Example: If a company does not have a = requirement for current
information, a CRL
> > > is sufficient. If a company requires = real time data (i.e. a bank or
government)
> > > due to high value transactions or = security, then I would highly
recommend OCSP.
> > > The risk is if you use CRLs for the = latter, the company may get a
false sense of
> > > security believing their "high = value" transactions are guarded by real
time
> > > data. If the batch CRL is latent, you = may continue processing
utilizing old
> > > data. The risk is a cert believed to = be revoked may still be
considered good in
> > > the system exposing the company to = potential fraud or negligence.
> > >
> > > In an OCSP environment, if you must = trust real time data and someone
executes a
> > > DoS attack, the responder may slow = down or worst case, stop working.
This is an
> > > added value because I would rather = slow down or stop processing than
to rely on
> > > old data. The risk here is slower = response time but guaranteed
accurate
> > > information.
> > >
> > > This is a question that each company = must answer by performing a risk
assessment
> > > to determine their acceptable level = of "pain", risk and exposure.
> > >
> > > I am not trying to be confrontational = in my recent "typings". I am
just trying
> > > to bring added value to everyone = here. As an auditor that has
performed audits
> > > on several PKI environments, I am = just trying to help elevate certain
risks that
> > > sometimes get overlooked.
> > >
> > > Best regards,
> > >
> > > Tom
> > >
> > > Liaquat Khan wrote:
> > >
> > > > You have to assume that access = to the server which issues CRLs is
protected
> > > > from denial of service = attacks.  For example, generally only trusted
> > > > operators can authorise the = generation of CRLs, after having their
> > > > identities authenticated by the = server.  Also access to the CRL
issuer has
> > > > to be protected through = firewalls, etc.
> > > >
> > > > If an attacker can perform a DoS = attack on a CRL issuer, what is
there to
> > > > stop him/her launching a similar = attack on an OCSP server (e.g. by
issuing
> > > > an extremely large amount of = OCSP requests)?
> > > >
> > > > Regards,
> > > > Liaquat Khan
> > > > Technical Manager
> > > > Global Trust Authority = (GTA)
> > > >
> > > > ----- Original Message = -----
> > > > From: Tom Strickland = <tstrickland@xcert.com>
> > > > To: Ambarish Malpani = <ambarish@valicert.com>
> > > > Cc: = <spinneyj@flashcom.net>; <ietf-pkix@imc.org>
> > > > Sent: Wednesday, August 23, 2000 = 5:11 AM
> > > > Subject: Re: President Clinton = digital signing
> > > >
> > > > > Hello Ambarish,
> > > > >
> > > > > Thanks for your reply. I = agree that OCSP services are by far
better than
> > > > > CRLs. In general, as = everyone knows, a CRL is a batch job that
updates a
> > > > > database over certain = intervals. From an audit standpoint, one of
the many
> > > > > issues with CRLs is that = they can be beat. For example, it is very
easy to
> > > > > perform any series of = denial of service attacks against the
server. This
> > > > > could cause longer than = expected delays in the execution of the
batch job
> > > > > or worse, prevent the batch = job from running causing latent (or
corrupted)
> > > > > CRL publishing. Also, if = someone is savvy enough, they could also
issue
> > > > > hundreds of back to back = CRL job requests resulting in multiple
jobs
> > > > > waiting on shared services = again causing problematic CRLs. I know
this may
> > > > > sound farfetched but they = are risks to be considered.
> > > > >
> > > > > As you may guess I am not a = proponent of CRLs for obvious reasons.
I have
> > > > > heard claims by some that = their products are OCSP compliant. In
reality it
> > > > > is just a batch job = publishing to a database but still they have
inherent
> > > > > CRL batch job = latency.
> > > > >
> > > > > As for the CAM, I am not = familiar enough with that to argue for or
against
> > > > > its use. I do know however = that the Xcert product has a non
proprietary
> > > > > real time OCSP LDAP out of = the box resulting in a more robust
product.
> > > > Note
> > > > > that the Sentry CA product = can publish CRLs to non OCSP products
to offer
> > > > > backwards compatibility = when needed. Also, the Sentry product can
import
> > > > > other vendors CRLs and = place them in the real time OCSP LDAP.
> > > > >
> > > > > Also one of the several = reasons that Sentry CA was chosen was due
to its
> > > > > ability to cross certify = against other CAs (cross certification).
It is
> > > > > very easy to setup trust to = another company's CA allowing multiple
CAs or
> > > > > PKI vendors within a = central Sentry OCSP environment.
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Tom
> > > > >
> > > > >
> > > > > Ambarish Malpani = wrote:
> > > > >
> > > > > > Hi Tom,
> > > > > >
> > > > > > It really isn't that = hard to set up quite a few of the CAs to
> > > > > > create a new CRL = whenever a new revocation happens.
> > > > > >
> > > > > > Think of this CRL as a = snapshot of the CA's revocation database
> > > > > > and the publishing of = a new CRL as a trigger to tell the OCSP
> > > > > > server that the = snapshot has changed.
> > > > > >
> > > > > > Really, an OCSP server = can be set up to be as current as any
other
> > > > > > software to provide = revocation information, either with or
without
> > > > > > CRLs.
> > > > > >
> > > > > = >     It is completely unclear to me why the CAM = solution is any
> > > > > > more real time than = OCSP. I believe the real reason for the
> > > > > > CAM solution was just = that OCSP didn't exist as a standard till
> > > > > > late in the ACES = project as indicated by the mails from both
> > > > > > Judith and Tim. I have = a suspicion that it still might be faster
> > > > > > and cheaper for ACES = to go with OCSP, rather than try to stick
to
> > > > > > a non-standard = protocol.
> > > > > >
> > > > > > Regards,
> > > > > > Ambarish
> > > > > >
> > > > >
> = ---------------------------------------------------------------------
> > > > > > Ambarish = Malpani
> > > > > > Architect
650.567.5457
> > > > > > ValiCert, Inc.
ambarish@valicert.com
> > > > > > 339 N. Bernardo = Ave.
http://www.valicert.com
> > > > > > Mountain View, CA = 94043
> > > > > >
> > > > > > > -----Original = Message-----
> > > > > > > From: Tom = Strickland [mailto:tstrickland@xcert.com]<= /FONT>
> > > > > > > Sent: Tuesday, = August 22, 2000 9:18 AM
> > > > > > > To: = spinneyj@flashcom.net; ietf-pkix@imc.org
> > > > > > > Subject: Re: = President Clinton digital signing
> > > > > > >
> > > > > > >
> > > > > > > You are correct = to ask "why the US govt (GSA, at least)
> > > > > > > dosent seem to = want to
> > > > > > > embrace OCSP as a = validation mechanism for ACES (and other
> > > > > > > = programs)??".
> > > > > > > You have to = remember that ACES does have built in OCSP. The
> > > > > > > product that = they
> > > > > > > chose includes an = OCSP "real time" responder, not antiquated
CRLs.
> > > > > > >
> > > > > > > Please review the = following URLs to see how and why Xcert was
chosen:
> > > > > > >
> > > > > > > ACES = announcement:
> > > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-ac= es.html
> > > > > > >
> > > > > > > Reference to = digital signature law:
> > > > > > > http://www.xcert.com/resources/esign/index.html
> > > > > > >
> > > > > > > Sentry CA = functionality:
> > > > > > > http://www.xcert.com/software/sentryca.html=
> > > > > > >
> > > > > > > Scalability to = manage over 8 million certs on one CA and box:
> > > > > > >
http://www.xcert.com/corp/Press_Releases/2000-05-15-8m= illion.html
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > = jspinney@securify.com wrote:
> > > > > > >
> > > > > > > > this is very = interexting, can somebody please comment on
> > > > > > > why the US = govt
> > > > > > > > (GSA, at = least) doesnt seem to want to embrace OCSP as a
validation
> > > > > > > > mechanism = for ACES (and other programs)??   the 'CAM' as
> > > > > > > they call it = sems
> > > > > > > > to be an = alternative mechanism....a duplication of much of
> > > > > > > the work OCSP = has
> > > > > > > > already = worked through...
> > > > > > > >
> > > > > > > > -j
> > > > > > > >
> > > > > > > > = -----Original Message-----
> > > > > > > > From: = marion.royal@gsa.gov [mailto:marion.royal@gsa.gov]
> > > > > > > > Sent: = Tuesday, August 22, 2000 8:52 AM
> > > > > > > > To: = ietf-pkix@imc.org
> > > > > > > > Cc: = terri.hobson@gsa.gov; judith.spencer@gsa.gov
> > > > > > > > Subject: RE: = President Clinton digital signing
> > > > > > > >
> > > > > > > > Terri = suggests that the real significance of the
> > > > > > > certificate and = smart card
> > > > > > > > used by = President Clinton is that they were obtained
> > > > > > > through the = Access
> > > > > > > > Certificates = for Electronic Services (ACES) contract at
> > > > > > > GSA.  = Through the
> > > > > > > > use of a = Certificate Arbitrator Module (CAM), which is
> > > > > > > effectively a = parser
> > > > > > > > and = validation tool (offered to public domain by GSA),
> > > > > > > multiple CA's = are
> > > > > > > > made = available to the government applications.
> > > > > > > >
> > > > > > > > More info = at
> > > > > > > >
> > > > > > > > http://www.gsa.gov/aces/
> > > > > > > >
> > > > > > > > To me, = though, the most significant thing is that the
> > > > > > > E-Sign bill = was
> > > > > > > > signed, = regardless of the technology utilized.
> > > > > > > >
> > > > > > > > = Cheers,
> > > > > > >
> > > > >
>

------_=_NextPart_001_01C00D21.64BA2AB0-- From owner-ietf-pkix@imc.org Wed Aug 23 12:55:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18528 for ; Wed, 23 Aug 2000 12:55:10 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA05116; Wed, 23 Aug 2000 09:54:22 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 09:54:20 -0700 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05083 for ; Wed, 23 Aug 2000 09:54:20 -0700 (PDT) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0FZR00A018BA1E@ext-mail.valicert.com> for ietf-pkix@imc.org; Wed, 23 Aug 2000 09:54:46 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0FZR0095F8BASG@ext-mail.valicert.com>; Wed, 23 Aug 2000 09:54:46 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 09:44:38 -0700 Content-return: allowed Date: Wed, 23 Aug 2000 09:44:35 -0700 From: Peter Williams Subject: RE: Undefined combinations of extensions To: "'d.w.chadwick@salford.ac.uk'" , ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE201C08720@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe 5 years ago, based on academic research, I specified a pre-PKIX1 PKI architecture in which variations of the X.500 structure and content rules were applied to certificate extensions to address this problem; It was 5 year too early (like many of the things I do.) The architecture exploited all the work of hierarchical distributed schema specification, delegation and administration accomplished by X.500 design for controlling the security of distributed directories. The objects controlled happened to be extensions, versus attributes of entries, but the security management properties were the same. Perhaps you could reuse this idea, and invent something? Perhaps the time has come, now that chains are beginning to matter. Even better, as trusted directories are now coming to the fore (based on modern X.500's standardization of distributed directory security techniques), perhaps we should make the directory the host for the schema rules controlling cert extensions - rather than embedding the structure/content rule in the superior certificate of a chain. -----Original Message----- From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk] Sent: Wednesday, August 23, 2000 9:36 AM To: ietf-pkix@imc.org Cc: Kurt D. Zeilenga; osidirectory@az05.bull.com Subject: Undefined combinations of extensions On the LDAPExt list we have been discussing the effects of combinations of extensions (controls in LDAP jargon) on the LDAP server performing an LDAP operation, when the effects of the combination of one or more extensions is not understood by the server. The server may understand each separate extension, but not the semantics of them in combination. It seems to me that PKIX/X.509 will have (or already may have encountered) this same problem for COMBINATIONS of certificate extensions (some of which may be private, some de-facto, some critical, some not) that are thought to be understood by the issuing CA, but are not fully understood by the relying party / validation engine. What text does anyone have for this situation? I believe the recently issued X.509 defect report 244, raised by Sharon, only discusses the case of a single extension in isolation, and does not discuss the effects of combinations of extensions. The most interesting cases are when the RP finds combinations of extensions, where each extension on its own is understood, but where the combined semantics are not fully understood (possibly due to incomplete or ambiguous specification of extension interactions when the extensions are written by different groups). In this case, LDAP is suggesting that a receiver may ignore non- critical extensions (even those it recognizes) to establish the semantics of the operation. This is in direct contrast to the wording of defect report 244, which states that an understood non-critical extension must be obeyed. The LDAP work would suggest an addition to DR244 along the lines of " A validation engine that does not understand the interaction of a non-critical extension with another extension (critical or non-critical), may ignore the non-critical extension (even if it understands the semantics of the extension in isolation to the others), and accept the certificate (unless factors other than this extension cause it to be rejected). A validation engine that does not understand the interaction of two critical extensions, must reject the certificate (even if it understands the semantics of both extensions in isolation to each other)." David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From owner-ietf-pkix@imc.org Wed Aug 23 12:55:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18550 for ; Wed, 23 Aug 2000 12:55:49 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA05344; Wed, 23 Aug 2000 09:55:06 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 09:55:04 -0700 Received: from scog-ws3.gsa.gov (host.159-142-144-58.gsa.gov [159.142.144.58]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA05313 for ; Wed, 23 Aug 2000 09:55:03 -0700 (PDT) From: judith.spencer@gsa.gov Received: from 159.142.144.55 by scog-ws3.gsa.gov with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Wed, 23 Aug 2000 12:55:25 -0400 X-Server-Uuid: cb2f616c-ae65-11d3-874c-00508b6362bc Subject: RE: President Clinton digital signing To: William.Flanigan@bmdo.osd.mil cc: pbaker@verisign.com, terri.hobson@gsa.gov, judith.spencer@gsa.gov, marion.royal@gsa.gov, ietf-pkix@imc.org Sender: judith.spencer@gsa.gov Date: Wed, 23 Aug 2000 12:55:14 -0400 Message-ID: X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on SCOG-NOTESSMTP1/GSAEXTERNAL(Release 5.0.1b|September 30, 1999) at 08/23/2000 12:55:25 PM MIME-Version: 1.0 X-WSS-ID: 15BADE76137946-03-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA05314 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit The e-signing of the bill was a demonstration of the technology. You're right. The bill was officially signed with a pen and then a wax seal was applied. I'm having a little trouble with your "circular reference" statement and that the bill is a "self-signed certificate". Perhaps you'd be willing to explain your reasoning to me more fully. Judy Spencer "Flanigan, William, CIV,BMDO/DSC" on 08/23/2000 09:37:06 AM To: "'Philip Hallam-Baker'" cc: terri.hobson@gsa.gov, judith.spencer@gsa.gov, "'marion.royal@gsa.gov'" , ietf-pkix@imc.org Subject: RE: President Clinton digital signing Right on Philip (as usual)!  But it seems unlikely that the bill was not "signed" twice, one being a wet signature (with no photo op).  Does anyone know for sure? Bill Flanigan -----Original Message----- From: Philip Hallam-Baker [mailto:pbaker@verisign.com] Sent: Tuesday, August 22, 2000 9:08 PM To: 'marion.royal@gsa.gov'; ietf-pkix@imc.org Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov Subject: RE: President Clinton digital signing [snip] And it was totally illogical to use a digital signature for the purpose. The act is now effectively a self-signed cert! The validity of the authentication on the act is established through a circular reference to the act itself.               Phill From owner-ietf-pkix@imc.org Wed Aug 23 13:04:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18907 for ; Wed, 23 Aug 2000 13:04:24 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA06080; Wed, 23 Aug 2000 10:03:39 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 10:03:37 -0700 Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06048 for ; Wed, 23 Aug 2000 10:03:35 -0700 (PDT) Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 13:03:26 -0400 Message-ID: From: Khaja Ahmed To: "'Stephen Kent'" , Tom Strickland , ietf-pkix@imc.org Subject: RE: President Clinton digital signing Date: Wed, 23 Aug 2000 13:03:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00D24.0CB58C50" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C00D24.0CB58C50 Content-Type: text/plain; charset="iso-8859-1" Re Steve's point that CRLs can be replicated at any number of servers... It is also possible to have a number of OCSP servers that get CRLs fed to them based on which they respond to OCSP requests. Unless I am much mistaken, nothing in the OCSP protocol prevents an OCSP server from having a distributed / widely replicated presence. While this is more expensive** than having CRLs available at multiple servers it offers the advantages that are associated with getting OCSP responses rather than CRLs to a relying party. In some cases this may be quite acceptable. Khaja ** An OCSP server has security requirements and performance requirements that do not get imposed on a web server that simply has a CRL available for download. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Wednesday, August 23, 2000 7:03 AM To: Tom Strickland Cc: ietf-pkix@imc.org Subject: Re: President Clinton digital signing Tom, >Hello Ambarish, > >Thanks for your reply. I agree that OCSP services are by far better than >CRLs. I think this is an over generalization, i.e., OCSP is bettr in some cases, but not in all cases. >In general, as everyone knows, a CRL is a batch job that updates a >database over certain intervals. From an audit standpoint, one of the many >issues with CRLs is that they can be beat. For example, it is very easy to >perform any series of denial of service attacks against the server. Which server? A directory? A CRL has the advantage that it can be replicated at any numnber of servers, without imbuing these serves with trust (re integrity and authenticity). While it is certainly true that one can engage in a DoS attack against directories, the same is also true for OCSP servers. I don't think we have enough experience with both types of servers to determine if one is more susceptible than the other, as a class, or if it's just an issue of implementation and local management quality. >This >could cause longer than expected delays in the execution of the batch job >or worse, prevent the batch job from running causing latent (or corrupted) >CRL publishing. Batch job? Now it sounds like your talking about a CA preparing a CRL. A CA component generating a CRL need not be online and thus need not be very susceptible to DoS attacks, so I'm puzzled by this line of reasoning. >Also, if someone is savvy enough, they could also issue >hundreds of back to back CRL job requests resulting in multiple jobs >waiting on shared services again causing problematic CRLs. I know this may >sound farfetched but they are risks to be considered. CRL job requests? I've been involved with the design of several CAs over time and none offered an external interface which could be manipulated inthe fashion you suggest. >As you may guess I am not a proponent of CRLs for obvious reasons. I have >heard claims by some that their products are OCSP compliant. In reality it >is just a batch job publishing to a database but still they have inherent >CRL batch job latency. The latency issue re CRLs is a red herring, in almost all cases. The time required to generate a CRL is fairly small for almost any PKI of a reasonable size. The external, non-technical factors associated with deciding that a compromise has occurred or that an attribute has changed and thus a cert should be revoked almost always swamp the CRL production activity. >As for the CAM, I am not familiar enough with that to argue for or against >its use. I do know however that the Xcert product has a non proprietary >real time OCSP LDAP out of the box resulting in a more robust product. Note >that the Sentry CA product can publish CRLs to non OCSP products to offer >backwards compatibility when needed. Also, the Sentry product can import >other vendors CRLs and place them in the real time OCSP LDAP. Oh, OCSp and LDAP? That combination suggests an DoS opportunity that might be the sum of the two server interfaces :-). >Also one of the several reasons that Sentry CA was chosen was due to its >ability to cross certify against other CAs (cross certification). It is >very easy to setup trust to another company's CA allowing multiple CAs or >PKI vendors within a central Sentry OCSP environment. No more product endorsements, OK? Steve ------_=_NextPart_001_01C00D24.0CB58C50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: President Clinton digital signing

Re Steve's point that CRLs can be replicated at any = number of servers...

It is also possible to have a number of OCSP servers = that get CRLs fed to them based on which they respond to OCSP = requests.  Unless I am much mistaken, nothing in the OCSP protocol = prevents an OCSP server from having a distributed / widely replicated = presence.

While this is more expensive** than having CRLs = available at multiple servers it offers the advantages that are = associated with getting OCSP responses rather than CRLs to a relying = party.  In some cases this may be quite acceptable.

Khaja

** An OCSP server has security requirements and = performance requirements that do not get imposed on a web server that = simply has a CRL available for download.


-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Wednesday, August 23, 2000 7:03 AM
To: Tom Strickland
Cc: ietf-pkix@imc.org
Subject: Re: President Clinton digital = signing


Tom,

>Hello Ambarish,
>
>Thanks for your reply. I agree that OCSP = services are by far better than
>CRLs.

I think this is an over generalization, i.e., OCSP is = bettr in some
cases, but not in all cases.

>In general, as everyone knows, a CRL is a batch = job that updates a
>database over certain intervals. From an audit = standpoint, one of the many
>issues with CRLs is that they can be beat. For = example, it is very easy to
>perform any series of denial of service attacks = against the server.

Which server? A directory?  A CRL has the = advantage that it can be
replicated at any numnber of servers, without = imbuing these serves
with trust (re integrity and authenticity).  = While it is certainly
true that one can engage in  a DoS attack = against directories, the
same is also true for OCSP servers. I don't think we = have enough
experience with both types of servers to determine = if one is more
susceptible than the other, as a class, or if it's = just an issue of
implementation and local management quality.

>This
>could cause longer than expected delays in the = execution of the batch job
>or worse, prevent the batch job from running = causing latent (or corrupted)
>CRL publishing.

Batch job?  Now it sounds like your talking = about a CA preparing a
CRL.  A CA component generating a CRL need not = be online and thus
need not be very susceptible to DoS attacks, so I'm = puzzled by this
line of reasoning.

>Also, if someone is savvy enough, they could also = issue
>hundreds of back to back CRL job requests = resulting in multiple jobs
>waiting on shared services again causing = problematic CRLs. I know this may
>sound farfetched but they are risks to be = considered.

CRL job requests?  I've been involved with the = design of several CAs
over time and none offered an external interface = which could be
manipulated inthe fashion you suggest.

>As you may guess I am not a proponent of CRLs for = obvious reasons. I have
>heard claims by some that their products are = OCSP compliant. In reality it
>is just a batch job publishing to a database but = still they have inherent
>CRL batch job latency.

The latency issue re CRLs is a red herring, in almost = all cases. The
time required to generate a CRL is fairly small for = almost any PKI of
a reasonable size.  The external, non-technical = factors associated
with deciding that a compromise has occurred or that = an attribute has
changed and thus a cert should be revoked almost = always swamp the CRL
production activity.

>As for the CAM, I am not familiar enough with = that to argue for or against
>its use. I do know however that the Xcert = product has a non proprietary
>real time OCSP LDAP out of the box resulting in = a more robust product. Note
>that the Sentry CA product can publish CRLs to = non OCSP products to offer
>backwards compatibility when needed. Also, the = Sentry product can import
>other vendors CRLs and place them in the real = time OCSP LDAP.

Oh, OCSp and LDAP?  That combination suggests an = DoS opportunity that
might be the sum of the two server interfaces = :-).

>Also one of the several reasons that Sentry CA = was chosen was due to its
>ability to cross certify against other CAs = (cross certification). It is
>very easy to setup trust to another company's CA = allowing multiple CAs or
>PKI vendors within a central Sentry OCSP = environment.


No more product endorsements, OK?

Steve

------_=_NextPart_001_01C00D24.0CB58C50-- From owner-ietf-pkix@imc.org Wed Aug 23 13:04:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18918 for ; Wed, 23 Aug 2000 13:04:31 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA06035; Wed, 23 Aug 2000 10:03:33 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 10:03:31 -0700 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA06004 for ; Wed, 23 Aug 2000 10:03:30 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 23 Aug 2000 11:03:14 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 23 Aug 2000 11:03:10 -0600 From: "Bob Jueneman" To: , Cc: Subject: RE: President Clinton digital signing Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_346CA4C2.29482D28" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_346CA4C2.29482D28 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I believe that the bill was in fact signed twice, once with a pen, but I = also believe that the concern about circularity is a red herring.=20 I would argue that it is the President's approval , rather than his = signature, that causes a Bill to become law. His signature is but one of = many means of evidencing and memorializing that approval -- witnesses, = photo ops, etc., could very reasonably be considered evidence of such = approval as well, and would actually be far more compelling than the = mechanical pen signature that I understand is routinely used for bills of = less than stellar significance.=20 In any case, because he didn't veto the bill and return it to the = Congress, it would have become binding within ten days in any case, except = if it had occurred at the end of the Congressional term (a "pocket veto"), = which was not the case.=20 So it would have become the law of the land no matter how it was signed, = or absent any signature at all.=20 Article I, Section 7 of the Constitution of the United states reads as = follows:=20 Section. 7. All Bills for raising Revenue shall originate in the=20 House of Representatives; but the Senate may propose or concur with=20 amendments as on other Bills.=20 Every Bill which shall have passed the House of Representatives=20 and the Senate, shall, before it become a law, be presented to the=20 President of the United States: If he approve he shall sign it, but if=20 not he shall return it, with his Objections to that House in which it=20 shall have originated, who shall enter the Objections at large on their=20 Journal, and proceed to reconsider it. If after such Reconsideration = two=20 thirds of that House shall agree to pass the Bill, it shall be sent,=20 together with the Objections, to the other House, by which it shall=20 likewise be reconsidered, and if approved by two thirds of that House,=20 it shall become a Law. But in all such Cases the Votes of both Houses=20 shall be determined by Yeas and Nays, and the Names of the Persons=20 voting for and against the Bill shall be entered on the Journal of each=20 House respectively. If any Bill shall not be returned by the President=20 within ten Days (Sundays excepted) after it shall have been presented = to=20 him, the Same shall be a Law, in like Manner as if he had signed it,=20 unless the Congress by their Adjournment prevent its Return, in which=20 Case it shall not be a Law=20 Every Order, Resolution, or Vote to which the Concurrence of the=20 Senate and House of Representatives may be necessary (except on a=20 question of Adjournment) shall be presented to the President of the=20 United States; and before the Same shall take Effect, shall be approved=20 by him, or being disapproved by him, shall be repassed by two thirds of=20 the Senate and House of Representatives, according to the Rules and=20 Limitations prescribed in the Case of a Bill.=20 The merits of the bill, however, are a different issue.=20 Bob=20 >>>< William.Flanigan@bmdo.osd.mil > 08/23/00 07:37AM >>>=20 Right on Philip (as usual)! But it seems unlikely that the bill was not = "signed" twice, one being a wet signature (with no photo op). Does anyone = know for sure?=20 Bill Flanigan=20 -----Original Message-----=20 From: Philip Hallam-Baker [ mailto:pbaker@verisign.com=20 Sent: Tuesday, August 22, 2000 9:08 PM=20 To: ' marion.royal@gsa.gov' ; ietf-pkix@imc.org=20 Cc: terri.hobson@gsa.gov ; judith.spencer@gsa.gov=20 Subject: RE: President Clinton digital signing=20 [snip]=20 And it was totally illogical to use a digital signature for the purpose.=20= The act is now effectively a self-signed cert! The validity of the=20 authentication on the act is established through a circular reference=20 to the act itself.=20 Phill=20 --=_346CA4C2.29482D28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I believe that the bill was in fact signed twice, once with a = pen, but I=20 also believe that the concern about circularity is a red herring. =

I=20 would argue that it is the President's approval , rather than = his=20 signature, that causes a Bill to become law. His signature is but one of = many=20 means of evidencing and memorializing that approval -- witnesses, photo = ops,=20 etc., could very reasonably be considered evidence of such approval as = well, and=20 would actually be far more compelling than the mechanical pen signature = that I=20 understand is routinely used for bills of less than stellar significance.= =20

In any case, because he didn't veto the bill and return it to = the=20 Congress, it would have become binding within ten days in any case, except = if it=20 had occurred at the end of the Congressional term (a "pocket veto"), which = was=20 not the case.

So it would have become the law of the land no = matter how=20 it was signed, or absent any signature at all.

Article I, Section = 7 of=20 the Constitution of the United states reads as follows:

Section. = 7. All=20 Bills for raising Revenue shall originate in the
House of Representativ= es;=20 but the Senate may propose or concur with
amendments as on other = Bills.=20
Every Bill which shall have passed the = House of=20 Representatives
and the Senate, shall, before it become a law, be = presented=20 to the
President of the United States: If he approve he shall sign = it,=20 but if
not he shall return it, with = his=20 Objections to that House in which it
shall have originated, who shall = enter=20 the Objections at large on their
Journal, and proceed to reconsider = it. If=20 after such Reconsideration two
thirds of that House shall agree to = pass the=20 Bill, it shall be sent,
together with the Objections, to the other = House, by=20 which it shall
likewise be reconsidered, and if approved by two thirds = of=20 that House,
it shall become a Law. But in all such Cases the Votes of = both=20 Houses
shall be determined by Yeas and Nays, and the Names of the = Persons=20
voting for and against the Bill shall be entered on the Journal of = each=20
House respectively. If any Bill shall = not be=20 returned by the President
within ten Days (Sundays excepted) after it = shall=20 have been presented to
him, the Same shall be a Law, in like Manner as = if he=20 had signed it,
unless the Congress by = their=20 Adjournment prevent its Return, in which
Case it shall not be a Law=20
Every Order, Resolution, or Vote to which the Concurrence of the =
Senate=20 and House of Representatives may be necessary (except on a
question = of=20 Adjournment) shall be presented to the = President of=20 the
United States; and before the Same shall take Effect, shall be = approved=20
by him, or being disapproved by him, = shall be=20 repassed by two thirds of
the Senate and House of Representatives, = according=20 to the Rules and
Limitations prescribed in the Case of a Bill.=20


The merits of the bill, however, are a different issue.=20


Bob


>>>< William.Flanigan@bmdo.osd.mil= =20 > 08/23/00 07:37AM >>>


Right on Philip (as usual)! = But=20 it seems unlikely that the bill was not "signed" twice, one being a wet=20 signature (with no photo op). Does anyone know for sure?
Bill = Flanigan=20
-----Original Message-----
From: Philip Hallam-Baker [ mailto:pbaker@verisign.com =
Sent:=20 Tuesday, August 22, 2000 9:08 PM
To: ' marion.royal@gsa.gov' ; = ietf-pkix@imc.org
Cc: = terri.hobson@gsa.gov ; = judith.spencer@gsa.gov =
Subject:=20 RE: President Clinton digital signing
[snip]
And it was totally=20 illogical to use a digital signature for the purpose.
The act is = now=20 effectively a self-signed cert! The validity of the
authentication on = the=20 act is established through a circular reference
to the act itself.=20

Phill
--=_346CA4C2.29482D28-- From owner-ietf-pkix@imc.org Wed Aug 23 13:13:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19040 for ; Wed, 23 Aug 2000 13:12:59 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA06859; Wed, 23 Aug 2000 10:12:12 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 10:12:09 -0700 Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06819 for ; Wed, 23 Aug 2000 10:12:05 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 13:12:04 -0400 Message-ID: <3120721CA75DD411B8340090273D20B1271F0E@sottmxs06.entrust.com> From: Sharon Boeyen To: "'d.w.chadwick@salford.ac.uk'" , ietf-pkix@imc.org Cc: "Kurt D. Zeilenga" , osidirectory@az05.bull.com Subject: RE: Undefined combinations of extensions Date: Wed, 23 Aug 2000 13:07:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe The defect report is clarifying, not changing, the way criticality is treated for certificate extensions. Criticality applies to each extension independent of all others. Clearly, if one extension is included in a certificate as critical (e.g. certificate policies) and another is included as non-critical (e.g. policy mappings), then there will be different results by relying party systems that do support policy mappings and ones that do not. However, there should be no difference in relying party systems that do support the extensions regardless of their criticality. A CA sets the criticality flag for each and every extension as it sees fit. By setting an extension non-critical, the CA is accepting the fact that relying party systems that do not understand this extension will ignore it when processing the certificate and relying party systems that do understand it will process it. When it sets the flag critical it is limiting the relying parties to ONLY those that understand the extension. Any semantic relationship between two or more extensions (e.g. among the policy related ones) needs to be addressed by the issuer (for instance it doesn't make a lot of sense to issue a certificate with critical policy mappings but non-critical certificate policies). This is a policy issue though not one that the criticality flag should be used to solve. If there is a situation where two extensions may cause conflicting impacts (e.g. the issuingDistributionPoint extension and the crlScope extension), then the definition of the extensions themselves should contain the semantics of what is to be done (see the definition of crlScope which states that these 2 are not intended to be used together but states what the rule is if both happen to be present). If the problem you are trying to solve is that extensions have not been properly or fully defined, then that problem should be fixed in the extension definitions themselves, not by trying to invert the meaning of critical and non critical in the standard. Is there a concrete example you can share, that might bring to light some point I'm missing? Sharon > -----Original Message----- > From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk] > Sent: Wednesday, August 23, 2000 12:36 PM > To: ietf-pkix@imc.org > Cc: Kurt D. Zeilenga; osidirectory@az05.bull.com > Subject: Undefined combinations of extensions > > > On the LDAPExt list we have been discussing the effects of > combinations of extensions (controls in LDAP jargon) on the LDAP > server performing an LDAP operation, when the effects of the > combination of one or more extensions is not understood by the > server. The server may understand each separate extension, but > not the semantics of them in combination. > > It seems to me that PKIX/X.509 will have (or already may have > encountered) this same problem for COMBINATIONS of certificate > extensions (some of which may be private, some de-facto, some > critical, some not) that are thought to be understood by the issuing > CA, but are not fully understood by the relying party / validation > engine. > > What text does anyone have for this situation? I believe the recently > issued X.509 defect report 244, raised by Sharon, only discusses > the case of a single extension in isolation, and does not discuss the > effects of combinations of extensions. > > The most interesting cases are when the RP finds combinations of > extensions, where each extension on its own is understood, but > where the combined semantics are not fully understood (possibly > due to incomplete or ambiguous specification of extension > interactions when the extensions are written by different > groups). In > this case, LDAP is suggesting that a receiver may ignore non- > critical extensions (even those it recognizes) to establish the > semantics of the operation. This is in direct contrast to the wording > of defect report 244, which states that an understood non-critical > extension must be obeyed. The LDAP work would suggest an > addition to DR244 along the lines of > > " A validation engine that does not understand the interaction of a > non-critical extension with another extension (critical or > non-critical), > may ignore the non-critical extension (even if it understands the > semantics of the extension in isolation to the others), and > accept the > certificate (unless factors other than this extension cause it to be > rejected). > > A validation engine that does not understand the interaction of two > critical extensions, must reject the certificate (even if it > understands > the semantics of both extensions in isolation to each other)." > > David > > > > *************************************************** > > David Chadwick > IS Institute, University of Salford, Salford M5 4WT > Tel +44 161 295 5351 Fax +44 161 745 8169 > Mobile +44 790 167 0359 > Email D.W.Chadwick@salford.ac.uk > Home Page http://www.salford.ac.uk/its024/chadwick.htm > Understanding X.500 http://www.salford.ac.uk/its024/X500.htm > X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm > Entrust key validation string MLJ9-DU5T-HV8J > > *************************************************** > From owner-ietf-pkix@imc.org Wed Aug 23 14:13:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20415 for ; Wed, 23 Aug 2000 14:13:04 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA09483; Wed, 23 Aug 2000 11:12:13 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 11:12:02 -0700 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA09439 for ; Wed, 23 Aug 2000 11:12:01 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 23 Aug 2000 12:11:52 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 23 Aug 2000 12:11:53 -0600 From: "Bob Jueneman" To: , Cc: Subject: OCSP vs. CRLs Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_1E468EF8.A7C6A346" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_1E468EF8.A7C6A346 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable As one of the original proponents (with Sead Muftic) of an on-line = document (not certificate) validation service, I'd like to support Steve's = assertion that "it depends" on whether OCSP is "better" than CRLs. I contend that it is very important to carefully consider the risk, the = computational load imposed on the server, the "freshness" of either the = CRL or OCSP response, the availability of caching, and most importantly, = the availability of full-time available connections in coming to that = decision. If updated CRLs are reliably made available to anyone who inquires as soon = as the decision to revoke a certificate is made, then I would argue that = they are nearly as good as OCSP. (Not quite as good, because OCSP at = least provides the option of including the hash of the document in = question, which avoids all sorts of time-stamping issues. But it isn't = clear that OCSP in fact does that.) However, the overhead of OCSP in terms of both server computational load = and bandwidth makes it completely ridiculous to even consider for certain = applications. For example, suppose that every .EXE and .DLL in Windows = was signed by Microsoft, and that the loader validated that signature = every time the module was invoked. Obviously this would be helpful in = preventing certain classes of viruses, right? And arguably, at least, it = would be desirable for the certificate chain to be checked to make sure = that the signing key hadn't been compromised, or that Microsoft was no = longer Microsoft, but was now a Baby Bill. But going back to the CA every time a module was invoked would obviously = bring the user's computer, the Internet, and VeriSign to its knees, in = that order. OK, so maybe we don't check it every time -- maybe just when = booting up, or every 24 hours. In other words, "I didn't mean THAT = real-time!" But in that case, a CRL would do equally well, and in fact = better, since CRLS can be cached locally in any of a number of different = ways. Now consider the case of the Navy, steaming around the ocean during either = peacetime or wartime. On a carrier, there are lots of sailors, and they = may need to either encrypt or sign e-mail. They may also receive e-mail = from home, or from shore-based installations. But in general, the CAs are = not part of the fleet, they are in San Diego, or Norfolk, or at Ft. Meade, = or somewhere else back on shore. Do you suppose that those ships would be willing to waste their very = precious bandwidth going back to shore via OCSP to revalidate the = certificate status of say the Chief of Naval Operations, if he sends out a = message or order to everyone in the fleet? Or to validate the certificate = of someone on-board that ship? I certainly don't think so. Instead, a = cached CRL that is updated once a day or even once a week would be = perfectly adequate, and highly preferable. There are many other instances where the requirement for up-to-the-nanoseco= nd validation of a certificate, or even a particular transaction, is = simply not justified. In fact, given all of the other safeguards and = legal back-stops that exist, the need for such verification is more likely = NOT to be the case. I'm not saying that OCSP is of no value, nor am I saying that CRLs are = invariable superior. Or vice versa. "It depends." Bob >>> Stephen Kent 08/23/00 08:03AM >>> Tom, >Hello Ambarish, > >Thanks for your reply. I agree that OCSP services are by far better than >CRLs. I think this is an over generalization, i.e., OCSP is bettr in some=20 cases, but not in all cases. >In general, as everyone knows, a CRL is a batch job that updates a >database over certain intervals. From an audit standpoint, one of the = many >issues with CRLs is that they can be beat. For example, it is very easy = to >perform any series of denial of service attacks against the server. Which server? A directory? A CRL has the advantage that it can be=20 replicated at any numnber of servers, without imbuing these serves=20 with trust (re integrity and authenticity). While it is certainly=20 true that one can engage in a DoS attack against directories, the=20 same is also true for OCSP servers. I don't think we have enough=20 experience with both types of servers to determine if one is more=20 susceptible than the other, as a class, or if it's just an issue of=20 implementation and local management quality. >This >could cause longer than expected delays in the execution of the batch job >or worse, prevent the batch job from running causing latent (or corrupted)= >CRL publishing. Batch job? Now it sounds like your talking about a CA preparing a=20 CRL. A CA component generating a CRL need not be online and thus=20 need not be very susceptible to DoS attacks, so I'm puzzled by this=20 line of reasoning. >Also, if someone is savvy enough, they could also issue >hundreds of back to back CRL job requests resulting in multiple jobs >waiting on shared services again causing problematic CRLs. I know this = may >sound farfetched but they are risks to be considered. CRL job requests? I've been involved with the design of several CAs=20 over time and none offered an external interface which could be=20 manipulated inthe fashion you suggest. >As you may guess I am not a proponent of CRLs for obvious reasons. I have >heard claims by some that their products are OCSP compliant. In reality = it >is just a batch job publishing to a database but still they have inherent >CRL batch job latency. The latency issue re CRLs is a red herring, in almost all cases. The=20 time required to generate a CRL is fairly small for almost any PKI of=20 a reasonable size. The external, non-technical factors associated=20 with deciding that a compromise has occurred or that an attribute has=20 changed and thus a cert should be revoked almost always swamp the CRL=20 production activity. >As for the CAM, I am not familiar enough with that to argue for or = against >its use. I do know however that the Xcert product has a non proprietary >real time OCSP LDAP out of the box resulting in a more robust product. = Note >that the Sentry CA product can publish CRLs to non OCSP products to offer >backwards compatibility when needed. Also, the Sentry product can import >other vendors CRLs and place them in the real time OCSP LDAP. Oh, OCSp and LDAP? That combination suggests an DoS opportunity that=20 might be the sum of the two server interfaces :-). >Also one of the several reasons that Sentry CA was chosen was due to its >ability to cross certify against other CAs (cross certification). It is >very easy to setup trust to another company's CA allowing multiple CAs or >PKI vendors within a central Sentry OCSP environment. No more product endorsements, OK? Steve --=_1E468EF8.A7C6A346 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As one of the original proponents (with Sead Muftic) = of an=20 on-line document (not certificate) validation service, I'd like to sup= port=20 Steve's assertion that "it depends" on whether OCSP is "better" than=20 CRLs.
 
I contend that it is very important to carefully = consider the=20 risk, the computational load imposed on the server, the "freshness" of = either=20 the CRL or OCSP response, the availability of caching, and most importantly= , the=20 availability of full-time available connections in coming to that=20 decision.
 
If updated CRLs are reliably made available to anyone = who=20 inquires as soon as the decision to revoke a certificate is made, then I = would=20 argue that they are nearly as good as OCSP.  (Not quite as good, = because=20 OCSP at least provides the option of including the hash of the document = in=20 question, which avoids all sorts of time-stamping issues. But it isn't = clear=20 that OCSP in fact does that.)
 
However, the overhead of OCSP in terms of both = server=20 computational load and bandwidth makes it completely ridiculous to even = consider=20 for certain applications.  For example, suppose that every .EXE and = .DLL in=20 Windows was signed by Microsoft, and that the loader validated that = signature=20 every time the module was invoked.  Obviously this would be = helpful=20 in preventing certain classes of viruses, right?  And arguably, at = least,=20 it would be desirable for the certificate chain to be checked to make sure = that=20 the signing key hadn't been compromised, or that Microsoft was no = longer=20 Microsoft, but was now a Baby Bill.
 
But going back to the CA every time a module was = invoked would=20 obviously bring the user's computer, the Internet, and VeriSign to its = knees, in=20 that order.  OK, so maybe we don't check it every time -- maybe just = when=20 booting up, or every 24 hours.  In other words, "I didn't mean = THAT=20 real-time!"  But in that case, a CRL would do equally well, and in = fact=20 better, since CRLS can be cached locally in any of a number of different=20= ways.
 
Now consider the case of the Navy, steaming around the = ocean=20 during either peacetime or wartime.  On a carrier, there are lots = of=20 sailors, and they may need to either encrypt or sign e-mail.  They = may also=20 receive e-mail from home, or from shore-based installations.  But = in=20 general, the CAs are not part of the fleet, they are in San Diego, or = Norfolk,=20 or at Ft. Meade, or somewhere else back on shore.
 
Do you suppose that those ships would be willing to = waste=20 their very precious bandwidth going back to shore via OCSP to revalidate = the=20 certificate status of say the Chief of Naval Operations, if he sends out = a=20 message or order to everyone in the fleet?  Or to validate the = certificate=20 of someone on-board that ship? I certainly don't think so.  Instead, = a=20 cached CRL that is updated once a day or even once a week would be = perfectly=20 adequate, and highly preferable.
 
There are many other instances where the requirement = for=20 up-to-the-nanosecond validation of a certificate, or even a particular=20 transaction, is simply not justified.  In fact, given all of the = other=20 safeguards and legal back-stops that exist, the need for such verification = is=20 more likely NOT to be the case.
 
I'm not saying that OCSP is of no value, nor am I = saying that=20 CRLs are invariable superior.  Or vice versa.
 
"It depends."
 
Bob
 
 
>>> Stephen Kent <kent@bbn.com> 08/23/00 08:03AM=20 >>>
Tom,

>Hello Ambarish,
>
>Thanks for = your=20 reply. I agree that OCSP services are by far better than
>CRLs.
I=20 think this is an over generalization, i.e., OCSP is bettr in some =
cases, but=20 not in all cases.

>In general, as everyone knows, a CRL is a = batch job=20 that updates a
>database over certain intervals. From an audit = standpoint,=20 one of the many
>issues with CRLs is that they can be beat. For = example,=20 it is very easy to
>perform any series of denial of service = attacks=20 against the server.

Which server? A directory?  A CRL has = the=20 advantage that it can be
replicated at any numnber of servers, = without=20 imbuing these serves
with trust (re integrity and authenticity).  = While=20 it is certainly
true that one can engage in  a DoS attack = against=20 directories, the
same is also true for OCSP servers. I don't think we = have=20 enough
experience with both types of servers to determine if one is = more=20
susceptible than the other, as a class, or if it's just an issue of=20
implementation and local management quality.

>This
>cou= ld=20 cause longer than expected delays in the execution of the batch job
>= or=20 worse, prevent the batch job from running causing latent (or=20 corrupted)
>CRL publishing.

Batch job?  Now it sounds = like=20 your talking about a CA preparing a
CRL.  A CA component = generating a=20 CRL need not be online and thus
need not be very susceptible to DoS = attacks,=20 so I'm puzzled by this
line of reasoning.

>Also, if someone = is=20 savvy enough, they could also issue
>hundreds of back to back CRL = job=20 requests resulting in multiple jobs
>waiting on shared services = again=20 causing problematic CRLs. I know this may
>sound farfetched but they = are=20 risks to be considered.

CRL job requests?  I've been involved = with=20 the design of several CAs
over time and none offered an external = interface=20 which could be
manipulated inthe fashion you suggest.

>As = you may=20 guess I am not a proponent of CRLs for obvious reasons. I have
>heard= =20 claims by some that their products are OCSP compliant. In reality = it
>is=20 just a batch job publishing to a database but still they have=20 inherent
>CRL batch job latency.

The latency issue re CRLs is = a red=20 herring, in almost all cases. The
time required to generate a CRL is = fairly=20 small for almost any PKI of
a reasonable size.  The external,=20 non-technical factors associated
with deciding that a compromise = has=20 occurred or that an attribute has
changed and thus a cert should be = revoked=20 almost always swamp the CRL
production activity.

>As for the = CAM,=20 I am not familiar enough with that to argue for or against
>its use. = I do=20 know however that the Xcert product has a non proprietary
>real time = OCSP=20 LDAP out of the box resulting in a more robust product. Note
>that = the=20 Sentry CA product can publish CRLs to non OCSP products to=20 offer
>backwards compatibility when needed. Also, the Sentry product = can=20 import
>other vendors CRLs and place them in the real time OCSP=20 LDAP.

Oh, OCSp and LDAP?  That combination suggests an DoS=20 opportunity that
might be the sum of the two server interfaces=20 :-).

>Also one of the several reasons that Sentry CA was chosen = was=20 due to its
>ability to cross certify against other CAs (cross=20 certification). It is
>very easy to setup trust to another company's = CA=20 allowing multiple CAs or
>PKI vendors within a central Sentry = OCSP=20 environment.


No more product endorsements,=20 OK?

Steve

--=_1E468EF8.A7C6A346-- From owner-ietf-pkix@imc.org Wed Aug 23 14:30:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20831 for ; Wed, 23 Aug 2000 14:30:46 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA10665; Wed, 23 Aug 2000 11:29:48 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 11:29:38 -0700 Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA10635 for ; Wed, 23 Aug 2000 11:29:38 -0700 (PDT) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 11:25:44 -0700 Message-ID: <69A40A314934D41190C70050DAD7F99063B587@MAIL> From: Mathew Butler To: "'judith.spencer@gsa.gov'" , William.Flanigan@bmdo.osd.mil Cc: pbaker@verisign.com, terri.hobson@gsa.gov, marion.royal@gsa.gov, ietf-pkix@imc.org Subject: RE: President Clinton digital signing Date: Wed, 23 Aug 2000 11:25:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA10636 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit The question is, "Is there some certification authority that was designated by [whoever has the power to make the designation, be it Congress or the GSA or the GAO or whoever], that signed the certificate that President Clinton used to sign the bill, in order to ensure the authenticity and integrity of the signature [in order to make it legally binding]?" I know that there is nothing in law (even with the signing of this bill) that allows the President to ratify a bill with anything other than a physical signature and seal. Therefore, the entire question is completely ludicrous in the first place, as the answer is patently "No". However, there's a few questions I have... what CA -did- sign the certificate that President Clinton used? Is there an actual copy of the electronically signed version of the bill, including signature, online that we can look at? Also, can we get a copy of the certificate that he used, along with the entire certificate chain to the certificate for the root? (Rather than spamming the list, is there a URL on the GSA's website that would provide access to this information?) Thanks! -Mat Butler -----Original Message----- From: judith.spencer@gsa.gov [mailto:judith.spencer@gsa.gov] Sent: Wednesday, August 23, 2000 9:55 AM To: William.Flanigan@bmdo.osd.mil Cc: pbaker@verisign.com; terri.hobson@gsa.gov; judith.spencer@gsa.gov; marion.royal@gsa.gov; ietf-pkix@imc.org Subject: RE: President Clinton digital signing The e-signing of the bill was a demonstration of the technology. You're right. The bill was officially signed with a pen and then a wax seal was applied. I'm having a little trouble with your "circular reference" statement and that the bill is a "self-signed certificate". Perhaps you'd be willing to explain your reasoning to me more fully. Judy Spencer "Flanigan, William, CIV,BMDO/DSC" on 08/23/2000 09:37:06 AM To: "'Philip Hallam-Baker'" cc: terri.hobson@gsa.gov, judith.spencer@gsa.gov, "'marion.royal@gsa.gov'" , ietf-pkix@imc.org Subject: RE: President Clinton digital signing Right on Philip (as usual)!  But it seems unlikely that the bill was not "signed" twice, one being a wet signature (with no photo op).  Does anyone know for sure? Bill Flanigan -----Original Message----- From: Philip Hallam-Baker [mailto:pbaker@verisign.com] Sent: Tuesday, August 22, 2000 9:08 PM To: 'marion.royal@gsa.gov'; ietf-pkix@imc.org Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov Subject: RE: President Clinton digital signing [snip] And it was totally illogical to use a digital signature for the purpose. The act is now effectively a self-signed cert! The validity of the authentication on the act is established through a circular reference to the act itself.               Phill From owner-ietf-pkix@imc.org Wed Aug 23 15:39:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22109 for ; Wed, 23 Aug 2000 15:38:59 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA12937; Wed, 23 Aug 2000 12:38:05 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 12:37:59 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12907 for ; Wed, 23 Aug 2000 12:37:58 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA05597; Wed, 23 Aug 2000 15:38:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <39A40B6C.20716.17FCDF7@localhost> References: <39A40B6C.20716.17FCDF7@localhost> Date: Wed, 23 Aug 2000 15:33:47 -0400 To: d.w.chadwick@salford.ac.uk From: Stephen Kent Subject: Re: Undefined combinations of extensions Cc: ietf-pkix@imc.org, "Kurt D. Zeilenga" , osidirectory@az05.bull.com Content-Type: multipart/alternative; boundary="============_-1245062893==_ma============" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --============_-1245062893==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" David, Your question about combinations of extensions, and base certificate/CRL fields, is a good one. Tim Polk and I discussed this issue during the last PKIX WG meeting, in a more limited context. I proposed that we include a table that described syntactic constraints among all the fields in a cert or CRL, to address the question of which combinations of fields and values are valid. One cannot do this for really private extensions, and doing it for new extensions that are publicly disclosed is an ongoing task. But, at least we should provide folks with a base set of constraints. I think 2459 should do this and I volunteered to provide a draft table for this. Steve --============_-1245062893==_ma============ Content-Type: text/enriched; charset="us-ascii" David, Your question about combinations of extensions, and base certificate/CRL fields, is a good one. Tim Polk and I discussed this issue during the last PKIX WG meeting, in a more limited context. I proposed that we include a table that described syntactic constraints among all the fields in a cert or CRL, to address the question of which combinations of fields and values are valid. One cannot do this for really private extensions, and doing it for new extensions that are publicly disclosed is an ongoing task. But, at least we should provide folks with a base set of constraints. I think 2459 should do this and I volunteered to provide a draft table for this. Steve --============_-1245062893==_ma============-- From owner-ietf-pkix@imc.org Wed Aug 23 19:47:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24314 for ; Wed, 23 Aug 2000 19:47:57 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA16558; Wed, 23 Aug 2000 16:46:17 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 16:46:08 -0700 Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16527 for ; Wed, 23 Aug 2000 16:46:07 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id QAA27716; Wed, 23 Aug 2000 16:46:21 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 16:44:46 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EBEB@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'Bob Jueneman'" , William.Flanigan@bmdo.osd.mil, Philip Hallam-Baker Cc: ietf-pkix@imc.org Subject: RE: President Clinton digital signing Date: Wed, 23 Aug 2000 16:44:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_000F_01C00D3A.C524EE50"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C00D3A.C524EE50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit >I believe that the bill was in fact signed twice, once with a pen, but I also believe that >the concern about circularity is a red herring. It was a humorous observation I didn't expect you folk to make a federal case out of it! The bill had to be signed twice because the whole premise of the act was legitimizing the use of digital signatures. If the digital signature alone was sufficient to sign an act of Congress then they were good enought for government work without the act. If the act was essential but only signed with a signature that was invalid absent the act there would be a circularity of reference. I agree that from that point of view, the bill itself was probably unnecessary to the extent that we all know that English Common Law (and its colonial derrivatives) is very tolerant of what is recognized as a 'signature'. There was actually an English Constitutional crisis when one of the Stuart Kings absconded, chucking the great seal of office in the Thames during his escape in an attempt to prevent parliament doing anything in his absence. But for the chance recovery of the seal by a fisherman the paliamentary faction would doubtless have decided that some arcane ceremony involving the parliamentary maces and such sanctified a new seal... In the case of the US Constitution however, the act didn't actually need signing at all - absent a veto the bill would have become law in any case. Phill ------=_NextPart_000_000F_01C00D3A.C524EE50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINaDCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEFDCCA32gAwIBAgIQ AxTuqrYcesW8jpUyudZ0/DANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNOTkxMjIwMDAwMDAwWhcNMDAx MjE5MjM1OTU5WjBsMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNTAzBgNVBAMTLHBiYWtlciAoUGhpbGlwIEhhbGxhbS1CYWtlciwgVmVyaVNpZ24s IEluYy4pMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3f0kRIy2AU5cHhfnUwuHecFNq6dnf /wsvxS//4Nt8rFgr2KdvQETKaQ6wGl6mVijB6udZW9dUKVoE1lnu2MMcIhtAL3+Q2dsrxlrTInfq PKAdxu/Fvb4n3Y0RItW9zh1MzFWZ8Q9z6eF2HuBwG6ANfRzfJgironyftbbitRyaxQIDAQABo4IB dDCCAXAwCQYDVR0TBAIwADBVBgNVHR8ETjBMMEqgSKBGhkRodHRwOi8vb25zaXRlY3JsLnZlcmlz aWduLmNvbS9WZXJpU2lnbkluY0V4Y2hhbmdlRW1wbG95ZWVzL0xhdGVzdENSTDALBgNVHQ8EBAMC BaAwHgYDVR0RBBcwFYETcGJha2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgB hvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4g YnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeA MB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQAaUApBXCjc mPE5dFPHlQVl4n9WoOU7AE487xxC7vcR1MDhF8p/0GMu6zOyZe9CFVaOndaYCRgv69qKTVoANmsM F/eFsQn/HaoXEz+jHPNgWcPyBu3dujO9s2PLQbuBXE3rIaDiVyTftVgoNvO0fcknSlNOWxqHvbaH 9RYvhMghkjGCAvgwggL0AgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVy bXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVy aVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAJBgUrDgMCGgUAoIIB jDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDA4MjMyMzQ2MDNa MCMGCSqGSIb3DQEJBDEWBBTIZs8w7YDiVjc5ZYv8EJtezbBxfjBYBgkqhkiG9w0BCQ8xSzBJMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjAKBggqhkiG9w0CBTCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEl MCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAN BgkqhkiG9w0BAQEFAASBgA3IIgVHSehgLrghinZdqsgD94eoztqLPsr1jC1hSs2RLvxH4LT7ucHs 3KbBcLdbkb9MQlGV+WpWNqFQNbBPaGdDIjophIp+fAo9OqJssvAnn6Ea5fZe+Mu5gPXBGF+Sejha 8dM0cjDhhUqRGOTaaQbtfJmi01ZAEJpJTjy9AcdpAAAAAAAA ------=_NextPart_000_000F_01C00D3A.C524EE50-- From owner-ietf-pkix@imc.org Wed Aug 23 20:15:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24560 for ; Wed, 23 Aug 2000 20:15:55 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA17121; Wed, 23 Aug 2000 17:15:10 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 17:15:05 -0700 Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17091 for ; Wed, 23 Aug 2000 17:15:04 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id RAA22999; Wed, 23 Aug 2000 17:14:04 -0700 (PDT) Message-Id: <4.2.2.20000823170442.00aa8340@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 23 Aug 2000 17:24:02 -0700 To: Philip Hallam-Baker , "'Bob Jueneman'" , William.Flanigan@bmdo.osd.mil, Philip Hallam-Baker From: Tony Bartoletti Subject: RE: President Clinton digital signing Cc: ietf-pkix@imc.org In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F408EBEB@vhqpostal.verisign. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 04:44 PM 8/23/00 -0700, Philip Hallam-Baker wrote: > >I believe that the bill was in fact signed twice, once with a pen, but >I also believe that >the concern about circularity is a red herring. > >It was a humorous observation I didn't expect you folk to make a federal >case out of it! :) And I enjoyed the story of the Stuart King. But for the sake of "formalism" (and curiosity) doe anyone know just what CA has certified this key? Or what the precise DN looks like? More to the point, was the entire exercise of signing with this key just a cute charade, or does the U.S. President (now, officially) have a digital key with which to sign "documents of the office", and if so, what are the attributes of the corresponding certificate? (It must expire soon ;) The question of "who certifies the President's digital signature" is an interesting one, in my view, not only now but in general. ___tony___ Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 From owner-ietf-pkix@imc.org Wed Aug 23 20:32:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24782 for ; Wed, 23 Aug 2000 20:32:27 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA17480; Wed, 23 Aug 2000 17:31:48 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 17:31:45 -0700 Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17450 for ; Wed, 23 Aug 2000 17:31:45 -0700 (PDT) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 17:27:52 -0700 Message-ID: <69A40A314934D41190C70050DAD7F99063B58E@MAIL> From: Mathew Butler To: "'Tony Bartoletti'" , Philip Hallam-Baker , "'Bob Jueneman'" , William.Flanigan@bmdo.osd.mil, Philip Hallam-Baker Cc: ietf-pkix@imc.org Subject: RE: President Clinton digital signing Date: Wed, 23 Aug 2000 17:27:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe There is no digital key that can sign "documents of office". The legislation changed how certain high-value monetary transactions can be signed -- it didn't modify how the president does his job. -Mat Butler -----Original Message----- From: Tony Bartoletti [mailto:azb@llnl.gov] Sent: Wednesday, August 23, 2000 5:24 PM To: Philip Hallam-Baker; 'Bob Jueneman'; William.Flanigan@bmdo.osd.mil; Philip Hallam-Baker Cc: ietf-pkix@imc.org Subject: RE: President Clinton digital signing At 04:44 PM 8/23/00 -0700, Philip Hallam-Baker wrote: > >I believe that the bill was in fact signed twice, once with a pen, but >I also believe that >the concern about circularity is a red herring. > >It was a humorous observation I didn't expect you folk to make a federal >case out of it! :) And I enjoyed the story of the Stuart King. But for the sake of "formalism" (and curiosity) doe anyone know just what CA has certified this key? Or what the precise DN looks like? More to the point, was the entire exercise of signing with this key just a cute charade, or does the U.S. President (now, officially) have a digital key with which to sign "documents of the office", and if so, what are the attributes of the corresponding certificate? (It must expire soon ;) The question of "who certifies the President's digital signature" is an interesting one, in my view, not only now but in general. ___tony___ Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 From owner-ietf-pkix@imc.org Wed Aug 23 20:49:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24900 for ; Wed, 23 Aug 2000 20:49:01 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA17996; Wed, 23 Aug 2000 17:48:02 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 17:47:57 -0700 Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17959 for ; Wed, 23 Aug 2000 17:47:56 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id RAA03036; Wed, 23 Aug 2000 17:46:56 -0700 (PDT) Message-Id: <4.2.2.20000823175057.00aabc00@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 23 Aug 2000 17:56:53 -0700 To: Mathew Butler , Philip Hallam-Baker , "'Bob Jueneman'" , William.Flanigan@bmdo.osd.mil, Philip Hallam-Baker From: Tony Bartoletti Subject: RE: President Clinton digital signing Cc: ietf-pkix@imc.org In-Reply-To: <69A40A314934D41190C70050DAD7F99063B58E@MAIL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 05:27 PM 8/23/00 -0700, Mathew Butler wrote: >There is no digital key that can sign "documents of office". The >legislation changed how certain high-value monetary transactions can be >signed -- it didn't modify how the president does his job. Understood, thank you. The "act" of digitally signing the bill in question was an empty gesture, so to speak. Out of curiosity, was it accomplished with an entirely arbitrary "signing key" (a string of zeros, perhaps) or was the (empty) formalism carried further (formal parameters, certificate, etc.)? Is the signature formally (if not legally) verifiable? ___tony___ >At 04:44 PM 8/23/00 -0700, Philip Hallam-Baker wrote: > > > >I believe that the bill was in fact signed twice, once with a pen, but > >I also believe that >the concern about circularity is a red herring. > > > >It was a humorous observation I didn't expect you folk to make a federal > >case out of it! > >:) > >And I enjoyed the story of the Stuart King. > >But for the sake of "formalism" (and curiosity) doe anyone know just >what CA has certified this key? Or what the precise DN looks like? > >More to the point, was the entire exercise of signing with this key >just a cute charade, or does the U.S. President (now, officially) >have a digital key with which to sign "documents of the office", and >if so, what are the attributes of the corresponding certificate? > >(It must expire soon ;) > >The question of "who certifies the President's digital signature" >is an interesting one, in my view, not only now but in general. > >___tony___ > > >Tony Bartoletti 925-422-3881 >Information Operations, Warfare and Assurance Center >Lawrence Livermore National Laboratory >Livermore, CA 94551-9900 Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 From owner-ietf-pkix@imc.org Wed Aug 23 21:10:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25135 for ; Wed, 23 Aug 2000 21:10:18 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA19511; Wed, 23 Aug 2000 18:09:39 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 18:09:36 -0700 Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19479 for ; Wed, 23 Aug 2000 18:09:35 -0700 (PDT) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 18:05:43 -0700 Message-ID: <69A40A314934D41190C70050DAD7F99063B58F@MAIL> From: Mathew Butler To: "'Tony Bartoletti'" , Mathew Butler , Philip Hallam-Baker , "'Bob Jueneman'" , William.Flanigan@bmdo.osd.mil, Philip Hallam-Baker Cc: ietf-pkix@imc.org Subject: RE: President Clinton digital signing Date: Wed, 23 Aug 2000 18:05:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is why I wanted the certificates all the way up to the root, as well as the signed digital representation of the bill. -Mat -----Original Message----- From: Tony Bartoletti [mailto:azb@llnl.gov] Sent: Wednesday, August 23, 2000 5:57 PM To: Mathew Butler; Philip Hallam-Baker; 'Bob Jueneman'; William.Flanigan@bmdo.osd.mil; Philip Hallam-Baker Cc: ietf-pkix@imc.org Subject: RE: President Clinton digital signing At 05:27 PM 8/23/00 -0700, Mathew Butler wrote: >There is no digital key that can sign "documents of office". The >legislation changed how certain high-value monetary transactions can be >signed -- it didn't modify how the president does his job. Understood, thank you. The "act" of digitally signing the bill in question was an empty gesture, so to speak. Out of curiosity, was it accomplished with an entirely arbitrary "signing key" (a string of zeros, perhaps) or was the (empty) formalism carried further (formal parameters, certificate, etc.)? Is the signature formally (if not legally) verifiable? ___tony___ >At 04:44 PM 8/23/00 -0700, Philip Hallam-Baker wrote: > > > >I believe that the bill was in fact signed twice, once with a pen, but > >I also believe that >the concern about circularity is a red herring. > > > >It was a humorous observation I didn't expect you folk to make a federal > >case out of it! > >:) > >And I enjoyed the story of the Stuart King. > >But for the sake of "formalism" (and curiosity) doe anyone know just >what CA has certified this key? Or what the precise DN looks like? > >More to the point, was the entire exercise of signing with this key >just a cute charade, or does the U.S. President (now, officially) >have a digital key with which to sign "documents of the office", and >if so, what are the attributes of the corresponding certificate? > >(It must expire soon ;) > >The question of "who certifies the President's digital signature" >is an interesting one, in my view, not only now but in general. > >___tony___ > > >Tony Bartoletti 925-422-3881 >Information Operations, Warfare and Assurance Center >Lawrence Livermore National Laboratory >Livermore, CA 94551-9900 Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 From owner-ietf-pkix@imc.org Wed Aug 23 23:04:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27904 for ; Wed, 23 Aug 2000 23:04:12 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA22726; Wed, 23 Aug 2000 20:03:30 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 20:03:21 -0700 Received: from imo-r16.mx.aol.com (imo-r16.mx.aol.com [152.163.225.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22694 for ; Wed, 23 Aug 2000 20:03:20 -0700 (PDT) From: TeamDaguio@aol.com Received: from TeamDaguio@aol.com by imo-r16.mx.aol.com (mail_out_v28.15.) id o.ae.9ae2b68 (4207); Wed, 23 Aug 2000 23:01:23 -0400 (EDT) Message-ID: Date: Wed, 23 Aug 2000 23:01:22 EDT Subject: Re: President Clinton digital signing To: mbutler@tonbu.com, azb@llnl.gov, pbaker@verisign.com, bjueneman@novell.com, William.Flanigan@bmdo.osd.mil CC: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 119 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Dear Friends, The use of the dst or abaecom ca generated certificate to sign the bill electronically was certainly meaningful in a politically symbolic sense, but not the legal signature that transformed the bill into law. The President used his pen first and will continue to do so because of tradition. I suggest that the technical issues involved in the signing are not only not really meaningful, but also not interesting. We passed the bill we wanted by ignoring the technology and focusing on the issues that are meaningful to politicians and ordinary people. I repeately said, "This effort is not about technology or technology vendors. This effort is about the freedom to contract and the right to expect contracts to be enforced." I argued that the Federal and state governments should not interfere with voluntary contracts and should instead support and enforced such arrangements. We won on this basis without having to explain how the crypto or biometrics might work. The push to get where we are has taken a lot of time and effort, and I am proud to say that at no time has political fundraising or partisan politics played a role in the outcome. We won this one on the strength of our arguments and the soundness of our strategy. The path to legal certainty was a long one and the strategy required collaboration between a number of old Washington hands running both strategy and interference to prevent less fair and less reasonable approaches from gaining ground. I have been lobbying on these issues for nearly a decade and was pleased to see the basic underpinnings for a supportive legal infrastructure for electronic commerce created. (I worked at the US Treasury and the American Bankers Association doing technology strategy, policy, and standards for the industry) HISTORY OF THE EFFORT The federal government has had the power to determine itself what forms of legal arrangements can bind the executive, legislative, and judiciary branches to writings or agreements of any sort. Quite some time ago the Executive Branch (administrative, not political officers) exercising its legitimate sovereignty published a policy that clearly supported electronic authentication as a legitimate contracting mechanism that could bind the government and contractors to agreements. (this was not a spontaneous act) We followed up by pushing for and getting reduced regulatory overhead on an agency by agency and department by department basis. A little later the Government Paperwork Elimination Act reinforced and broadened the Federal legal infrastructure's support for electronic agreements between the government, individuals, and firms. (this incremental bit of legislation was critical to positioning the next and later steps) We again broadened and further supported the legal framework for electronic commerce by passing the most recent act, which provides for purely voluntary and arbitrary agreements between contracting parties. We have a bit of fine tuning to go and more to do. Some part of e-enabling commerce still requires that we push policy changes, but much more work is required to make the technologies offered as solutions meet the practical requirements of the real world. I suggest that the arrogance of technologists and technology vendors is the greatest obstacle to adoption and acceptance that PKI faces. We have the basic supportive legal infrastructure built (effective in october). I am looking foward to addressing the challenges presented by both the lack of a sufficiently supportive technological infrastructures and the lack of support for the deployment of the technology on a business case basis as well as a whole host of other business issues. I hope that each of you can help to make PKI more practical so that we can get pragmatists to see its value, buy it, pay for it, use it, and recommend it to each other. aloha...kawika kawika daguio 301 332 5224 From owner-ietf-pkix@imc.org Thu Aug 24 00:48:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29197 for ; Thu, 24 Aug 2000 00:48:29 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA25886; Wed, 23 Aug 2000 21:47:39 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Aug 2000 21:47:30 -0700 Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA25851 for ; Wed, 23 Aug 2000 21:47:29 -0700 (PDT) From: Lynn.Wheeler@firstdata.com Received: from mailgw.firstdata.com ([204.48.27.156]) by mail01-ewr.pilot.net with ESMTP id AAA10739; Thu, 24 Aug 2000 00:47:58 -0400 (EDT) Received: from lnsunr02.firstdata.com (localhost [127.0.0.1]) by mailgw.firstdata.com with SMTP id AAA02475; Thu, 24 Aug 2000 00:47:55 -0400 (EDT) Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256945.0019D1D1 ; Thu, 24 Aug 2000 00:42:01 -0400 X-Lotus-FromDomain: FDC To: Tom Strickland cc: Liaquat Khan , ietf-pkix@imc.org Message-ID: <85256944.006F22E1.00@lnsunr02.firstdata.com> Date: Wed, 23 Aug 2000 13:14:45 -0700 Subject: Re: President Clinton digital signing Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe a number of financial infrastructures not only need real-time status ... but also things like real time inforatmion, no single point of failrues and some even five nines availability. also looking at it from a transaction flow aspect, the transaction has to hit the account record (for other real time informaiton reasons ... like account balance) ... and involve an infrastructure that have existing business infrastructures with both authentication and authorization. For these types of financial infrastructures ... they need to control their own infrastructure including things like RAs ... where they do the public key registration in the account record ... and returning a copy of relying-party only certificate to the account holder (for liability and privacy reasons). The interesting thing is that these protocols appends a copy of the certificate to a signed message that is sent to the financial institution ... when the financial institution has the original of the certificate in the account record (an account record that has to be read in any case to perform the financial ttransaction). The simpler process is to recognize that it is superfulous and redundant to return a copy of a certificate (appended to every signed message) sent to a financial institution, a financial insitution that will be reading a record containing the original of the certificate. Since the master account record with not only real-time status as well real-time information is being read as part of executing the operation ... it not only eliminates the extraneous transmission of appended certificates, eliminates requirements for both CRL & OCSP checking, minimizes points of failures, and improves availability. misc. refs: http://www.garlic.com/~lynn/99.html#71 http://www.garlic.com/~lynn/99.html#128 http://www.garlic.com/~lynn/ansiepay.htm#aadsnew2 http://www.garlic.com/~lynn/aepay2.htm#position mapping of the draft x9.59 financial standard to existing online networks: http://www.garlic.com/~lynn/8583flow.htm Tom Strickland on 08/23/2000 05:31:12 AM ...... Example: If a company does not have a requirement for current information, a CRL is sufficient. If a company requires real time data (i.e. a bank or government) due to high value transactions or security, then I would highly recommend OCSP. The risk is if you use CRLs for the latter, the company may get a false sense of security believing their "high value" transactions are guarded by real time data. If the batch CRL is latent, you may continue processing utilizing old data. The risk is a cert believed to be revoked may still be considered good in the system exposing the company to potential fraud or negligence. In an OCSP environment, if you must trust real time data and someone executes a DoS attack, the responder may slow down or worst case, stop working. This is an added value because I would rather slow down or stop processing than to rely on old data. The risk here is slower response time but guaranteed accurate information. From owner-ietf-pkix@imc.org Thu Aug 24 07:20:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14684 for ; Thu, 24 Aug 2000 07:20:07 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA13307; Thu, 24 Aug 2000 04:19:17 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 24 Aug 2000 04:19:02 -0700 Received: from scog-ws3.gsa.gov (host.159-142-144-58.gsa.gov [159.142.144.58]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA13271 for ; Thu, 24 Aug 2000 04:19:02 -0700 (PDT) From: judith.spencer@gsa.gov Received: from 159.142.144.55 by scog-ws3.gsa.gov with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Thu, 24 Aug 2000 07:19:28 -0400 X-Server-Uuid: cb2f616c-ae65-11d3-874c-00508b6362bc Subject: RE: President Clinton digital signing To: mbutler@tonbu.com cc: judith.spencer@gsa.gov, William.Flanigan@bmdo.osd.mil, pbaker@verisign.com, terri.hobson@gsa.gov, marion.royal@gsa.gov, ietf-pkix@imc.org Sender: judith.spencer@gsa.gov Date: Thu, 24 Aug 2000 07:19:17 -0400 Message-ID: X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on SCOG-NOTESSMTP1/GSAEXTERNAL(Release 5.0.1b|September 30, 1999) at 08/24/2000 07:19:28 AM MIME-Version: 1.0 X-WSS-ID: 15BBDB4A251669-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA13272 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit The certificate used by the President was signed by the ACES CA. ACES is a GSA-sponsored governmentwide pki capability that includes the issuance of certificates under a Certificate Policy developed by the General Services Administration, Office of Governmentwide Policy. We do have a copy of the electronically signed bill and the signature can be verified. It is not available on line at this time, but it should be made available in the next few weeks. Ditto the certificate used by the President. I will let you know when it is available. Judy Spencer Office of Information Security General Services Administration "Mathew Butler" on 08/23/2000 02:25:42 PM To: "'judith.spencer@gsa.gov'" , William.Flanigan@bmdo.osd.mil cc: pbaker@verisign.com, terri.hobson@gsa.gov, marion.royal@gsa.gov, ietf-pkix@imc.org Subject: RE: President Clinton digital signing The question is, "Is there some certification authority that was designated by [whoever has the power to make the designation, be it Congress or the GSA or the GAO or whoever], that signed the certificate that President Clinton used to sign the bill, in order to ensure the authenticity and integrity of the signature [in order to make it legally binding]?" I know that there is nothing in law (even with the signing of this bill) that allows the President to ratify a bill with anything other than a physical signature and seal. Therefore, the entire question is completely ludicrous in the first place, as the answer is patently "No". However, there's a few questions I have... what CA -did- sign the certificate that President Clinton used? Is there an actual copy of the electronically signed version of the bill, including signature, online that we can look at? Also, can we get a copy of the certificate that he used, along with the entire certificate chain to the certificate for the root? (Rather than spamming the list, is there a URL on the GSA's website that would provide access to this information?) Thanks! -Mat Butler -----Original Message----- From: judith.spencer@gsa.gov [mailto:judith.spencer@gsa.gov] Sent: Wednesday, August 23, 2000 9:55 AM To: William.Flanigan@bmdo.osd.mil Cc: pbaker@verisign.com; terri.hobson@gsa.gov; judith.spencer@gsa.gov; marion.royal@gsa.gov; ietf-pkix@imc.org Subject: RE: President Clinton digital signing The e-signing of the bill was a demonstration of the technology. You're right. The bill was officially signed with a pen and then a wax seal was applied. I'm having a little trouble with your "circular reference" statement and that the bill is a "self-signed certificate". Perhaps you'd be willing to explain your reasoning to me more fully. Judy Spencer "Flanigan, William, CIV,BMDO/DSC" on 08/23/2000 09:37:06 AM To: "'Philip Hallam-Baker'" cc: terri.hobson@gsa.gov, judith.spencer@gsa.gov, "'marion.royal@gsa.gov'" , ietf-pkix@imc.org Subject: RE: President Clinton digital signing Right on Philip (as usual)!  But it seems unlikely that the bill was not "signed" twice, one being a wet signature (with no photo op).  Does anyone know for sure? Bill Flanigan -----Original Message----- From: Philip Hallam-Baker [mailto:pbaker@verisign.com] Sent: Tuesday, August 22, 2000 9:08 PM To: 'marion.royal@gsa.gov'; ietf-pkix@imc.org Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov Subject: RE: President Clinton digital signing [snip] And it was totally illogical to use a digital signature for the purpose. The act is now effectively a self-signed cert! The validity of the authentication on the act is established through a circular reference to the act itself.               Phill From owner-ietf-pkix@imc.org Thu Aug 24 09:52:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17127 for ; Thu, 24 Aug 2000 09:52:41 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA17776; Thu, 24 Aug 2000 06:51:46 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 24 Aug 2000 06:51:30 -0700 Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA17745 for ; Thu, 24 Aug 2000 06:51:29 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Aug 2000 09:51:29 -0400 Message-ID: <3120721CA75DD411B8340090273D20B1271F19@sottmxs06.entrust.com> From: Sharon Boeyen To: "'Stephen Kent'" , d.w.chadwick@salford.ac.uk Cc: ietf-pkix@imc.org, "Kurt D. Zeilenga" , osidirectory@az05.bull.com Subject: RE: Undefined combinations of extensions Date: Thu, 24 Aug 2000 09:47:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I agree that this would be a valuable profiling activity and would hopefully address the issues David raised without any impact on the criticality flag. PKIX could certainly impose requirements on the set of combinations that are valid for a PKIX issued certificate, however validation engines still need to be able to cope with PKIX and non-PKIX issued certificates. Sharon -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Wednesday, August 23, 2000 3:34 PM To: d.w.chadwick@salford.ac.uk Cc: ietf-pkix@imc.org; Kurt D. Zeilenga; osidirectory@az05.bull.com Subject: Re: Undefined combinations of extensions David, Your question about combinations of extensions, and base certificate/CRL fields, is a good one. Tim Polk and I discussed this issue during the last PKIX WG meeting, in a more limited context. I proposed that we include a table that described syntactic constraints among all the fields in a cert or CRL, to address the question of which combinations of fields and values are valid. One cannot do this for really private extensions, and doing it for new extensions that are publicly disclosed is an ongoing task. But, at least we should provide folks with a base set of constraints. I think 2459 should do this and I volunteered to provide a draft table for this. Steve From owner-ietf-pkix@imc.org Fri Aug 25 03:37:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13731 for ; Fri, 25 Aug 2000 03:37:34 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA13768; Fri, 25 Aug 2000 00:36:28 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 25 Aug 2000 00:35:10 -0700 Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.121.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA13644 for ; Fri, 25 Aug 2000 00:35:08 -0700 (PDT) Received: from [38.29.124.224] (ip224.phoenix12.az.pub-ip.psi.net [38.29.124.224]) by harrier.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id AAA00520; Fri, 25 Aug 2000 00:35:32 -0700 (PDT) Mime-Version: 1.0 X-Sender: hoytkesterson@mail.earthlink.net Message-Id: In-Reply-To: <3120721CA75DD411B8340090273D20B1271F0E@sottmxs06.entrust.com> References: <3120721CA75DD411B8340090273D20B1271F0E@sottmxs06.entrust.com> Date: Thu, 24 Aug 2000 23:55:18 -0700 To: Sharon Boeyen , "'d.w.chadwick@salford.ac.uk'" , ietf-pkix@imc.org From: "Hoyt L. Kesterson II" Subject: RE: Undefined combinations of extensions Cc: "Kurt D. Zeilenga" , osidirectory@az05.bull.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe i want to support sharon on her statement on the intent of the DR. the text that will be added to the standard to resolve the defect report will make it clear that if an implementation "recognizes" an extension, then that implementation shall support THAT extension according to the syntax and procedures specified in the clauses defining THAT extension. one of the problems of viewing the x.509 standard by itself is that we have lost the valuable concept of the statement of conformance. i hope that the approved text will correct this lack. this concern about relationships between extensions can be addressed in a variety of ways. for example, an environment, such as a vertical sector, could decide that certain extensions must be present (regardless of criticality settings) before a certificate is acceptable. in addition, permitted and disallowed combinations of extensions, or values within those extensions, could also be specified in a profile for that environment. only implementations with statements of proper conformance would be deployed into that environment. however, the reason for extensibility, including criticality, must always be kept in mind - correct interoperation using an acceptable, commonly understood subset of information in a certificate. one is permitted to define a new extension,X, that, if present, influences the interpretation of one or more other extensions, Y. however, if the issuer of a certificate wants to ensure that Y will always be interpreted in the new fashion, it must declare X critical (or know that the certificate will only be used within an environment that understands, and requires the presence of, X). if the issuer does not adhere to this principle, an implementation that is unaware of the definition of X will ignore X but will process Y according to the rules the implementation understand, i.e. without the nuances associated with the presence of X. hoyt At 1:07 PM -0400 8/23/00, Sharon Boeyen wrote: >The defect report is clarifying, not changing, the way criticality >is treated for certificate extensions. Criticality applies to each >extension independent of all others. Clearly, if one extension is >included in a certificate as critical (e.g. certificate policies) >and another is included as non-critical (e.g. policy mappings), then >there will be different results by relying party systems that do >support policy mappings and ones that do not. However, there should >be no difference in relying party systems that do support the extensions >regardless of their criticality. > > > >A CA sets the criticality flag for each and every extension as it sees >fit. By setting an extension non-critical, the CA is accepting the fact >that relying party systems that do not understand this extension will ignore >it when processing the certificate and relying party systems that do >understand it will process it. When it sets the flag critical it is >limiting the relying parties to ONLY those that understand the extension. > >Any semantic relationship between two or more extensions (e.g. among the >policy related ones) needs to be addressed by the issuer (for instance >it doesn't make a lot of sense to issue a certificate with critical >policy mappings but non-critical certificate policies). This is a policy >issue though not one that the criticality flag should be used to solve. > >If there is a situation where two extensions may cause conflicting >impacts (e.g. the issuingDistributionPoint extension and the crlScope >extension), then the definition of the extensions themselves should >contain the semantics of what is to be done (see the definition of >crlScope which states that these 2 are not intended to be used together >but states what the rule is if both happen to be present). > >If the problem you are trying to solve is that extensions have not >been properly or fully defined, then that problem should be fixed in >the extension definitions themselves, not by trying to invert the meaning >of critical and non critical in the standard. > >Is there a concrete example you can share, that might bring to light some >point I'm missing? > > >Sharon > > > > > > >> -----Original Message----- >> From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk] >> Sent: Wednesday, August 23, 2000 12:36 PM >> To: ietf-pkix@imc.org >> Cc: Kurt D. Zeilenga; osidirectory@az05.bull.com >> Subject: Undefined combinations of extensions >> >> >> On the LDAPExt list we have been discussing the effects of >> combinations of extensions (controls in LDAP jargon) on the LDAP > > server performing an LDAP operation, when the effects of the > > combination of one or more extensions is not understood by the > > server. The server may understand each separate extension, but >> not the semantics of them in combination. >> >> It seems to me that PKIX/X.509 will have (or already may have >> encountered) this same problem for COMBINATIONS of certificate >> extensions (some of which may be private, some de-facto, some >> critical, some not) that are thought to be understood by the issuing >> CA, but are not fully understood by the relying party / validation >> engine. >> >> What text does anyone have for this situation? I believe the recently >> issued X.509 defect report 244, raised by Sharon, only discusses >> the case of a single extension in isolation, and does not discuss the >> effects of combinations of extensions. >> >> The most interesting cases are when the RP finds combinations of >> extensions, where each extension on its own is understood, but >> where the combined semantics are not fully understood (possibly >> due to incomplete or ambiguous specification of extension >> interactions when the extensions are written by different >> groups). In >> this case, LDAP is suggesting that a receiver may ignore non- >> critical extensions (even those it recognizes) to establish the >> semantics of the operation. This is in direct contrast to the wording >> of defect report 244, which states that an understood non-critical >> extension must be obeyed. The LDAP work would suggest an >> addition to DR244 along the lines of >> >> " A validation engine that does not understand the interaction of a >> non-critical extension with another extension (critical or >> non-critical), >> may ignore the non-critical extension (even if it understands the >> semantics of the extension in isolation to the others), and >> accept the >> certificate (unless factors other than this extension cause it to be >> rejected). >> >> A validation engine that does not understand the interaction of two >> critical extensions, must reject the certificate (even if it >> understands >> the semantics of both extensions in isolation to each other)." >> >> David >> >> >> >> *************************************************** >> >> David Chadwick >> IS Institute, University of Salford, Salford M5 4WT >> Tel +44 161 295 5351 Fax +44 161 745 8169 >> Mobile +44 790 167 0359 >> Email D.W.Chadwick@salford.ac.uk >> Home Page http://www.salford.ac.uk/its024/chadwick.htm >> Understanding X.500 http://www.salford.ac.uk/its024/X500.htm >> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm >> Entrust key validation string MLJ9-DU5T-HV8J >> >> *************************************************** >> From owner-ietf-pkix@imc.org Fri Aug 25 14:20:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26637 for ; Fri, 25 Aug 2000 14:20:50 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA25396; Fri, 25 Aug 2000 11:19:56 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 25 Aug 2000 11:19:43 -0700 Received: from mailhost.tdpt.net ([63.146.0.238]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25362 for ; Fri, 25 Aug 2000 11:19:42 -0700 (PDT) Received: from tidepoint.net ([192.168.10.52]) by mailhost.tdpt.net (Netscape Messaging Server 4.15) with ESMTP id FZV1LD00.U6R for ; Fri, 25 Aug 2000 14:20:01 -0400 Message-ID: <39A6B8A2.C6B2548A@tidepoint.net> Date: Fri, 25 Aug 2000 14:19:14 -0400 From: "Mitchell Arnone" Organization: TidePoint X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF-PKIX LIST Subject: certificate management tools Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msB55DFE58D568D791D191F597" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a cryptographically signed message in MIME format. --------------msB55DFE58D568D791D191F597 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am looking for some tools that will allow me to convert PEM encoded certificates (ASCII or Binary) into simple readable text. Does anyone know where there might be some freeware or shareware utilities for digital certificates? Thanks Mitch --------------msB55DFE58D568D791D191F597 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIIKwYJKoZIhvcNAQcCoIIIHDCCCBgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BcwwggLXMIICQKADAgECAhEArBkEZgAAAnwAAAAVAAAACTANBgkqhkiG9w0BAQUFADCBtjEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCE1hcnlsYW5kMRIwEAYDVQQHEwlCYWx0aW1vcmUxHjAc BgNVBAoTFVRpZGVQb2ludCBDb3Jwb3JhdGlvbjEMMAoGA1UECxMDUEtJMR8wHQYDVQQDExZU aWRlUG9pbnQgQ29ycG9yYXRlIENBMTEwLwYJKoZIhvcNAQkBFiJicmlhbi5kaWxsZXlAYjJi Y29tbXVuaWNhdGlvbnMuY29tMB4XDTAwMDgwMTE0NTcxNloXDTAzMDcwMzIwMTgxNlowgYox CzAJBgNVBAYTAnVzMREwDwYDVQQIEwhNYXJ5bGFuZDESMBAGA1UEBxMJQmFsdGltb3JlMR4w HAYDVQQKExVUaWRlUG9pbnQgQ29ycG9yYXRpb24xDDAKBgNVBAsTA1BLSTEmMCQGA1UEAxMd TWl0Y2hlbGwgVCBBcm5vbmUgKFNpZ25hdHVyZSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALRwJhDwGHIxVV5FNHITbjGCeccK70+6vZ5xegTDflWwoJXb2T1eEqHZTZ+NUmgHTaNj ckbS4RP0CbO7bnthENbknm/dj77gzMQy1ouZgctMNbkR9ktry4MGvn1sNkCnNJD4I5eRlWuw FDIwn3OB8Q4Mm45omq9+9TWeSKYzRJbJAgMBAAGjDzANMAsGA1UdDwQEAwIHgDANBgkqhkiG 9w0BAQUFAAOBgQCHSm7EfCrk9ZDWvKxTbu4xWgCq+z2unLCnI2lSU8QJpRtqk1qfrCx1ZoE7 C6kcef+oo36NNJQWSX6lI6IvwA0GRM20aW/J11keuiZvNnOG2xqYbp8GAtiCpY2c4j06a1wW JyHLiPrT+APVq+9HGYv+aC1a9q7hXHHd4Z3yZWaSWTCCAu0wggJWAhEArBkEZQAAAnwAAAAC AAAABDANBgkqhkiG9w0BAQUFADCBtjELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE1hcnlsYW5k MRIwEAYDVQQHEwlCYWx0aW1vcmUxHjAcBgNVBAoTFVRpZGVQb2ludCBDb3Jwb3JhdGlvbjEM MAoGA1UECxMDUEtJMRwwGgYDVQQDExNUaWRlUG9pbnQgUHJpbmNpcGxlMTQwMgYJKoZIhvcN AQkBFiVtaXRjaGVsbC5hcm5vbmVAYjJiY29tbXVuaWNhdGlvbnMuY29tMB4XDTAwMDcwNjIw MTk1N1oXDTAzMDcwNjIwMTk1N1owgbYxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNYXJ5bGFu ZDESMBAGA1UEBxMJQmFsdGltb3JlMR4wHAYDVQQKExVUaWRlUG9pbnQgQ29ycG9yYXRpb24x DDAKBgNVBAsTA1BLSTEfMB0GA1UEAxMWVGlkZVBvaW50IENvcnBvcmF0ZSBDQTExMC8GCSqG SIb3DQEJARYiYnJpYW4uZGlsbGV5QGIyYmNvbW11bmljYXRpb25zLmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEA1/CKGYEMULAuj6+5EYuFl1R6NvmslYywzTFL5suvKNeEH5rA jH8jlV6qv7ugoryeL+130Atsh1muS+bKDYUTg+eCSNTZ0G0Pi4qLzzNwZPxTk7prJvErD0b8 3ByEZb+7LJ0wXeI5TxU8n2sLWecHKnXmQTpVrxA6Ub0uOxFbbKsCAwEAATANBgkqhkiG9w0B AQUFAAOBgQBIAW6ADXwSIanrFKnX66xdWXlblwc2pfasIr3uDrPBRSpwrvt8RyCM+eWUByAi G03AD+y40G0hdMEoljZMgZabeZ5fwtM3zLm13z9G/ec7oU2jUNy7N9MQ6HNg8kd2kDNNoSDR yG1sYLPBSIPgtghDZg2MnxBxc40GVDzxaUXVGzGCAicwggIjAgEBMIHMMIG2MQswCQYDVQQG EwJVUzERMA8GA1UECBMITWFyeWxhbmQxEjAQBgNVBAcTCUJhbHRpbW9yZTEeMBwGA1UEChMV VGlkZVBvaW50IENvcnBvcmF0aW9uMQwwCgYDVQQLEwNQS0kxHzAdBgNVBAMTFlRpZGVQb2lu dCBDb3Jwb3JhdGUgQ0ExMTAvBgkqhkiG9w0BCQEWImJyaWFuLmRpbGxleUBiMmJjb21tdW5p Y2F0aW9ucy5jb20CEQCsGQRmAAACfAAAABUAAAAJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwODI1MTgxOTE0WjAjBgkqhkiG 9w0BCQQxFgQUSfZ3Ymdww0aIu5lM2+qKELcw1TkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcN AwICASgwDQYJKoZIhvcNAQEBBQAEgYB/RIuOx0miMmCLelOETl1OIYA7sUjpTebQFfFJl/BH yAr7/fEJDGpYhIrOWKbYbqKrSohNc3dDYnrzO1JHs6Rb+HBdVEOzc45v9zl2IRA5mYp/4Uty Hv/s6ZDNpAgbc2IPQ/ITiFkdvDk1Q1+9iQnk3y4Te2UREiki/0F9NcsJwg== --------------msB55DFE58D568D791D191F597-- From owner-ietf-pkix@imc.org Fri Aug 25 14:33:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26874 for ; Fri, 25 Aug 2000 14:33:28 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA26533; Fri, 25 Aug 2000 11:32:31 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 25 Aug 2000 11:32:29 -0700 Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26500 for ; Fri, 25 Aug 2000 11:32:28 -0700 (PDT) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Fri, 25 Aug 2000 11:28:35 -0700 Message-ID: <69A40A314934D41190C70050DAD7F99063B597@MAIL> From: Mathew Butler To: "'Mitchell Arnone'" , IETF-PKIX LIST Subject: RE: certificate management tools Date: Fri, 25 Aug 2000 11:28:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe OpenSSL, at www.openssl.org. Use 'openssl x509 -noout -text -in ' (where is not a literal less-than/greater-than, but the name of the file that contains the PEM-encoded certificate). -Mat -----Original Message----- From: Mitchell Arnone [mailto:mitchell.arnone@tidepoint.net] Sent: Friday, August 25, 2000 11:19 AM To: IETF-PKIX LIST Subject: certificate management tools I am looking for some tools that will allow me to convert PEM encoded certificates (ASCII or Binary) into simple readable text. Does anyone know where there might be some freeware or shareware utilities for digital certificates? Thanks Mitch From owner-ietf-pkix@imc.org Sun Aug 27 22:01:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14758 for ; Sun, 27 Aug 2000 22:01:17 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA21747; Sun, 27 Aug 2000 18:59:51 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sun, 27 Aug 2000 18:58:58 -0700 Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA21590 for ; Sun, 27 Aug 2000 18:58:40 -0700 (PDT) Received: (qmail 31425 invoked from network); 28 Aug 2000 02:59:25 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 28 Aug 2000 02:59:25 -0000 Reply-To: From: "Steven Legg" To: , Subject: Matching Rules for Constructed Syntaxes Date: Mon, 28 Aug 2000 12:58:31 +1000 Message-ID: <000301c0109b$d9bf6bb0$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit LDAPers and PKIXers, The LDAP ACI model and PKIX both have to deal with attribute syntaxes that are complex constructed types. Matching rules for those syntaxes have recently been discussion topics so it seems like a good time to describe some ideas for matching rules that have been kicking around in the back of my head for a while. First I'll address the question of an equality matching rule for ldapACI and then go on to describe some generic matching rules for complex syntaxes that would be useful to both LDAP access control and PKIX, among other things. One approach for ldapACI is the X.500 solution where a DirectoryString label has been made a component of the ACI and the directoryStringFirstComponentMatch matching rule is used to decide the equality of two ACIs. This satisfies some basic requirements to be able to match ACIs but the equality of two ACI values doesn't really say anything about them at the semantic level. Back when I was with Telstra we defined a catch-all equality matching rule that could do a comparison of two attribute values of any arbitrary ASN.1 syntax. This rule, or something like it, could be used as the equality matching rule for the ldapACI attribute. The X.500 style definition is simply this: asn1Match MATCHING-RULE ::= { ID { 1 3 32 0 1 13 0 } } Since no assertion syntax is specified, the syntax is inherited at run time from the attribute type to which the matching rule is applied. So the assertion syntax would be LdapACI if asn1Match is used to match against the ldapACI attribute. I have a slight problem defining this matching rule in LDAP terms because the string encoding for MatchingRuleDescription doesn't allow an absent SYNTAX. This matching rule evaluates to true if and only if the attribute value and the assertion value have the same components with the same values. If the syntax is a SEQUENCE or SET type then each component in the assertion value must match each component of the attribute value. Optional components must be either both present or both absent. If the syntax is a SEQUENCE OF then the attribute value and the assertion value must have the same instances (members) in the same order. If the syntax is a SET OF then the attribute value and the assertion value must have the same instances (and the same duplicates), but order doesn't matter. If the syntax is a CHOICE then the attribute value and the assertion value must use the same CHOICE alternative. The rules apply recursively to nested constructed types. The primitive types like OBJECT IDENTIFIER, BOOLEAN, INTEGER, etc match as one would expect. The string types are just matched character for character. The asn1Match rule would be fine as the equality matching rule for the ldapACI attribute and would have much the same effect as was intended by the original use of caseIgnoreMatch and DirectoryString syntax. However, where there is a complex constructed syntax there is usually a desire to selectively match only some of the components, e.g. to match ACIs with a specific subject, or with specific rights. What usually happens is that a bunch of new matching rules are defined to cover the anticipated needs. Just look at X.509 and PKI for examples. Rather than going down this path I would like to suggest a generic way of selectively matching components in arbitrary syntaxes. The following matching rule is something I've often thought about implementing but haven't as yet. componentMatch MATCHING-RULE ::= { SYNTAX ComponentAssertion ID } ComponentAssertion ::= SEQUENCE { component [0] PrintableString, rule [1] MATCHING-RULE.&id, -- MatchingRuleId value [2] MATCHING-RULE.&AssertionType -- AssertionValue } The idea here is that the component field identifies which part of a value of a constructed syntax is to be matched, the rule indicates how that part is to be matched, and the value is what that part is matched against. X.680, section 12 already describes a way to reference the components of an arbitrary ASN.1 type but it hasn't got a BER encoding so I'm just stuffing it as text into a PrintableString. Basically the component referencing string is a series of "." separated componentIds where a componentId is usually the ASN.1 identifier for the component. The componentId can also be a positive number to reference a particular instance in a SET OF or SEQUENCE OF, "*" to reference all the instances in a SET OF or SEQUENCE OF, or the number zero, which is a conceptual count of the number of instances. An example should make this clearer. First, here is the ASN.1 definition of the syntax of the objectClasses schema attribute (not to be confused with the objectClass attribute), so that I have something reasonably familiar to base examples on. ObjectClassDescription ::= SEQUENCE { identifier OBJECT-CLASS.&id, name SET OF DirectoryString { ub-schema } OPTIONAL, description DirectoryString { ub-schema } OPTIONAL, obsolete BOOLEAN DEFAULT FALSE, information [0] ObjectClassInformation } ObjectClassInformation ::= SEQUENCE { subclassOf SET OF OBJECT-CLASS.&id OPTIONAL, kind ObjectClassKind DEFAULT structural, mandatories [3] SET OF ATTRIBUTE.&id OPTIONAL, optionals [4] SET OF ATTRIBUTE.&id OPTIONAL } OBJECT-CLASS.&id and ATTRIBUTE.&id are equivalent to the OBJECT IDENTIFIER ASN.1 type. So for a given value with the ObjectClassDescription syntax (i.e. a value of the objectClasses attribute) ... "identifier" references the OID of the object class description, "description" references the text description of the object class, "name.*" references all of the object class's names, "name.0" gives the number of names defined for the object class, "name.1" references the first of those names, "information" references the whole ObjectClassInformation nested SEQUENCE, "information.kind" references the ObjectClassKind in the nested SEQUENCE, "information.mandatories.*" references all the mandatory attribute types for the object class ... and so on. Each referenced component has a specific ASN.1 type. For example, "identifier" is of type OBJECT IDENTIFIER and "name.1" is of type DirectoryString. The type of "information.mandatories" is SET OF OBJECT IDENTIFIER but the corresponding type for "information.mandatories.*" I'll take to be OBJECT IDENTIFIER (the instance type of the SET OF). The ".0" instance counts I'll assume to be INTEGER. Now that I've got a way to reference components I need to say how they are matched. I could specify a new bunch of rules for different kinds of matching on different ASN.1 types but it is convenient to just use existing attribute matching rules. Each matching rule has a notional set of attribute syntaxes (typically one), defined as ASN.1 types, to which it may be applied. When embedded in a ComponentAssertion these matching rules apply to the same ASN.1 types, only in this context the types aren't necessarily attribute syntaxes. So the "identifier" component of an objectClasses attribute value could be matched with objectIdentifierMatch. The "name.*" component (instances) could be matched with caseIgnoreMatch, caseExactMatch, caseIgnoreOrderingMatch, or even caseIgnoreSubstringMatch. Any component, regardless of its ASN.1 type could be matched by the asn1Match rule. The assertion value that goes with the chosen matching rule will be of the syntax required by that rule. Because constructed types can have CHOICEs and OPTIONAL fields it is possible that the referenced component does not exist in an attribute value. In these cases the matching rule would evaluate to false. Now for a few example filters using the componentMatch matching rule. I don't want to go to the trouble of defining complete ABNF right now so I'm using a string encoding that is a mix of ASN.1 value notation, which I trust is verbose enough to be sufficiently clear, and LDAP string encodings for well known ASN.1 types. I've put in spacing and line breaks only as an aid to readability. The example search filters are mostly single extensible match filter items, though of course there is no reason why componentMatch can't be used in more complicated search filters. To find the object class definition for the object class called foobar use the filter: (objectClasses:componentMatch:={ component "names.*", rule caseIgnoreMatch, value "foobar" }) An object class definition can have multiple names and the above filter will match an objectClasses value if any one of the names is "foobar". To find all obsolete object classes use: (objectClasses:componentMatch:={ component "obsolete", rule booleanMatch, value TRUE }) To find all subclasses of "person" use: (objectClasses:componentMatch:={ component "information.subclassOf.*", rule objectIdentifierMatch, value person }) To find the object class definition for 2.5.6.18 use: (objectClasses:componentMatch:={ component "identifier", rule objectIdentifierMatch, value 2.5.6.18 }) A match on the "identifier" component of objectClasses values is equivalent to the objectIdentifierFirstComponentMatch matching rule applied to this attribute type. The componentMatch matching rule subsumes the objectIdentifierFirstComponentMatch, integerFirstComponentMatch and directoryStringFirstComponentMatch matching rules. To find all values of the ldapACI attribute that have my DN in the subject field I could use (refer to draft-ietf-ldapext-acl-model-06.txt for the ASN.1 type definition of the ldapACI syntax): (ldapACI:componentMatch:={ component "subject.dn", rule distinguishedNameMatch, value "cn=Steven Legg, o=Adacel, c=au" }) The subject component is a CHOICE of which "dn" is one of several possibilities. Those values with a different choice won't match the filter item. To find all ACIs that apply to the commonName attribute: (ldapACI:componentMatch:= { component "attr.attributes.*", rule objectIdentifierMatch, value cn }) The componentMatch rule allows any one component in a constructed value to be matched but there are often good reasons to want to match more than one component in the same constructed value. This is particularly true for the matching of certificates and related constructs in PKIX. Most, if not all, of the desired functionality could be achieved with the following matching rule whose assertion syntax is a filter of component matches. componentFilterMatch MATCHING-RULE ::= { SYNTAX ComponentFilter ID } ComponentFilter ::= CHOICE { item [0] ComponentAssertion, and [1] SEQUENCE OF ComponentFilter, or [2] SEQUENCE OF ComponentFilter, not [3] ComponentFilter } The component filter is evaluated over a single attribute value rather than a whole entry. Note that a matching rule like this gives us the same capability for matching components of a constructed syntax that a regular search filter would give us had the constructed syntax been exploded out as a set of attributes of simpler syntaxes in a subordinate entry. The observant will notice that componentMatch is a special case of componentFilterMatch so we don't really need componentMatch. Here are some example search filters using the componentFilterMatch matching rule. To find all object class definitions that reference the commonName AND surname attributes as mandatory attributes use: (objectClasses:componentFilterMatch:=and:{ item:{ component "information.mandatories.*", rule objectIdentifierMatch, value cn }, item:{ component "information.mandatories.*", rule objectIdentifierMatch, value sn } }) To find all object class definitions that reference the commonName AND surname attributes as either mandatory OR optional attributes: (objectClasses:componentFilterMatch:=and:{ or:{ item:{ component "information.mandatories.*", rule objectIdentifierMatch, value cn }, item:{ component "information.optionals.*", rule objectIdentifierMatch, value cn } }, or:{ item:{ component "information.mandatories.*", rule objectIdentifierMatch, value sn }, item:{ component "information.optionals.*", rule objectIdentifierMatch, value sn } } }) The next example is inspired by Sean Mullan. Sean Mullan wrote: > What happens if you want to define a matching rule to only retrieve certs > that contain a specific basic constraints value AND a certain issuer name? In > this case, you would define 2 matching rules and specify both of them in > the valuesReturnFilter control. But then you would get all certs with the > requested issuer name and any basic constraints value and all certs with > any issuer name and the requested basic constraints value. That's not > what you wanted. I think we may want to enhance the valuesReturnFilter > control (through a flag, perhaps) to allow the user to apply all of the > elements of the filter to each attribute value. Let's discuss this more > offline, if you like. Here is a component filter match on a specific value of basic constraints AND a certain issuer name: (userCertificate:componentFilterMatch:=and:{ item:{ component "extensions.*", rule asn1Match, value { extnId 2.5.29.19, extnValue '3003020102'H } }, item:{ component "issuer.rdnSequence", rule distinguishedNameMatch, value "cn=CA, o=Adacel, c=au" } }) 2.5.29.19 is the OID for the basicConstraints extension. Unfortunately the extension value (extnValue) is defined to be a DER encoding wrapped in an OCTET STRING (ugh!). In the above example it was particularly convenient to use the asn1Match rule to match the whole extension, i.e. { extnId 2.5.29.19, extnValue '3003020102'H }, in one hit, instead of writing a nested "and" filter of each of the components of the extension. The asn1Match rule is essentially a short hand for an "and" component filter specifying every component. I can imagine situations where it would be useful to test not only if a *specific* value of a particular component is present but whether *any* value of a particular component is present. Hence the following matching rule: presentMatch MATCHING-RULE ::= { SYNTAX NULL ID } When used on an attribute in a extensible match filter item it behaves like the present case of a regular search filter. In a ComponentAssertion it evaluates to true if and only if the referenced component exists. To find object class definitions that have descriptions use: (objectClasses:componentMatch:= { component "description", rule presentMatch, NULL }) To find object class definitions that don't have descriptions use: (objectClasses:componentFilterMatch:= not:item:{ component "description", rule presentMatch, NULL }) To find the object class definitions that are not marked as obsolete (the "obsolete" component is absent, or is present and set to FALSE): (objectClasses:componentFilterMatch:=or:{ not:item:{ component "obsolete", rule presentMatch, NULL }, item:{ component "obsolete", rule booleanMatch, FALSE } }) The DistinguishedName and RelativeDistinguishedName ASN.1 types are also constructed types so the component matching rules could be applied to them. For convenience, here is the stripped down ASN.1 type for DNs. DistinguishedName ::= SEQUENCE OF RelativeDistinguishedName RelativeDistinguishedName ::= SET OF AttributeTypeAndValue AttributeTypeAndValue ::= SEQUENCE { type AttributeType, -- OBJECT IDENTIFIER value AttributeValue -- ANY } To find all seeAlso attributes (DN syntax) containing the RDN "o=Adacel" use: (seeAlso:componentMatch:= { component "*", rule componentFilterMatch, value and:{ item:{ component "0", rule integerMatch, value 1 }, item:{ component "*", rule asn1Match, value { type o, value "Adacel" } } } }) This assertion tests each RDN (referenced by the first "*") to see if it has exactly one AVA (the count is given by "0") with attribute type organization and value "Adacel". Since RDNs appear all over the place it makes sense to define a matching rule that can make RDN matching more concise. rdnMatch MATCHING-RULE ::= { SYNTAX RelativeDistinguishedName ID } The rdnMatch rule evaluates to true if the component value and assertion value are the same RDN. Now the above example to find all seeAlso attributes containing the RDN "o=Adacel" becomes: (seeAlso:componentMatch:={ component "*", rule rdnMatch, value "o=Adacel" }) The rdnMatch can be useful wherever DNs appear. To find all values of the ldapACI attribute that have "o=Adacel" somewhere in the DN in the subject field use: (ldapACI:componentMatch:= { component "subject.dn.*", rule rdnMatch, value "o=Adacel" }) To find all seeAlso values with "o=Adacel, c=au" as a "suffix" (noting that the string encoding of LDAPDN puts the RDNs in reverse order) use: (seeAlso:componentFilterMatch:=and:{ item:{ component "1", rule rdnMatch, value "c=au" }, item:{ component "2", rule rdnMatch, value "o=Adacel" } }) There's a case for being able to specify a match against the last component, or second last component, etc, but we'd have to invent a syntax for that. Okay, so what do people think ? The value of componentFilterMatch and friends is that they implicitly define a bunch of useful matching rule semantics for a new attribute syntax the moment the ASN.1 type is written down, and are automatically extended if the ASN.1 type is later extended. We might never need to define another matching rule for a constructed syntax. What would be missing though is a definition of the string encoding, so having a predictable way of generating the ABNF from the ASN.1 type would be particularly valuable. For the examples above I didn't formally define the string encoding for ComponentAssertion and ComponentFilter, themselves constructed types, but I was consistently following a set of rules. Those rules would be my preferred solution for algorithmically derived string encodings for new attribute and assertion syntaxes. Since the componentFilterMatch is generally useful, and can be applied to any ASN.1 type, it makes more sense for me to write it up as a separate Internet draft under the auspices of LDAPEXT, rather than incorporating its definition into either the LDAP ACL model or the PKIX LDAP schema. So is there support out there for me to go ahead and write this up as an ID ? Will LDAP access control and PKIX make use of it ? Regards, Steven From owner-ietf-pkix@imc.org Mon Aug 28 01:41:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21911 for ; Mon, 28 Aug 2000 01:41:43 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA03209; Sun, 27 Aug 2000 22:40:32 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sun, 27 Aug 2000 22:40:24 -0700 Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA03173 for ; Sun, 27 Aug 2000 22:40:23 -0700 (PDT) Received: (qmail 19681 invoked from network); 28 Aug 2000 06:41:17 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 28 Aug 2000 06:41:17 -0000 Reply-To: From: "Steven Legg" To: , Subject: RE: Matching Rules for Constructed Syntaxes Date: Mon, 28 Aug 2000 16:40:19 +1000 Message-ID: <000801c010ba$d64288e0$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-reply-to: <000301c0109b$d9bf6bb0$b05508cb@osmium.adacel.com.au> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Oops! I misread the ASN.1 for LdapACI. This: > (ldapACI:componentMatch:={ > component "subject.dn", > rule distinguishedNameMatch, > value "cn=Steven Legg, o=Adacel, c=au" }) should read: (ldapACI:componentMatch:={ component "subject.subject.dn", rule distinguishedNameMatch, value "cn=Steven Legg, o=Adacel, c=au" }) and this: > (ldapACI:componentMatch:= > { component "subject.dn.*", rule rdnMatch, value "o=Adacel" }) should read: (ldapACI:componentMatch:={ component "subject.subject.dn.*", rule rdnMatch, value "o=Adacel" }) Cheers, Steven From owner-ietf-pkix@imc.org Mon Aug 28 10:01:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09354 for ; Mon, 28 Aug 2000 10:01:30 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA15094; Mon, 28 Aug 2000 07:00:28 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 28 Aug 2000 07:00:11 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15059 for ; Mon, 28 Aug 2000 07:00:10 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09258; Mon, 28 Aug 2000 10:00:59 -0400 (EDT) Message-Id: <200008281400.KAA09258@ietf.org> To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: The IESG SUBJECT: Last Call: Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP) to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 28 Aug 2000 10:00:59 -0400 Sender: scoya@cnri.reston.va.us Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe The IESG has received a request from the Public-Key Infrastructure (X.509) Working Group to consider Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by September 8, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-09.txt From owner-ietf-pkix@imc.org Mon Aug 28 10:40:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10910 for ; Mon, 28 Aug 2000 10:40:05 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA16047; Mon, 28 Aug 2000 07:39:00 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 28 Aug 2000 07:38:54 -0700 Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16016 for ; Mon, 28 Aug 2000 07:38:49 -0700 (PDT) Received: from dwc-acer ([62.252.106.112]) by mta01-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20000828143939.QQRU26680.mta01-svc.ntlworld.com@dwc-acer>; Mon, 28 Aug 2000 15:39:39 +0100 From: "David Chadwick" Organization: University of Salford To: "Steven Legg" Date: Mon, 28 Aug 2000 15:38:48 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Matching Rules for Constructed Syntaxes Reply-to: d.w.chadwick@salford.ac.uk CC: , Message-ID: <39AA8788.22408.4D82210@localhost> Priority: normal In-reply-to: <000301c0109b$d9bf6bb0$b05508cb@osmium.adacel.com.au> X-mailer: Pegasus Mail for Win32 (v3.12c) Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7BIT Steven Being an editor of a current ID on LDAP schema and matching rules for PKIX, I find your approach very appealing. Having to write potentially dozens of new matching rules for certs and CRLs, that all do very similar things, a generic way of describing this has significant benefits from a documentation point of view. I am certainly prepared to use your work in the PKIX schema ID, if there is general approval for it to procede. I also think the work should be part of LDAPExt as we need this type of matching rule to be core to LDAP implementations, and not application specific. In this way many applications can benefit from the technology provided by a central LDAP server. David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From owner-ietf-pkix@imc.org Mon Aug 28 11:09:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12173 for ; Mon, 28 Aug 2000 11:09:03 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA16856; Mon, 28 Aug 2000 08:07:56 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 28 Aug 2000 08:07:51 -0700 Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA16826 for ; Mon, 28 Aug 2000 08:07:50 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 09336512; Mon, 28 Aug 2000 11:08:13 -0400 (EDT) Sender: rsalz@ns.secondary.com Message-ID: <39AA8069.C07ABCF6@caveosystems.com> Date: Mon, 28 Aug 2000 11:08:25 -0400 From: Rich Salz X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Sam Schaen CC: "'ietf-pkix@imc.org'" Subject: Re: RFC 2560 - OCSP - Clarification References: <27FF4FAEA8CDD211B97E00902745CBE201B830EF@seine.valicert.com> <39A173CA.C9EF2071@mitre.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit The text in uppercase is contradicted by the sentence that immediately follows. If good doesn't mean the certificate was issued, then there need not be a CA that issued it. :) > 'The "good" state indicates that THE RESPONDER HAS CURRENT REVOCATION > INFORMATION FROM THE CA THAT ISSUED THE CERTIFICATE AND the certificate has not > been revoked. It > does not indicate whether the certificate was ever issued, is still valid or > any other assertion. From owner-ietf-pkix@imc.org Mon Aug 28 13:03:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15875 for ; Mon, 28 Aug 2000 13:03:07 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA24181; Mon, 28 Aug 2000 10:01:54 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 28 Aug 2000 10:01:47 -0700 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24148 for ; Mon, 28 Aug 2000 10:01:41 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e7SGuCY09794 for ; Mon, 28 Aug 2000 09:56:12 -0700 (PDT) Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id G00HZE03.A0K; Mon, 28 Aug 2000 10:02:02 -0700 Message-ID: <39AA9AEF.DED595C4@netscape.com> Date: Mon, 28 Aug 2000 10:01:35 -0700 From: thayes@netscape.com (Terry Hayes) X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Rich Salz CC: Sam Schaen , "'ietf-pkix@imc.org'" Subject: Re: RFC 2560 - OCSP - Clarification References: <27FF4FAEA8CDD211B97E00902745CBE201B830EF@seine.valicert.com> <39A173CA.C9EF2071@mitre.org> <39AA8069.C07ABCF6@caveosystems.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF9B896A65F40D60462DD6ABD" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a cryptographically signed message in MIME format. --------------msF9B896A65F40D60462DD6ABD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Well, I guess the first sentence should read: "... current revocation information from the CA that APPARENTLY issued the certificate". I believe this is what is intended. Terry Hayes thayes@netscape.com Rich Salz wrote: > The text in uppercase is contradicted by the sentence that immediately > follows. If good doesn't mean the certificate was issued, then there > need not be a CA that issued it. :) > > > 'The "good" state indicates that THE RESPONDER HAS CURRENT REVOCATION > > INFORMATION FROM THE CA THAT ISSUED THE CERTIFICATE AND the certificate has not > > been revoked. It > > does not indicate whether the certificate was ever issued, is still valid or > > any other assertion. --------------msF9B896A65F40D60462DD6ABD Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIIhQYJKoZIhvcNAQcCoIIIdjCCCHICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlgwggMLMIICdKADAgECAgIbDjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA0MDMxODQxMzdaFw0wMDA5MzAxODQxMzda MIGBMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIjAg BgkqhkiG9w0BCQEWE3RoYXllc0BuZXRzY2FwZS5jb20xFDASBgNVBAMTC1RlcnJ5IEhheWVz MRYwFAYKCZImiZPyLGQBARMGdGhheWVzMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCw rDkkK9RaJwlVNF5TcYLpthJh4LHe3h0OCrSR6k6wXyrjd6KEoX2Q6afsu7GNAaOmcPJ6HMQq RPW+6noGzYYa63Q8pgyT7wsZepzgbArJ+2lKiV4ACYAcYcsJHuDbQFcbMsec9vUNofVvnwQv gu2GR2edFbon+4WLdcF/P0z7/wIDAQABo34wfDARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0P AQH/BAQDAgSwMB8GA1UdIwQYMBaAFKI7ZTL39xuJ/FUNBwG8h0ha/ZA9MDYGCCsGAQUFBwEB BCowKDAmBggrBgEFBQcwAYYaaHR0cDovL25zb2NzcC5uZXRzY2FwZS5jb20wDQYJKoZIhvcN AQEEBQADgYEAAiM7sfHY5qngjeKJZToTvAhDa/99M6h4Yi2p8v8/36ioCjfORg1PY8G/AHpp lrTu3JNtYBgzjUDpVAwVxgYyCgJ1GYzFFj27DkD5Saqg2P4baU8UPVf1rnAtXkRbri+tqwoK T8OWU7GWBfYGQI7s2EAetnlfl98JzcT7BQRJLCIwggNFMIICrqADAgECAgEnMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0 aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5j b20wHhcNOTkwNjAzMjIwMDM0WhcNMDEwNjAyMjIwMDM0WjCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA4u9f LHZDiUsaX7Pl+Kpviy+BTWf/vUoPYy7E3IX2nixJJiD/ABfkiIhp3v2DV+CjERkRqtbcvO+z 0hUuVMZufL/ZucNG0wkFhOVTXEjthIWaDjs9Fgdc8LN5q5oQpbzBpNF4TAblZEH8BSVjJuvv DMduVKGMzlRXth+S2rISS40CAwEAAaNpMGcwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUE FjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwEQYJYIZIAYb4QgEBBAQDAgECMB8GA1UdIwQYMBaA FHJJwnM0xlX0C3ZygX539IfnxrIOMA0GCSqGSIb3DQEBBAUAA4GBALpQffwAsv9BtAcIOQwh 9FlJFwjMjtPPDFbxb+gLGmli6waCW2msHYQnBjnJDn41E9B+wI+cWHwDMSyHENViO3DVDrFk gDROWfrGWeZG3k5oCHVA9R2MKdaud63JPWnkQI1El0ZvvnrAWKSxH2qnDylRioENKY6d5A8z C4+NJD3sMYIB9TCCAfECAQEwgZowgZMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQG A1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRkwFwYD VQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBB dXRob3JpdHkCAhsOMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMDAwODI4MTcwMTM3WjAjBgkqhkiG9w0BCQQxFgQUjKgWjh1Ntd4l RGl2dLWT0McwORUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEgYBOjh9TLLZbXOER9vuBL0W1AQYstoX4t/EYZVy2qA5JGM50Lwq2D//k07LExOYKI7Nl quxyO6KIImN4EiuJhaBiHi0m6aCsw/3OwecTnQ1ZTVccM16/Q8WDiWE8jYvr6xIz5ptxxoEQ nrPjICuH5T8VyTR9C7coMZ22jWRFsKHWCw== --------------msF9B896A65F40D60462DD6ABD-- From owner-ietf-pkix@imc.org Mon Aug 28 15:08:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18615 for ; Mon, 28 Aug 2000 15:08:20 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA26264; Mon, 28 Aug 2000 12:06:03 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 28 Aug 2000 12:05:56 -0700 Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA26231 for ; Mon, 28 Aug 2000 12:05:55 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 09397480; Mon, 28 Aug 2000 15:06:33 -0400 (EDT) Sender: rsalz@ns.secondary.com Message-ID: <39AAB846.B6A95B65@caveosystems.com> Date: Mon, 28 Aug 2000 15:06:46 -0400 From: Rich Salz X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ambarish Malpani CC: "'ietf-pkix@imc.org'" Subject: Re: RFC 2560 - OCSP - Clarification References: <27FF4FAEA8CDD211B97E00902745CBE201B830EF@seine.valicert.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit > The "revoked" state indicates that the certificate has been revoked(either > permanantly or temporarily (on hold)). I prefer something like The "revoked" state indicates that the certificate is revoked at the time the responder recevied the query. The revocation may be permanent, or temporary (i.e., on hold), and this state does not imply either condition. > The "unknown" state indicates that the responder does not know, or is > unwilling to tell, whether the certificate is revoked or not. A client may > be able to get a definitive response later, or at another responder. I'd like to add A responder SHOULD use an error response when possible to indicate unwillingness, rather than lack of information. From owner-ietf-pkix@imc.org Mon Aug 28 16:18:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19850 for ; Mon, 28 Aug 2000 16:18:29 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA27560; Mon, 28 Aug 2000 13:17:19 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 28 Aug 2000 13:17:08 -0700 Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27529 for ; Mon, 28 Aug 2000 13:17:08 -0700 (PDT) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Mon, 28 Aug 2000 13:13:27 -0700 Message-ID: <69A40A314934D41190C70050DAD7F99063B59C@MAIL> From: Mathew Butler To: "'Rich Salz'" , Sam Schaen , "'ietf-pkix@imc.org'" Subject: RE: RFC 2560 - OCSP - Clarification Date: Mon, 28 Aug 2000 13:13:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I think that there's a problem with this idea. If the responder doesn't know about the CA, or have the ability to verify the CA's signature on the certificate versus the CRL, the response should be "unknown" rather than "good". "Good" should indicate: "The certificate was apparently issued by a CA that the responder has current revocation information for, and the certificate has not been revoked." Forgive me for not reading the draft as thoroughly as I should have; is there any call for the responder to cryptographically check the certificate at any point during the request? -Mat Butler -----Original Message----- From: Rich Salz [mailto:rsalz@caveosystems.com] Sent: Monday, August 28, 2000 8:08 AM To: Sam Schaen Cc: 'ietf-pkix@imc.org' Subject: Re: RFC 2560 - OCSP - Clarification The text in uppercase is contradicted by the sentence that immediately follows. If good doesn't mean the certificate was issued, then there need not be a CA that issued it. :) > 'The "good" state indicates that THE RESPONDER HAS CURRENT REVOCATION > INFORMATION FROM THE CA THAT ISSUED THE CERTIFICATE AND the certificate has not > been revoked. It > does not indicate whether the certificate was ever issued, is still valid or > any other assertion. From owner-ietf-pkix@imc.org Mon Aug 28 19:47:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22301 for ; Mon, 28 Aug 2000 19:47:19 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA00967; Mon, 28 Aug 2000 16:46:12 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 28 Aug 2000 16:46:05 -0700 Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA00937 for ; Mon, 28 Aug 2000 16:46:04 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id TAA17470 for ; Mon, 28 Aug 2000 19:30:52 -0400 (EDT) Message-Id: <200008282330.TAA17466@roadblock.missi.ncsc.mil> Date: Mon, 28 Aug 2000 19:41:45 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Client-side revocation checking capability To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NVxPCloTUC+pGpfrJkj3CA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Reminds me of the blurb for a new fall TV series: Student: "You mean we should go online [to check the facts on a murder]?" Reporter: "No, I mean you should put on your socks and shoes and walk down to the police station." A CA doesn't have to resort to using DNS to validate the legitimacy of requests for certificates containing DNS names. In fact, there is no point in doing so - DNS maps names to IP addresses, certificates map names to public keys. Finding a DNS record, hijacked or not, doesn't give a CA any assurance that a public key belongs to the owner of the name. Certs-by-email are cute toys for users to play with, but any merchant using such a cert shouldn't get an "XYZ seal of approval" from any legitimate XYZ auditing organization. The value added by a CA who checks with D&B and WIPO before issuing a server cert is nearly orthogonal to the value added by secure DNS (at least until DNS administrators publish their CPSs). And even if the CA and the DNS used identical identity proofing procedures, independently-issued name-to-key and name-to-IP certificates provide additional assurance. Maybe overkill for some applications, but certainly not superfluous and redundant. Dave > From: Lynn.Wheeler@firstdata.com > Date: Wed, 16 Aug 2000 10:13:33 -0700 > > The side observation is there is a requirement for such a trusted DNS > infrastructure ... just to improve the integrity of existing server-side SSL > certificates (i.e. problem with hijacking host name and then obtaining a SSL > certificate since the certification authority has to resort to using the DNS > infrastructure as the authoritative entity for validating DNS information). But > addressing that requirement then also makes the need for such servier-side SSL > certificates superfulous and redundant. From owner-ietf-pkix@imc.org Mon Aug 28 23:07:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25991 for ; Mon, 28 Aug 2000 23:07:30 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA18389; Mon, 28 Aug 2000 20:06:21 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 28 Aug 2000 20:05:43 -0700 Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA18250 for ; Mon, 28 Aug 2000 20:05:39 -0700 (PDT) Received: (qmail 7564 invoked from network); 29 Aug 2000 03:05:47 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 29 Aug 2000 03:05:47 -0000 Reply-To: From: "Steven Legg" To: , , Subject: RE: Matching Rules for Constructed Syntaxes Date: Tue, 29 Aug 2000 14:05:41 +1000 Message-ID: <000a01c0116e$65fa9690$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Following some private email discussions with Tom Gindin I've decided on some changes to the way asn1Match, componentMatch and componentFilterMatch compare strings. The asn1Match rule isn't exactly a shorthand way of writing an "and" component filter because it doesn't compare character strings like any of the existing string matching rules. It compares two strings letter for letter, so letter case and all spaces are significant, but it also returns false if two compared DirectoryStrings use different alternatives in the DirectoryString CHOICE (which will only be visible in X.500). I think asn1Match will be more useful if it behaves just like caseIgnoreMatch when it is matching string type components. The assumed behaviour could be some other string matching rule, like caseExactMatch, or a purposely defined new string matching rule. In the absence of any request for an alternative I'll stick with caseIgnoreMatch. This change would make asn1Match somewhat different from its current implementation in the Adacel directory so I propose instead to define a new matching rule, which I'll call allComponentsMatch (unless someone has a better idea), with a new OID. The DirectoryString type is actually a CHOICE type (i.e. a constructed syntax) but I was deliberately treating it like a primitive string type in the examples of componentMatch and componentFilterMatch. Since it is fairly common practice to replace a specific ASN.1 string type that turns out to be too restrictive (e.g. PrintableString) with a CHOICE between the previous string type and a more general string type (e.g. UTF8String) I propose generalizing the special treatment for DirectoryString to any CHOICE of string types. Conceptually a string "component" has an ASN.1 type which is one of the primitive string types (e.g. PrintableString, IA5String) or a CHOICE of those string types (e.g. DirectoryString, PKCS9String). Nested CHOICEs would be permitted also. Regardless of the string type, I only intend that the string encoding of ComponentAssertion will use UTF8. The CHOICE construct would not normally be evident in the string encoding, though it would still be relevant to the BER encoding. To aid in the conversion between string encoding and BER encoding I'll provide some simple rules for deciding which alternative in a CHOICE of strings to assume, and a syntax for overriding the default rules to force a particular alternative. Regards, Steven From owner-ietf-pkix@imc.org Tue Aug 29 11:28:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22014 for ; Tue, 29 Aug 2000 11:28:36 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA13021; Tue, 29 Aug 2000 08:27:11 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 29 Aug 2000 08:26:57 -0700 Received: from smtp4.libero.it (smtp4.libero.it [193.70.192.54]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12935 for ; Tue, 29 Aug 2000 08:26:56 -0700 (PDT) Received: from tin.it (151.25.244.163) by smtp4.libero.it; 29 Aug 2000 17:27:19 +0200 Sender: nello@ns.secondary.com Message-ID: <39ABD661.1451F2A6@tin.it> Date: Tue, 29 Aug 2000 17:27:30 +0200 From: Sebastiano Di Paola X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: A question about X.509 Extensions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit I have a question about X.509 Extension. I would like to know how they are codified.. What I mean is: Extensions are defined as: Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING } What I would like to know is: if I would like to put in a X.509 Cert the Extension Authority Key Identifier defined as: AuthorityKeyIdentifier ::= SEQUENCE { keyIdentifier [0] KeyIdentifier OPTIONAL, authorityCertIssuer [1] GeneralNames OPTIONAL, authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } KeyIdentifier ::= OCTET STRING If I would like to include all of the fileds (keyIdentifier,authorityCertIssuer ,authorityCertSerialNumber) what I have to do to put the Extension in the llist EXTENSIONS which has OctetString as extn value? I mean do I have to Der Encode the structure AuthorityKeyIdentifier and then create an OctetString with the encoded data or what? The same question can be made for CrlNumber Extension where I have an int which should be put into an octet string. I hope you can help me. Kind Regards Marco From owner-ietf-pkix@imc.org Tue Aug 29 12:39:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25240 for ; Tue, 29 Aug 2000 12:39:42 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA17789; Tue, 29 Aug 2000 09:38:26 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 29 Aug 2000 09:38:21 -0700 Received: from nxs_vyr_dns.sie.cl (IDENT:root@[206.48.156.90]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17759 for ; Tue, 29 Aug 2000 09:38:15 -0700 (PDT) Received: from JPEREZ ([206.48.156.91]) by nxs_vyr_dns.sie.cl (8.9.3/8.9.3) with SMTP id IAA07045 for ; Tue, 29 Aug 2000 08:44:08 -0400 Reply-To: From: =?iso-8859-1?Q?Juan_Carlos_P=E9rez_Aguayo?= To: "Ietf-Pkix" Subject: How to define a new Distinguished Name (DN) attribute ? Date: Tue, 29 Aug 2000 12:37:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Can I define a new DN attribute, for using in the Subject or Issuer of a certificate? By example, can I say this in the DN?: "O= My company, OU=My Dept. , XX=..., C=.." Can I say XX=.... ? Here XX mean my own attribute... I understand that the attribute names (as O , OU, DN ..) have OID assigned in a standarized fashion (X.208 ?), but I don`t know if I can assign my own OID for my private attribute (i.e XX). The DN attribute names are ONLY thoses standards(O, OU, C, ...) ? If I could register my own attribute name and OID, the browsers (o client-certificate validators) could validate those too ? Thanks Juan Carlos From owner-ietf-pkix@imc.org Wed Aug 30 00:01:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07669 for ; Wed, 30 Aug 2000 00:01:47 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA14469; Tue, 29 Aug 2000 20:57:09 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 29 Aug 2000 20:56:12 -0700 Received: from mail02-ewr.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA14353 for ; Tue, 29 Aug 2000 20:56:10 -0700 (PDT) From: Lynn.Wheeler@firstdata.com Received: from mailgw.firstdata.com ([204.48.27.156]) by mail02-ewr.pilot.net with ESMTP id XAA11289; Tue, 29 Aug 2000 23:57:10 -0400 (EDT) Received: from lnsunr02.firstdata.com (localhost [127.0.0.1]) by mailgw.firstdata.com with SMTP id XAA12612; Tue, 29 Aug 2000 23:57:08 -0400 (EDT) Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525694B.00152EF1 ; Tue, 29 Aug 2000 23:51:22 -0400 X-Lotus-FromDomain: FDC To: "David P. Kemp" cc: ietf-pkix@imc.org Message-ID: <8525694B.00152DF9.00@lnsunr02.firstdata.com> Date: Tue, 29 Aug 2000 20:52:43 -0700 Subject: Re: Client-side revocation checking capability Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe a relying party presumably executes some protocol initiation, signing validation, certificate validation, etc. after all that is done, the relying party can compare some "bound" information in the certificates with something that the relying party may be assuming and/or expects. If the relying party is expecting a specific business name ... they could check if the business name in the certificate matches the business name they are expecting. They might also have some expectation as to the due dilligence that the certification authority exercised in validating that information (for business names ... possibly checking with D&B). Now looking at possibly a trivial occurance of relying party checking ... maybe only a trivial 99.99999999999999% of all relying party "checking" currently going on ... it would appear that the most common occurance of a relying party checking something is a SSL relying party checking a domain name. 99.999999999999% of all such checking might not seem like a valid situation to consider. Now if the most common client-side validation of certificate information (only a trivial 99.9999999999999% of all such checks) involves domain name checking ... then clients might expect that certification authorities would be checking some authority that is involved in registering domain names. Now, it is possible that certification authorities might check with their local police station with regard to who has registered an internet domain name ... or they could check with D&B ... or they could check with all the agencies in the world which are explicitly not part of registering domain names. Frequently I've heard reference to one of the reasons for certificates in the SSL protocol is because of weaknesses in the domain name system ... which can be corrected by SSL domain certificates issued by certification authorities ... who may have check with the domain name registration authority as to the validity of the domain name (or on the other hand could have just checked with their local police station as to who owns a particular domain name). A minor issue if the domain name system is weak ... then it also is weak as an authority of certification authorities to check the information that they supposedly need to be correct (but which the domain name infrastructure can't be trusted to verify as correct????). So some of the proposals are to add public key registration to the domain name process. That makes it harder to hijack domain names and leads to a more trusted domain name system. Given a trusted domain name system with public keys, then the domain name system could return the public key (associated with a domain name) at the same time it returned the IP-address. However, if a trusted domain name system returned a public key as part of the domain name process, then having an SSL domain name certificate with a public key would seem to be superfulous and redundants (at least as far as the trivial SSL case under consideration). SSL certificates are somewhat a catch-22 ... some believe they exist because of untrusted DNS ... however the SSL certificate certification authorities would appear to be dependant on an untrusted domain name system as the authority for the domain name information that they place in SSL certificates ... creating a trusted DNS with the addition of public keys ... allows the real-time DNS domain name infrastructure to the real time authority of public keys for an SSL protocol as part of the standard domain name process. In this particular scenerio, SSL certificates would appear to be superfulous and redundant (aka it isn't necessary to have a certification authority manufactor a stale certificate with stale bound information ... when a trusted DNS is providing real-time information). That doesn't say that all certificates with public keys are redundant and superfulous ... just the apparent most common scenerio ... at least in terms of relying party/clients validating information ... possibly only a trivial 99.99999999999% of the cases (the SSL scenario). If the relying party isn't doing something on the internet and requires little or no IP services (including DNS) ... but still needs some authentication process, then certificates could address the opportunity. One could do SSL with an ip-address ... rather than a domain name ... and bypass the (real time) domain name system alltogether and rely on stale information in manufactored certificates. Hopefully the certification authority would be checking some internet ip-address authority (rather than the local police station). "David P. Kemp" on 08/28/2000 04:41:45 PM Please respond to "David P. Kemp" To: ietf-pkix@imc.org cc: (bcc: Lynn Wheeler/CA/FDMS/FDC) Subject: Re: Client-side revocation checking capability Reminds me of the blurb for a new fall TV series: Student: "You mean we should go online [to check the facts on a murder]?" Reporter: "No, I mean you should put on your socks and shoes and walk down to the police station." A CA doesn't have to resort to using DNS to validate the legitimacy of requests for certificates containing DNS names. In fact, there is no point in doing so - DNS maps names to IP addresses, certificates map names to public keys. Finding a DNS record, hijacked or not, doesn't give a CA any assurance that a public key belongs to the owner of the name. Certs-by-email are cute toys for users to play with, but any merchant using such a cert shouldn't get an "XYZ seal of approval" from any legitimate XYZ auditing organization. The value added by a CA who checks with D&B and WIPO before issuing a server cert is nearly orthogonal to the value added by secure DNS (at least until DNS administrators publish their CPSs). And even if the CA and the DNS used identical identity proofing procedures, independently-issued name-to-key and name-to-IP certificates provide additional assurance. Maybe overkill for some applications, but certainly not superfluous and redundant. Dave From owner-ietf-pkix@imc.org Wed Aug 30 01:49:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13590 for ; Wed, 30 Aug 2000 01:49:12 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA22849; Tue, 29 Aug 2000 22:48:00 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 29 Aug 2000 22:47:55 -0700 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA22806 for ; Tue, 29 Aug 2000 22:47:54 -0700 (PDT) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G0300D01C5CXA@ext-mail.valicert.com> for ietf-pkix@imc.org; Tue, 29 Aug 2000 22:48:48 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G0300DLDC5CIB@ext-mail.valicert.com>; Tue, 29 Aug 2000 22:48:48 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 22:38:18 -0700 Content-return: allowed Date: Tue, 29 Aug 2000 22:38:08 -0700 From: Ambarish Malpani Subject: RE: A question about X.509 Extensions To: "'Sebastiano Di Paola'" , ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE201B831A1@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hi Sebastiano, your analysis is correct (if I understood it correctly). To verify that we are both thinking the same thing, you could just look at the bytes in a standard certificate that has the extension you want (or some other extension). Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Sebastiano Di Paola [mailto:zio.moe@tin.it] > Sent: Tuesday, August 29, 2000 8:28 AM > To: ietf-pkix@imc.org > Subject: A question about X.509 Extensions > > > I have a question about X.509 Extension. > I would like to know how they are codified.. > What I mean is: > Extensions are defined as: > > Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension > > Extension ::= SEQUENCE { > extnID OBJECT IDENTIFIER, > critical BOOLEAN DEFAULT FALSE, > extnValue OCTET STRING } > > What I would like to know is: if I would like to put in a > X.509 Cert the > > Extension Authority Key > Identifier defined as: > > AuthorityKeyIdentifier ::= SEQUENCE { > keyIdentifier [0] KeyIdentifier OPTIONAL, > authorityCertIssuer [1] GeneralNames OPTIONAL, > authorityCertSerialNumber [2] CertificateSerialNumber > OPTIONAL } > > KeyIdentifier ::= OCTET STRING > > If I would like to include all of the fileds > (keyIdentifier,authorityCertIssuer ,authorityCertSerialNumber) > what I have to do to put the Extension in the llist > EXTENSIONS which has > > OctetString as extn value? > I mean do I have to Der Encode the structure > AuthorityKeyIdentifier and > then create an OctetString with the encoded data or what? > The same question can be made for CrlNumber Extension where I have an > int which > should be put into an octet string. > I hope you can help me. > Kind Regards > Marco > From owner-ietf-pkix@imc.org Wed Aug 30 04:21:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22154 for ; Wed, 30 Aug 2000 04:21:19 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA03645; Wed, 30 Aug 2000 01:20:09 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 30 Aug 2000 01:20:03 -0700 Received: from sendflowersamerica.com ([206.168.43.194]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA01618; Wed, 30 Aug 2000 01:00:01 -0700 (PDT) From: sfaquestions@sendflowersamerica.com Subject: FlowerFunds - Fund Raising Program Date: Wed, 30 Aug 2000 01:32:17 Message-Id: <620.108063.29555@sendflowersamerica.com> Precedence: bulk To: undisclosed-recipients:; List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe SendFlowersAmerica is proud to introduce FlowerFunds-- This unique new concept will provide an income flow for your organization for years to come. Your organization is invited to explore the possibilities of participating in FlowerFunds. $FlowerFunds is an individualized fund raising program for non-profit organizations and schools. $FlowerFunds are cash rebates that are paid to your organization each and every time an order is placed by your members and supporters. $The best part is that it costs your organization nothing to participate!! How it works: 1. When your members and supporters order flowers or gifts through sendflowersamerica they determine the price they want to pay; be it $30, $40, $50 or $1000. Since your members and supporters determine the price, they all can participate in this program. 2. Your organization receives 20% of the purchase price of the order. Say a husband buys his wife a $50 bouquet. Your organization will receive a $10 cash rebate. Nice. This program never ends. Each and every time there is an order placed by your memebers and supporters, your organization will receive the 20% cash rebate. That's a lot of FlowerFunds, and your organization stands to benefit from a findraiser unlike any other fundraiser. For more information call 1 800 SEND 123 or http://www.sendflowersamerica.com Imagine earning money for your organization by making someone smile :-) From owner-ietf-pkix@imc.org Wed Aug 30 12:00:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03143 for ; Wed, 30 Aug 2000 12:00:08 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA09718; Wed, 30 Aug 2000 08:58:44 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 30 Aug 2000 08:58:22 -0700 Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09668 for ; Wed, 30 Aug 2000 08:58:20 -0700 (PDT) Received: from [195.99.45.237] (helo=vaio) by gadolinium.btinternet.com with smtp (Exim 3.03 #83) id 13UAGn-0006pe-00 for ietf-pkix@imc.org; Wed, 30 Aug 2000 16:59:21 +0100 Message-ID: <003b01c0129b$b379aae0$f13863c3@vaio> Reply-To: "Liaquat Khan" From: "Liaquat Khan" To: References: <69A40A314934D41190C70050DAD7F99063B59C@MAIL> Subject: Re: RFC 2560 - OCSP - Clarification Date: Wed, 30 Aug 2000 17:01:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit The problem is linked to the fact that OCSP generally uses CRLs as the base information (although of course this doesn't have to be the case). And CRLs basically contain identifiers for those certificates that have been revoked (or suspended). Therefore, if a particular certificates serial number is not on a CRL, it maybe because it is still valid or maybe because it was never issued in the first place. Note that the OCSP standard makes a reference that extensions should be used for providing additional information. Regards, Liaquat Khan Technical Manager Global Trust Authority ----- Original Message ----- From: Mathew Butler To: 'Rich Salz' ; Sam Schaen ; Sent: Monday, August 28, 2000 9:13 PM Subject: RE: RFC 2560 - OCSP - Clarification > I think that there's a problem with this idea. If the responder doesn't > know about the CA, or have the ability to verify the CA's signature on the > certificate versus the CRL, the response should be "unknown" rather than > "good". > > "Good" should indicate: "The certificate was apparently issued by a CA that > the responder has current revocation information for, and the certificate > has not been revoked." > > Forgive me for not reading the draft as thoroughly as I should have; is > there any call for the responder to cryptographically check the certificate > at any point during the request? > > -Mat Butler > > -----Original Message----- > From: Rich Salz [mailto:rsalz@caveosystems.com] > Sent: Monday, August 28, 2000 8:08 AM > To: Sam Schaen > Cc: 'ietf-pkix@imc.org' > Subject: Re: RFC 2560 - OCSP - Clarification > > > The text in uppercase is contradicted by the sentence that immediately > follows. If good doesn't mean the certificate was issued, then there > need not be a CA that issued it. :) > > > > 'The "good" state indicates that THE RESPONDER HAS CURRENT REVOCATION > > INFORMATION FROM THE CA THAT ISSUED THE CERTIFICATE AND the certificate > has not > > been revoked. It > > does not indicate whether the certificate was ever issued, is still valid > or > > any other assertion. > From owner-ietf-pkix@imc.org Wed Aug 30 16:56:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09032 for ; Wed, 30 Aug 2000 16:56:04 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA20989; Wed, 30 Aug 2000 13:54:49 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 30 Aug 2000 13:54:40 -0700 Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20951 for ; Wed, 30 Aug 2000 13:54:39 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA12488; Wed, 30 Aug 2000 13:55:55 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 13:54:21 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4F93EE6@vhqpostal.verisign.com> From: Michael Myers To: Liaquat Khan , ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification Date: Wed, 30 Aug 2000 13:54:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Liaquat, Thanks for taking a careful look at 2560 regarding CRLs. This thread will feed productively into 2560bis. But I do need to point out that OCSP does not, nor was ever intended, to require the use of CRLs. In fact, here are a few references from 2560 as currently written: Abstract "This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs." ^^^^^^^^^^^^^^^^^^^^^^ 2. Protocol Overview "OCSP may be used to satisfy some of the operational requirements of providing more timely revocation information than is possible with CRLs . . . ." ^^^^^^^^^^^^^^^^^^^^^^^^^^ Now, that said, 2560 does recognize that CRLs are a useful input to OCSP and so we made certain to accomodate that data source in the event that periodically produced CRLs were the ONLY means by which an OCSP service could be offered. We enabled the use of CRL extensions to accomodate environments where this feature was useful. But OCSP is and was primarly intended to address immediate timeliness, a feature that is inherently beyond the scope of periodically produced CRLs. 2560bis will clarify this intent. Mike > -----Original Message----- > From: Liaquat Khan [mailto:liaquat.khan@gta.multicert.org] > Sent: Wednesday, August 30, 2000 9:02 AM > To: ietf-pkix@imc.org > Subject: Re: RFC 2560 - OCSP - Clarification > > > The problem is linked to the fact that OCSP generally uses > CRLs as the base > information (although of course this doesn't have to be the > case). And CRLs > basically contain identifiers for those certificates that > have been revoked > (or suspended). Therefore, if a particular certificates > serial number is > not on a CRL, it maybe because it is still valid or maybe > because it was > never issued in the first place. > > Note that the OCSP standard makes a reference that extensions > should be used > for providing additional information. > > Regards, > Liaquat Khan > Technical Manager > Global Trust Authority > > > > ----- Original Message ----- > From: Mathew Butler > To: 'Rich Salz' ; Sam Schaen > ; > > Sent: Monday, August 28, 2000 9:13 PM > Subject: RE: RFC 2560 - OCSP - Clarification > > > > I think that there's a problem with this idea. If the > responder doesn't > > know about the CA, or have the ability to verify the CA's > signature on the > > certificate versus the CRL, the response should be > "unknown" rather than > > "good". > > > > "Good" should indicate: "The certificate was apparently > issued by a CA > that > > the responder has current revocation information for, and > the certificate > > has not been revoked." > > > > Forgive me for not reading the draft as thoroughly as I > should have; is > > there any call for the responder to cryptographically check the > certificate > > at any point during the request? > > > > -Mat Butler > > > > -----Original Message----- > > From: Rich Salz [mailto:rsalz@caveosystems.com] > > Sent: Monday, August 28, 2000 8:08 AM > > To: Sam Schaen > > Cc: 'ietf-pkix@imc.org' > > Subject: Re: RFC 2560 - OCSP - Clarification > > > > > > The text in uppercase is contradicted by the sentence that > immediately > > follows. If good doesn't mean the certificate was issued, > then there > > need not be a CA that issued it. :) > > > > > > > 'The "good" state indicates that THE RESPONDER HAS > CURRENT REVOCATION > > > INFORMATION FROM THE CA THAT ISSUED THE CERTIFICATE AND > the certificate > > has not > > > been revoked. It > > > does not indicate whether the certificate was ever > issued, is still > valid > > or > > > any other assertion. > > > From owner-ietf-pkix@imc.org Wed Aug 30 19:46:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11075 for ; Wed, 30 Aug 2000 19:46:40 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA23999; Wed, 30 Aug 2000 16:45:02 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 30 Aug 2000 16:43:19 -0700 Received: from Newman.GSC.GTE.Com (SYSTEM@NS0.GDGSC.Com [192.160.62.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA23931 for ; Wed, 30 Aug 2000 16:43:17 -0700 (PDT) Received: from gscex01.gsc.gte.com ("port 2437"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #38015) with SMTP id <01JTLCRRX9SG003QSB@Newman.GSC.GTE.Com> for ietf-pkix@imc.org; Wed, 30 Aug 2000 19:44:10 -0400 (EDT) Received: from 127.0.0.1 by gscex01.gsc.gte.com (InterScan E-Mail VirusWall NT) ; Wed, 30 Aug 2000 19:44:09 -0400 (Eastern Daylight Time) Received: by GSCEX01.gsc.gte.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 19:44:09 -0400 Date: Wed, 30 Aug 2000 19:44:08 -0400 From: "Heimberg, Jim" Subject: RE: Matching Rules for Constructed Syntaxes To: "'steven.legg@adacel.com.au'" , ietf-ldapext@netscape.com, ietf-pkix@imc.org, osidirectory@az05.bull.com Message-id: <2575327B6755D211A0E100805F9FF9540508062D@ndhmex02.ndhm.gsc.gte.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="ISO-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Please change my address to jimhei@cablespeed.com. Thanks. -----Original Message----- From: Steven Legg [mailto:steven.legg@adacel.com.au] Sent: Tuesday, August 29, 2000 12:06 AM To: ietf-ldapext@netscape.com; ietf-pkix@imc.org; osidirectory@az05.bull.com Subject: RE: Matching Rules for Constructed Syntaxes Following some private email discussions with Tom Gindin I've decided on some changes to the way asn1Match, componentMatch and componentFilterMatch compare strings. The asn1Match rule isn't exactly a shorthand way of writing an "and" component filter because it doesn't compare character strings like any of the existing string matching rules. It compares two strings letter for letter, so letter case and all spaces are significant, but it also returns false if two compared DirectoryStrings use different alternatives in the DirectoryString CHOICE (which will only be visible in X.500). I think asn1Match will be more useful if it behaves just like caseIgnoreMatch when it is matching string type components. The assumed behaviour could be some other string matching rule, like caseExactMatch, or a purposely defined new string matching rule. In the absence of any request for an alternative I'll stick with caseIgnoreMatch. This change would make asn1Match somewhat different from its current implementation in the Adacel directory so I propose instead to define a new matching rule, which I'll call allComponentsMatch (unless someone has a better idea), with a new OID. The DirectoryString type is actually a CHOICE type (i.e. a constructed syntax) but I was deliberately treating it like a primitive string type in the examples of componentMatch and componentFilterMatch. Since it is fairly common practice to replace a specific ASN.1 string type that turns out to be too restrictive (e.g. PrintableString) with a CHOICE between the previous string type and a more general string type (e.g. UTF8String) I propose generalizing the special treatment for DirectoryString to any CHOICE of string types. Conceptually a string "component" has an ASN.1 type which is one of the primitive string types (e.g. PrintableString, IA5String) or a CHOICE of those string types (e.g. DirectoryString, PKCS9String). Nested CHOICEs would be permitted also. Regardless of the string type, I only intend that the string encoding of ComponentAssertion will use UTF8. The CHOICE construct would not normally be evident in the string encoding, though it would still be relevant to the BER encoding. To aid in the conversion between string encoding and BER encoding I'll provide some simple rules for deciding which alternative in a CHOICE of strings to assume, and a syntax for overriding the default rules to force a particular alternative. Regards, Steven From owner-ietf-pkix@imc.org Thu Aug 31 04:25:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01615 for ; Thu, 31 Aug 2000 04:25:43 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA29960; Thu, 31 Aug 2000 01:24:21 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 31 Aug 2000 01:24:07 -0700 Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA29919 for ; Thu, 31 Aug 2000 01:24:06 -0700 (PDT) Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A66673301A6; Thu, 31 Aug 2000 10:25:10 +0200 Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0beta1 14/January/2000); Thu, 31 Aug 2000 10:24:10 +0100 From: "Karl Scheibelhofer" To: "Michael Myers" , "IETF PKIX Mailing List" Subject: RE: RFC 2560 - OCSP - Clarification Date: Thu, 31 Aug 2000 10:24:10 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4F93EE6@vhqpostal.verisign.com> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Michael, > Abstract > "This document specifies a protocol useful in determining the > current status > of a digital certificate without requiring CRLs." > ^^^^^^^^^^^^^^^^^^^^^^ the current status of a certificate is very often not so important. when i verify a signature that was created using a specific certificate, i want to know, if the certificate was vaild, when the signature was created. to detemine the time the signature was created, one would ideally use timestamps. using timestamps, it is possible to determine the signature creation time to be in an intervall [t1,t2]. here t1 and t2 are the times of two timestamp (taking time base errors into consideration). what i would like to see in OCSP is a request with the following meaning: "what was the state of certificate XYZ in the time interval [t1,t2]?" the answers could be: 1) the state of certificate XYZ was A (e.g. valid, suspended, revoked,...) throughout the time intervall [t1,t2] 3) certificate XYZ changed its state from state A (e.g. valid) to state B (e.g. suspended) at tx, where t1 <= tx <= t2 if i get the first answer with 'valid', i can definitely say: "the signature it was used for is valid". moreover, this request-response supports any history model for certificate. by now OCSP assumes that a certificate can never become valid again once it became invalid. of course, implementing this based on CRLs will be hard, but if the server has access to the history of the certificates, it should not be a big deal. what do you and others think of this requirement for future OCSP regards Karl Scheibelhofer -- Karl Scheibelhofer, Institute for Applied Information Processing and Communications (IAIK) at Technical University of Graz, Austria, http://www.iaik.at Phone: (+43) (316) 873-5540 From owner-ietf-pkix@imc.org Thu Aug 31 08:27:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04816 for ; Thu, 31 Aug 2000 08:27:47 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA17417; Thu, 31 Aug 2000 05:26:25 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 31 Aug 2000 05:26:14 -0700 Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA17365 for ; Thu, 31 Aug 2000 05:26:12 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA08335; Thu, 31 Aug 2000 14:26:44 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 31 Aug 2000 14:26:44 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id OAA13858; Thu, 31 Aug 2000 14:26:43 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA12849; Thu, 31 Aug 2000 14:26:42 +0200 (MET DST) Date: Thu, 31 Aug 2000 14:26:42 +0200 (MET DST) Message-Id: <200008311226.OAA12849@emeriau.edelweb.fr> To: MMyers@verisign.com, ietf-pkix@imc.org, Karl.Scheibelhofer@iaik.at Subject: RE: RFC 2560 - OCSP - Clarification Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > > the current status of a certificate is very often not so important. when i > verify a signature that was created using a specific certificate, i want to > know, if the certificate was vaild, when the signature was created. to > detemine the time the signature was created, one would ideally use > timestamps. using timestamps, it is possible to determine the signature > creation time to be in an intervall [t1,t2]. here t1 and t2 are the times of > two timestamp (taking time base errors into consideration). > what i would like to see in OCSP is a request with the following meaning: > "what was the state of certificate XYZ in the time interval [t1,t2]?" I do not think that you really want to ask this question, see below. > > the answers could be: > 1) the state of certificate XYZ was A (e.g. valid, suspended, revoked,...) > throughout the time intervall [t1,t2] > 3) certificate XYZ changed its state from state A (e.g. valid) to state B > (e.g. suspended) at tx, where t1 <= tx <= t2 > > if i get the first answer with 'valid', i can definitely say: "the signature > it was used for is valid". > moreover, this request-response supports any history model for certificate. > by now OCSP assumes that a certificate can never become valid again once it > became invalid. Hm, If a certificate was 'invalid' (suspended) and if it becomes valid later, then why would you want to get a 'suspended' status? If it becomes definetely revoked, you get a bad answer, if the the current status is still 'pending', you get that. And for those cases you get a date, so you can compare. It is assumed that either by using a cut-off date or by external knowledge you know that for which time frame you get an answer. If you want to have more detailed information about the history, you can also require that the signer, a cosigner, a notary, or whoever you want, produce an OCSP response near the moment of the signature and add this to the document, or you other protocols to enable validity checking of the document. I am not talking about the effects of a CA key compromise that might allow you to create 'good' responses for a non-existing cert, and then you estimate to be able to fake one in the future. > of course, implementing this based on CRLs will be hard, but if the server > has access to the history of the certificates, it should not be a big deal. > > what do you and others think of this requirement for future OCSP Some general thoughts: So far, OCSP without extensions has been made in such a way that you can create a conforming implementation if you have a repository of CRLs. As far as I remember all requests to give different answers are handled by the magic 'do it by an extension'. OCSP adds an archive-cut off extension for example, this seems to me a simple thing to support, knowing the the history of the CRLs that you have isn't that difficult. PS From owner-ietf-pkix@imc.org Thu Aug 31 09:27:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05731 for ; Thu, 31 Aug 2000 09:27:33 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA20102; Thu, 31 Aug 2000 06:26:12 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 31 Aug 2000 06:26:09 -0700 Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA20072 for ; Thu, 31 Aug 2000 06:26:07 -0700 (PDT) Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id AD3056601E4; Thu, 31 Aug 2000 15:27:12 +0200 Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0beta1 14/January/2000); Thu, 31 Aug 2000 15:26:11 +0100 From: "Karl Scheibelhofer" To: "Peter Sylvester" , , Subject: RE: RFC 2560 - OCSP - Clarification Date: Thu, 31 Aug 2000 15:26:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <200008311226.OAA12849@emeriau.edelweb.fr> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr] > Sent: Thursday, August 31, 2000 2:27 PM > To: MMyers@verisign.com; ietf-pkix@imc.org; Karl.Scheibelhofer@iaik.at > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > the current status of a certificate is very often not so > important. when i > > verify a signature that was created using a specific > certificate, i want to > > know, if the certificate was vaild, when the signature was created. to > > detemine the time the signature was created, one would ideally use > > timestamps. using timestamps, it is possible to determine the signature > > creation time to be in an intervall [t1,t2]. here t1 and t2 are > the times of > > two timestamp (taking time base errors into consideration). > > what i would like to see in OCSP is a request with the > following meaning: > > "what was the state of certificate XYZ in the time interval [t1,t2]?" > > I do not think that you really want to ask this question, see below. i do not simply want, in fact i must(!) have a answer to this question to decide whether the signature is valid. for me a certificate status service it is the most obvious place to get the answer for this question. > > the answers could be: > > 1) the state of certificate XYZ was A (e.g. valid, suspended, > revoked,...) > > throughout the time intervall [t1,t2] > > 3) certificate XYZ changed its state from state A (e.g. valid) > to state B > > (e.g. suspended) at tx, where t1 <= tx <= t2 > > > > if i get the first answer with 'valid', i can definitely say: > "the signature > > it was used for is valid". > > moreover, this request-response supports any history model for > certificate. > > by now OCSP assumes that a certificate can never become valid > again once it > > became invalid. > Hm, > > If a certificate was 'invalid' (suspended) and if it becomes > valid later, then > why would you want to get a 'suspended' status? simply to temporarily take away the rigths that a valid certificate brings with for a entity. consider a employee gets suspended for any reason, the company may not want to revoke the certificate before the reason for this suspension have been verified. and if the company finds out that the reason is unjustified, it may want to make the certificate valid again. during the period the employee is suspended, the company may not want him do any business. > If it becomes definetely revoked, you get a bad answer, > if the the current status is still 'pending', you get that. > And for those cases you get a date, so you can compare. > > It is assumed that either by using a cut-off date or by external knowledge > you know that for which time frame you get an answer. collecting facts from serveral sources to get an answer is what i want to avoid. i would like to have a single point where is get a definitive answer to the question stated above. by now i have to do serveral parts of this processing at the client side. i think the server side would be the better place for this. > If you want to have more detailed information about the history, you can > also require that the signer, a cosigner, a notary, or whoever you want, > produce an OCSP response near the moment of the signature and add > this to the document, or you other protocols to enable validity checking > of the document. if you sign a lot of documents and always attach all necessary verification data, you produce a lot of redundant information. this can be avoided and i think this should be avoided. nevertheless it works. > I am not talking about the effects of a CA key compromise that might allow > you to create 'good' responses for a non-existing cert, and then > you estimate > to be able to fake one in the future. i also do not consider a CA key compromise here. > > of course, implementing this based on CRLs will be hard, but if > the server > > has access to the history of the certificates, it should not be > a big deal. > > > > what do you and others think of this requirement for future OCSP > Some general thoughts: > > So far, OCSP without extensions has been made in such a way that you can > create a conforming implementation if you have a repository of CRLs. yes i know about this requirement for supporting CRLs. but this is a implementation issue. for me as a developer of a signature/verification terminal software my stated question is the one that i need an answer for. > As far as I remember all requests to give different answers are handled by > the magic 'do it by an extension'. OCSP adds an archive-cut off extension > for example, this seems to me a simple thing to support, knowing the > the history of the CRLs that you have isn't that difficult. just getting my idea in there in any non-standard extension is not a very disirable solution. because if i am the only one supporting it, it is not better than any ad-hoc protocol. i posted my idea here to hear the opinion of other people that use OCSP. regards Karl Scheibelhofer -- Karl Scheibelhofer, Institute for Applied Information Processing and Communications (IAIK) at Technical University of Graz, Austria, http://www.iaik.at Phone: (+43) (316) 873-5540 From owner-ietf-pkix@imc.org Thu Aug 31 10:29:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06609 for ; Thu, 31 Aug 2000 10:29:00 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA24481; Thu, 31 Aug 2000 07:27:41 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 31 Aug 2000 07:27:34 -0700 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24448 for ; Thu, 31 Aug 2000 07:27:33 -0700 (PDT) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G0500K01UVMDA@ext-mail.valicert.com> for ietf-pkix@imc.org; Thu, 31 Aug 2000 07:28:34 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G0500JJMUVLOZ@ext-mail.valicert.com>; Thu, 31 Aug 2000 07:28:34 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 07:17:59 -0700 Content-return: allowed Date: Thu, 31 Aug 2000 07:17:52 -0700 From: Ambarish Malpani Subject: RE: RFC 2560 - OCSP - Clarification To: "'Karl Scheibelhofer'" , Peter Sylvester , MMyers@verisign.com, ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE201B831B9@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hi Karl, The Archive-Cutoff extension is one that is defined in the OCSP spec - it would not be a non-standard extension just made up by you. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Karl Scheibelhofer [mailto:Karl.Scheibelhofer@iaik.at] > Sent: Thursday, August 31, 2000 6:26 AM > To: Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > -----Original Message----- > > From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr] > > Sent: Thursday, August 31, 2000 2:27 PM > > To: MMyers@verisign.com; ietf-pkix@imc.org; > Karl.Scheibelhofer@iaik.at > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > > > the current status of a certificate is very often not so > > important. when i > > > verify a signature that was created using a specific > > certificate, i want to > > > know, if the certificate was vaild, when the signature > was created. to > > > detemine the time the signature was created, one would ideally use > > > timestamps. using timestamps, it is possible to determine > the signature > > > creation time to be in an intervall [t1,t2]. here t1 and t2 are > > the times of > > > two timestamp (taking time base errors into consideration). > > > what i would like to see in OCSP is a request with the > > following meaning: > > > "what was the state of certificate XYZ in the time > interval [t1,t2]?" > > > > I do not think that you really want to ask this question, see below. > > i do not simply want, in fact i must(!) have a answer to this > question to > decide whether the signature is valid. for me a certificate > status service > it is the most obvious place to get the answer for this question. > > > > the answers could be: > > > 1) the state of certificate XYZ was A (e.g. valid, suspended, > > revoked,...) > > > throughout the time intervall [t1,t2] > > > 3) certificate XYZ changed its state from state A (e.g. valid) > > to state B > > > (e.g. suspended) at tx, where t1 <= tx <= t2 > > > > > > if i get the first answer with 'valid', i can definitely say: > > "the signature > > > it was used for is valid". > > > moreover, this request-response supports any history model for > > certificate. > > > by now OCSP assumes that a certificate can never become valid > > again once it > > > became invalid. > > Hm, > > > > If a certificate was 'invalid' (suspended) and if it becomes > > valid later, then > > why would you want to get a 'suspended' status? > > simply to temporarily take away the rigths that a valid > certificate brings > with for a entity. consider a employee gets suspended for any > reason, the > company may not want to revoke the certificate before the > reason for this > suspension have been verified. and if the company finds out > that the reason > is unjustified, it may want to make the certificate valid > again. during the > period the employee is suspended, the company may not want him do any > business. > > > If it becomes definetely revoked, you get a bad answer, > > if the the current status is still 'pending', you get that. > > And for those cases you get a date, so you can compare. > > > > It is assumed that either by using a cut-off date or by > external knowledge > > you know that for which time frame you get an answer. > > collecting facts from serveral sources to get an answer is > what i want to > avoid. i would like to have a single point where is get a > definitive answer > to the question stated above. by now i have to do serveral > parts of this > processing at the client side. i think the server side would > be the better > place for this. > > > If you want to have more detailed information about the > history, you can > > also require that the signer, a cosigner, a notary, or > whoever you want, > > produce an OCSP response near the moment of the signature and add > > this to the document, or you other protocols to enable > validity checking > > of the document. > > if you sign a lot of documents and always attach all > necessary verification > data, you produce a lot of redundant information. this can be > avoided and i > think this should be avoided. > nevertheless it works. > > > I am not talking about the effects of a CA key compromise > that might allow > > you to create 'good' responses for a non-existing cert, and then > > you estimate > > to be able to fake one in the future. > > i also do not consider a CA key compromise here. > > > > of course, implementing this based on CRLs will be hard, but if > > the server > > > has access to the history of the certificates, it should not be > > a big deal. > > > > > > what do you and others think of this requirement for future OCSP > > Some general thoughts: > > > > So far, OCSP without extensions has been made in such a way > that you can > > create a conforming implementation if you have a repository of CRLs. > > yes i know about this requirement for supporting CRLs. but this is a > implementation issue. > for me as a developer of a signature/verification terminal software my > stated question is the one that i need an answer for. > > > As far as I remember all requests to give different answers > are handled by > > the magic 'do it by an extension'. OCSP adds an archive-cut > off extension > > for example, this seems to me a simple thing to support, knowing the > > the history of the CRLs that you have isn't that difficult. > > just getting my idea in there in any non-standard extension > is not a very > disirable solution. because if i am the only one supporting > it, it is not > better than any ad-hoc protocol. > i posted my idea here to hear the opinion of other people > that use OCSP. > > regards > > Karl Scheibelhofer > > -- > > Karl Scheibelhofer, > Institute for Applied Information Processing and Communications (IAIK) > at Technical University of Graz, Austria, http://www.iaik.at > Phone: (+43) (316) 873-5540 > From owner-ietf-pkix@imc.org Thu Aug 31 10:37:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06787 for ; Thu, 31 Aug 2000 10:37:36 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA25263; Thu, 31 Aug 2000 07:36:18 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 31 Aug 2000 07:36:16 -0700 Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA25232 for ; Thu, 31 Aug 2000 07:36:14 -0700 (PDT) Received: FROM aunt15.ausys.se BY naigwy ; Thu Aug 31 16:34:36 2000 +0200 Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 16:36:39 +0200 Message-ID: From: Simon Tardell To: "'Ambarish Malpani'" Cc: "'Karl Scheibelhofer'" , Peter Sylvester , MMyers@verisign.com, ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification Date: Thu, 31 Aug 2000 16:36:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Collect me if I'm long, but archive cutoff only indicates whether the revocation status of a certificate is "garbage collected" after the expiration of the said certificate (or rather, guarantees that it won't be until some other point in time). The responder will still only tell you about the current status of the certificate. I.e. if the certificate was put on hold and subsequently removed from CRL and is still not expired, you will not be told. Karl wants to wind back time and tell the responder: Use only the information you had at this historical point in time, and answer from that. Simon. Simon Tardell, Software Architect, iD2 Technologies voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 simon.tardell@iD2tech.com, http://www.iD2tech.com Securing the Internet economy > -----Original Message----- > From: Ambarish Malpani [mailto:ambarish@valicert.com] > Sent: den 31 augusti 2000 16:18 > To: 'Karl Scheibelhofer'; Peter Sylvester; MMyers@verisign.com; > ietf-pkix@imc.org > Subject: RE: RFC 2560 - OCSP - Clarification > > > > Hi Karl, > The Archive-Cutoff extension is one that is defined in the > OCSP spec - it would not be a non-standard extension just made up > by you. > > Regards, > Ambarish > > --------------------------------------------------------------------- > Ambarish Malpani > Architect 650.567.5457 > ValiCert, Inc. ambarish@valicert.com > 339 N. Bernardo Ave. http://www.valicert.com > Mountain View, CA 94043 > > > > -----Original Message----- > > From: Karl Scheibelhofer [mailto:Karl.Scheibelhofer@iaik.at] > > Sent: Thursday, August 31, 2000 6:26 AM > > To: Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > > > > -----Original Message----- > > > From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr] > > > Sent: Thursday, August 31, 2000 2:27 PM > > > To: MMyers@verisign.com; ietf-pkix@imc.org; > > Karl.Scheibelhofer@iaik.at > > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > > > > > > > the current status of a certificate is very often not so > > > important. when i > > > > verify a signature that was created using a specific > > > certificate, i want to > > > > know, if the certificate was vaild, when the signature > > was created. to > > > > detemine the time the signature was created, one would > ideally use > > > > timestamps. using timestamps, it is possible to determine > > the signature > > > > creation time to be in an intervall [t1,t2]. here t1 and t2 are > > > the times of > > > > two timestamp (taking time base errors into consideration). > > > > what i would like to see in OCSP is a request with the > > > following meaning: > > > > "what was the state of certificate XYZ in the time > > interval [t1,t2]?" > > > > > > I do not think that you really want to ask this question, > see below. > > > > i do not simply want, in fact i must(!) have a answer to this > > question to > > decide whether the signature is valid. for me a certificate > > status service > > it is the most obvious place to get the answer for this question. > > > > > > the answers could be: > > > > 1) the state of certificate XYZ was A (e.g. valid, suspended, > > > revoked,...) > > > > throughout the time intervall [t1,t2] > > > > 3) certificate XYZ changed its state from state A (e.g. valid) > > > to state B > > > > (e.g. suspended) at tx, where t1 <= tx <= t2 > > > > > > > > if i get the first answer with 'valid', i can definitely say: > > > "the signature > > > > it was used for is valid". > > > > moreover, this request-response supports any history model for > > > certificate. > > > > by now OCSP assumes that a certificate can never become valid > > > again once it > > > > became invalid. > > > Hm, > > > > > > If a certificate was 'invalid' (suspended) and if it becomes > > > valid later, then > > > why would you want to get a 'suspended' status? > > > > simply to temporarily take away the rigths that a valid > > certificate brings > > with for a entity. consider a employee gets suspended for any > > reason, the > > company may not want to revoke the certificate before the > > reason for this > > suspension have been verified. and if the company finds out > > that the reason > > is unjustified, it may want to make the certificate valid > > again. during the > > period the employee is suspended, the company may not want > him do any > > business. > > > > > If it becomes definetely revoked, you get a bad answer, > > > if the the current status is still 'pending', you get that. > > > And for those cases you get a date, so you can compare. > > > > > > It is assumed that either by using a cut-off date or by > > external knowledge > > > you know that for which time frame you get an answer. > > > > collecting facts from serveral sources to get an answer is > > what i want to > > avoid. i would like to have a single point where is get a > > definitive answer > > to the question stated above. by now i have to do serveral > > parts of this > > processing at the client side. i think the server side would > > be the better > > place for this. > > > > > If you want to have more detailed information about the > > history, you can > > > also require that the signer, a cosigner, a notary, or > > whoever you want, > > > produce an OCSP response near the moment of the signature and add > > > this to the document, or you other protocols to enable > > validity checking > > > of the document. > > > > if you sign a lot of documents and always attach all > > necessary verification > > data, you produce a lot of redundant information. this can be > > avoided and i > > think this should be avoided. > > nevertheless it works. > > > > > I am not talking about the effects of a CA key compromise > > that might allow > > > you to create 'good' responses for a non-existing cert, and then > > > you estimate > > > to be able to fake one in the future. > > > > i also do not consider a CA key compromise here. > > > > > > of course, implementing this based on CRLs will be hard, but if > > > the server > > > > has access to the history of the certificates, it should not be > > > a big deal. > > > > > > > > what do you and others think of this requirement for future OCSP > > > Some general thoughts: > > > > > > So far, OCSP without extensions has been made in such a way > > that you can > > > create a conforming implementation if you have a > repository of CRLs. > > > > yes i know about this requirement for supporting CRLs. but this is a > > implementation issue. > > for me as a developer of a signature/verification terminal > software my > > stated question is the one that i need an answer for. > > > > > As far as I remember all requests to give different answers > > are handled by > > > the magic 'do it by an extension'. OCSP adds an archive-cut > > off extension > > > for example, this seems to me a simple thing to support, > knowing the > > > the history of the CRLs that you have isn't that difficult. > > > > just getting my idea in there in any non-standard extension > > is not a very > > disirable solution. because if i am the only one supporting > > it, it is not > > better than any ad-hoc protocol. > > i posted my idea here to hear the opinion of other people > > that use OCSP. > > > > regards > > > > Karl Scheibelhofer > > > > -- > > > > Karl Scheibelhofer, > > Institute for Applied Information Processing and > Communications (IAIK) > > at Technical University of Graz, Austria, http://www.iaik.at > > Phone: (+43) (316) 873-5540 > > > From owner-ietf-pkix@imc.org Thu Aug 31 10:49:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06953 for ; Thu, 31 Aug 2000 10:49:35 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA26206; Thu, 31 Aug 2000 07:48:11 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 31 Aug 2000 07:48:09 -0700 Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA26168 for ; Thu, 31 Aug 2000 07:48:05 -0700 (PDT) Received: FROM aunt15.ausys.se BY naigwy ; Thu Aug 31 16:45:21 2000 +0200 Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 16:47:24 +0200 Message-ID: From: Simon Tardell To: "'ietf-pkix@imc.org'" Cc: "'Karl.Scheibelhofer@iaik.at'" , "'Peter.Sylvester@EdelWeb.fr'" , "'MMyers@verisign.com'" Subject: RE: RFC 2560 - OCSP - Clarification Date: Thu, 31 Aug 2000 16:47:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I tend to agree with both of you. That is, both models are fairly valid. It is my opinion that we should provide standard semantics for supporting both models. The trouble I can see with answering historical questions of the type "what was the status of this certificate at time t (or in the interval [t1, t2])" is that there is no corresponding question to put to a CRL. CRLs are important because (and only because, IMHO) they are the mechanism we have to resynchronize the state of an OCSP responder with that of the internal state of a CA at the time of production of the CRL (which has to be done if the responder does not have access to the internal database of the CA and misses some CRL issued or so). They are also heavily abused as a certificate validation mechanism -- but this is a akin to having a POS terminal downloading the banks account database to be able to validate a credit card purchase. Now, to support the historical question the OCSP responder has to be able to retrieve the state of certificates issued by the CA during the CAs entire history (modulo some cutoff). This means that it will have to have all CRLs that the CA has issued (after that cutoff). That will be a lot of redundant information, and also a lot of processing to get started. A better way would be to have a way to serialize the entire revocation history of certificates from a CA. We could use the CRL form and allow a certificate to appear multiple times (is this actually disallowed?...), e.g. to have entries with revocation reason certificateHold followed by an entry with removeFromCrl _in the same CRL_ if the certificate was later unsuspended (obviously the history could be arbitrarily complicated: suspend, unsuspend, suspend, unsuspend, suspend, permanent). Apparently, used this way "removeFromCrl" becomes a misnomer and should perhaps be called something else. A CRL with these semantics should be marked with a critical extension to avoid confusion. Bottom line: I am in favour of Karl's extension, and I also argue for a similar extension to CRLs to support OCSP responders that are separate from the CA. Simon. Simon Tardell, Software Architect, iD2 Technologies voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 simon.tardell@iD2tech.com, http://www.iD2tech.com Securing the Internet economy > -----Original Message----- > From: Karl Scheibelhofer [mailto:Karl.Scheibelhofer@iaik.at] > Sent: den 31 augusti 2000 15:26 > To: Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > -----Original Message----- > > From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr] > > Sent: Thursday, August 31, 2000 2:27 PM > > To: MMyers@verisign.com; ietf-pkix@imc.org; > Karl.Scheibelhofer@iaik.at > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > > > the current status of a certificate is very often not so > > important. when i > > > verify a signature that was created using a specific > > certificate, i want to > > > know, if the certificate was vaild, when the signature > was created. to > > > detemine the time the signature was created, one would ideally use > > > timestamps. using timestamps, it is possible to determine > the signature > > > creation time to be in an intervall [t1,t2]. here t1 and t2 are > > the times of > > > two timestamp (taking time base errors into consideration). > > > what i would like to see in OCSP is a request with the > > following meaning: > > > "what was the state of certificate XYZ in the time > interval [t1,t2]?" > > > > I do not think that you really want to ask this question, see below. > > i do not simply want, in fact i must(!) have a answer to this > question to > decide whether the signature is valid. for me a certificate > status service > it is the most obvious place to get the answer for this question. > > > > the answers could be: > > > 1) the state of certificate XYZ was A (e.g. valid, suspended, > > revoked,...) > > > throughout the time intervall [t1,t2] > > > 3) certificate XYZ changed its state from state A (e.g. valid) > > to state B > > > (e.g. suspended) at tx, where t1 <= tx <= t2 > > > > > > if i get the first answer with 'valid', i can definitely say: > > "the signature > > > it was used for is valid". > > > moreover, this request-response supports any history model for > > certificate. > > > by now OCSP assumes that a certificate can never become valid > > again once it > > > became invalid. > > Hm, > > > > If a certificate was 'invalid' (suspended) and if it becomes > > valid later, then > > why would you want to get a 'suspended' status? > > simply to temporarily take away the rigths that a valid > certificate brings > with for a entity. consider a employee gets suspended for any > reason, the > company may not want to revoke the certificate before the > reason for this > suspension have been verified. and if the company finds out > that the reason > is unjustified, it may want to make the certificate valid > again. during the > period the employee is suspended, the company may not want him do any > business. > > > If it becomes definetely revoked, you get a bad answer, > > if the the current status is still 'pending', you get that. > > And for those cases you get a date, so you can compare. > > > > It is assumed that either by using a cut-off date or by > external knowledge > > you know that for which time frame you get an answer. > > collecting facts from serveral sources to get an answer is > what i want to > avoid. i would like to have a single point where is get a > definitive answer > to the question stated above. by now i have to do serveral > parts of this > processing at the client side. i think the server side would > be the better > place for this. > > > If you want to have more detailed information about the > history, you can > > also require that the signer, a cosigner, a notary, or > whoever you want, > > produce an OCSP response near the moment of the signature and add > > this to the document, or you other protocols to enable > validity checking > > of the document. > > if you sign a lot of documents and always attach all > necessary verification > data, you produce a lot of redundant information. this can be > avoided and i > think this should be avoided. > nevertheless it works. > > > I am not talking about the effects of a CA key compromise > that might allow > > you to create 'good' responses for a non-existing cert, and then > > you estimate > > to be able to fake one in the future. > > i also do not consider a CA key compromise here. > > > > of course, implementing this based on CRLs will be hard, but if > > the server > > > has access to the history of the certificates, it should not be > > a big deal. > > > > > > what do you and others think of this requirement for future OCSP > > Some general thoughts: > > > > So far, OCSP without extensions has been made in such a way > that you can > > create a conforming implementation if you have a repository of CRLs. > > yes i know about this requirement for supporting CRLs. but this is a > implementation issue. > for me as a developer of a signature/verification terminal software my > stated question is the one that i need an answer for. > > > As far as I remember all requests to give different answers > are handled by > > the magic 'do it by an extension'. OCSP adds an archive-cut > off extension > > for example, this seems to me a simple thing to support, knowing the > > the history of the CRLs that you have isn't that difficult. > > just getting my idea in there in any non-standard extension > is not a very > disirable solution. because if i am the only one supporting > it, it is not > better than any ad-hoc protocol. > i posted my idea here to hear the opinion of other people > that use OCSP. > > regards > > Karl Scheibelhofer > > -- > > Karl Scheibelhofer, > Institute for Applied Information Processing and Communications (IAIK) > at Technical University of Graz, Austria, http://www.iaik.at > Phone: (+43) (316) 873-5540 > From owner-ietf-pkix@imc.org Thu Aug 31 10:54:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07023 for ; Thu, 31 Aug 2000 10:54:05 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA26588; Thu, 31 Aug 2000 07:52:39 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 31 Aug 2000 07:52:37 -0700 Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26558 for ; Thu, 31 Aug 2000 07:52:35 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA10634; Thu, 31 Aug 2000 16:53:08 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 31 Aug 2000 16:53:08 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA14414; Thu, 31 Aug 2000 16:53:07 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA12882; Thu, 31 Aug 2000 16:53:07 +0200 (MET DST) Date: Thu, 31 Aug 2000 16:53:07 +0200 (MET DST) Message-Id: <200008311453.QAA12882@emeriau.edelweb.fr> To: Peter.Sylvester@EdelWeb.fr, RMMyers@verisign.com, ietf-pkix@imc.org, Karl.Scheibelhofer@iaik.at Subject: RE: RFC 2560 - OCSP - Clarification Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > > > > > I do not think that you really want to ask this question, see below. > > i do not simply want, in fact i must(!) have a answer to this question to > decide whether the signature is valid. for me a certificate status service > it is the most obvious place to get the answer for this question. The intial question is: "Is this document/contract/etc a valid one in my context of application etc?" A verifier can also simply ask some server (of the other company or a local company centralized server) "Is this signed document a valid one in this particular application context?" Depending on the answer, continue with the workflow this way or the other *AND* you might want to add the answer as a verifiable element to the 'dossier'. You have reduced the problem space to something that seems to be close to what OCSP could respond. > > If a certificate was 'invalid' (suspended) and if it becomes > > valid later, then > > why would you want to get a 'suspended' status? > > simply to temporarily take away the rigths that a valid certificate brings > with for a entity. consider a employee gets suspended for any reason, the > company may not want to revoke the certificate before the reason for this > suspension have been verified. and if the company finds out that the reason > is unjustified, it may want to make the certificate valid again. during the > period the employee is suspended, the company may not want him do any > business. The person cannot do any business during that time, since any verifier would fall on the suspended status DURING that time, and if something gets rectified later, where is the harm of having prepared a contract in advance? > > > If it becomes definetely revoked, you get a bad answer, > > if the the current status is still 'pending', you get that. > > And for those cases you get a date, so you can compare. > > > > It is assumed that either by using a cut-off date or by external knowledge > > you know that for which time frame you get an answer. > > collecting facts from serveral sources to get an answer is what i want to > avoid. i would like to have a single point where is get a definitive answer > to the question stated above. by now i have to do serveral parts of this > processing at the client side. i think the server side would be the better > place for this. You don't collect answers from several sources, you determine the validity of the document by using some information that you get from one server. You already do local processing by validating the signatures, etc. Why do you start with the second step of validating the cert? you can also ask some server to validate the whole document. > > > If you want to have more detailed information about the history, you can > > also require that the signer, a cosigner, a notary, or whoever you want, > > produce an OCSP response near the moment of the signature and add > > this to the document, or you other protocols to enable validity checking > > of the document. > > if you sign a lot of documents and always attach all necessary verification > data, you produce a lot of redundant information. this can be avoided and i > think this should be avoided. In real life contracts in an enterprise you also add several signatures and other info, like for example you use the officiel forms for contracts of the company (a verifier knows that only authorised persons have access to that), or you add a date stamp of the company and verifiers know that this stamp can only be made if the contract had been reviewed, copied, archived, etc. And you sometimes need a second signature from a financial controller. > nevertheless it works. Where do you see the redundancy: Either the signer or the verifier have to determine 'current' status info, and carrying around a response during the workflow doesn't look a redundant to me. You could also argue that the document itself is redundant because a verifier could be asked to ask a server of potential document producer to deliver all contracts on line when you are ready. > > > I am not talking about the effects of a CA key compromise that might allow > > you to create 'good' responses for a non-existing cert, and then > > you estimate > > to be able to fake one in the future. > > i also do not consider a CA key compromise here. But this could break the whole model? > > > > So far, OCSP without extensions has been made in such a way that you can > > create a conforming implementation if you have a repository of CRLs. > > yes i know about this requirement for supporting CRLs. but this is a > implementation issue. This is a design decision of OCSP, the protocol is specified in such a way that support via CRL repositories are possible. > for me as a developer of a signature/verification terminal software my > stated question is the one that i need an answer for. You don't have a signature/verification terminal. You are assuming a particular application context with a particular validity model of signatures/signed documents. Adding a little bit of 'feature' like "you may not sign during suspension" reminds me to many discussion at least 15 years ago of the kind 'if we just add a trustworthy message-id to mail, then ....'. (Sorry for the flame). But wouldn't the next question be for example: Well, in order to determine the validity of the signature, I have to know whether the signer has already used his quota of money for that certificate, or else ? How do you determine the time of the contract? Probably the signer had to add a time stamps? Why would you allow him to make time stamps during the time his signing cert is suspended? > > > As far as I remember all requests to give different answers are handled by > > the magic 'do it by an extension'. OCSP adds an archive-cut off extension > > for example, this seems to me a simple thing to support, knowing the > > the history of the CRLs that you have isn't that difficult. > > just getting my idea in there in any non-standard extension is not a very > disirable solution. because if i am the only one supporting it, it is not > better than any ad-hoc protocol. Indeed. > i posted my idea here to hear the opinion of other people that use OCSP. You have at some opinion of someone who doesn't (any more). And I share your desire. Maybe you could simply rephrase your question by asking to what extent OCSP support path validation as in : To meet this goal, the path validation process verifies, among other things, that a prospective certification path (a sequence of n certi- ficates) satisfies the following conditions: (i) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate x+1; (ii) certificate 1 is issued by the trust anchor; (iii) certificate n is the end entity certificate; and (iv) for all x in {1, ..., n}, the certificate was valid at the XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX time in question. XXXXXXXXXXXXXXXXX From owner-ietf-pkix@imc.org Thu Aug 31 11:03:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07185 for ; Thu, 31 Aug 2000 11:03:01 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA27023; Thu, 31 Aug 2000 08:01:37 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 31 Aug 2000 08:01:34 -0700 Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26992 for ; Thu, 31 Aug 2000 08:01:33 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA10749; Thu, 31 Aug 2000 17:01:57 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 31 Aug 2000 17:01:57 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA14441; Thu, 31 Aug 2000 17:01:55 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA12887; Thu, 31 Aug 2000 17:01:54 +0200 (MET DST) Date: Thu, 31 Aug 2000 17:01:54 +0200 (MET DST) Message-Id: <200008311501.RAA12887@emeriau.edelweb.fr> To: ambarish@valicert.com, simon.tardell@iD2tech.com Subject: RE: RFC 2560 - OCSP - Clarification Cc: Karl.Scheibelhofer@iaik.at, Peter.Sylvester@EdelWeb.fr, MMyers@verisign.com, ietf-pkix@imc.org Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > > Collect me if I'm long, but archive cutoff only indicates whether the > revocation status of a certificate is "garbage collected" after the > expiration of the said certificate (or rather, guarantees that it won't be > until some other point in time). The responder will still only tell you > about the current status of the certificate. I.e. if the certificate was put > on hold and subsequently removed from CRL and is still not expired, you will > not be told. This seems right. > > Karl wants to wind back time and tell the responder: Use only the > information you had at this historical point in time, and answer from that. > This means to have a protocol that can support 'by the letter' the following spec: To meet this goal, the path validation process verifies, among other things, that a prospective certification path (a sequence of n certi- ficates) satisfies the following conditions: (i) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate x+1; (ii) certificate 1 is issued by the trust anchor; (iii) certificate n is the end entity certificate; and (iv) for all x in {1, ..., n}, the certificate was valid at the time in question. or whether the specification is an overkill and there should be added the two words 'or later' at the end ? From owner-ietf-pkix@imc.org Thu Aug 31 11:12:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07450 for ; Thu, 31 Aug 2000 11:12:32 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA27590; Thu, 31 Aug 2000 08:11:03 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 31 Aug 2000 08:11:01 -0700 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27555 for ; Thu, 31 Aug 2000 08:11:00 -0700 (PDT) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G0500K01WW6M8@ext-mail.valicert.com> for ietf-pkix@imc.org; Thu, 31 Aug 2000 08:12:06 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G0500K0ZWW6L4@ext-mail.valicert.com>; Thu, 31 Aug 2000 08:12:06 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 08:01:31 -0700 Content-return: allowed Date: Thu, 31 Aug 2000 08:01:22 -0700 From: Ambarish Malpani Subject: RE: RFC 2560 - OCSP - Clarification To: "'Simon Tardell'" , Ambarish Malpani Cc: "'Karl Scheibelhofer'" , Peter Sylvester , MMyers@verisign.com, ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE201B831BA@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Sorry, I misread Karl's message. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Simon Tardell [mailto:simon.tardell@iD2tech.com] > Sent: Thursday, August 31, 2000 7:36 AM > To: 'Ambarish Malpani' > Cc: 'Karl Scheibelhofer'; Peter Sylvester; MMyers@verisign.com; > ietf-pkix@imc.org > Subject: RE: RFC 2560 - OCSP - Clarification > > > Collect me if I'm long, but archive cutoff only indicates whether the > revocation status of a certificate is "garbage collected" after the > expiration of the said certificate (or rather, guarantees > that it won't be > until some other point in time). The responder will still > only tell you > about the current status of the certificate. I.e. if the > certificate was put > on hold and subsequently removed from CRL and is still not > expired, you will > not be told. > > Karl wants to wind back time and tell the responder: Use only the > information you had at this historical point in time, and > answer from that. > > Simon. > > Simon Tardell, Software Architect, iD2 Technologies > voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 > simon.tardell@iD2tech.com, http://www.iD2tech.com > Securing the Internet economy > > > > > -----Original Message----- > > From: Ambarish Malpani [mailto:ambarish@valicert.com] > > Sent: den 31 augusti 2000 16:18 > > To: 'Karl Scheibelhofer'; Peter Sylvester; MMyers@verisign.com; > > ietf-pkix@imc.org > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > Hi Karl, > > The Archive-Cutoff extension is one that is defined in the > > OCSP spec - it would not be a non-standard extension just made up > > by you. > > > > Regards, > > Ambarish > > > > > --------------------------------------------------------------------- > > Ambarish Malpani > > Architect > 650.567.5457 > > ValiCert, Inc. > ambarish@valicert.com > > 339 N. Bernardo Ave. > http://www.valicert.com > > Mountain View, CA 94043 > > > > > > > -----Original Message----- > > > From: Karl Scheibelhofer [mailto:Karl.Scheibelhofer@iaik.at] > > > Sent: Thursday, August 31, 2000 6:26 AM > > > To: Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org > > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr] > > > > Sent: Thursday, August 31, 2000 2:27 PM > > > > To: MMyers@verisign.com; ietf-pkix@imc.org; > > > Karl.Scheibelhofer@iaik.at > > > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > > > > > > > > > > > the current status of a certificate is very often not so > > > > important. when i > > > > > verify a signature that was created using a specific > > > > certificate, i want to > > > > > know, if the certificate was vaild, when the signature > > > was created. to > > > > > detemine the time the signature was created, one would > > ideally use > > > > > timestamps. using timestamps, it is possible to determine > > > the signature > > > > > creation time to be in an intervall [t1,t2]. here t1 > and t2 are > > > > the times of > > > > > two timestamp (taking time base errors into consideration). > > > > > what i would like to see in OCSP is a request with the > > > > following meaning: > > > > > "what was the state of certificate XYZ in the time > > > interval [t1,t2]?" > > > > > > > > I do not think that you really want to ask this question, > > see below. > > > > > > i do not simply want, in fact i must(!) have a answer to this > > > question to > > > decide whether the signature is valid. for me a certificate > > > status service > > > it is the most obvious place to get the answer for this question. > > > > > > > > the answers could be: > > > > > 1) the state of certificate XYZ was A (e.g. valid, suspended, > > > > revoked,...) > > > > > throughout the time intervall [t1,t2] > > > > > 3) certificate XYZ changed its state from state A (e.g. valid) > > > > to state B > > > > > (e.g. suspended) at tx, where t1 <= tx <= t2 > > > > > > > > > > if i get the first answer with 'valid', i can definitely say: > > > > "the signature > > > > > it was used for is valid". > > > > > moreover, this request-response supports any history model for > > > > certificate. > > > > > by now OCSP assumes that a certificate can never become valid > > > > again once it > > > > > became invalid. > > > > Hm, > > > > > > > > If a certificate was 'invalid' (suspended) and if it becomes > > > > valid later, then > > > > why would you want to get a 'suspended' status? > > > > > > simply to temporarily take away the rigths that a valid > > > certificate brings > > > with for a entity. consider a employee gets suspended for any > > > reason, the > > > company may not want to revoke the certificate before the > > > reason for this > > > suspension have been verified. and if the company finds out > > > that the reason > > > is unjustified, it may want to make the certificate valid > > > again. during the > > > period the employee is suspended, the company may not want > > him do any > > > business. > > > > > > > If it becomes definetely revoked, you get a bad answer, > > > > if the the current status is still 'pending', you get that. > > > > And for those cases you get a date, so you can compare. > > > > > > > > It is assumed that either by using a cut-off date or by > > > external knowledge > > > > you know that for which time frame you get an answer. > > > > > > collecting facts from serveral sources to get an answer is > > > what i want to > > > avoid. i would like to have a single point where is get a > > > definitive answer > > > to the question stated above. by now i have to do serveral > > > parts of this > > > processing at the client side. i think the server side would > > > be the better > > > place for this. > > > > > > > If you want to have more detailed information about the > > > history, you can > > > > also require that the signer, a cosigner, a notary, or > > > whoever you want, > > > > produce an OCSP response near the moment of the > signature and add > > > > this to the document, or you other protocols to enable > > > validity checking > > > > of the document. > > > > > > if you sign a lot of documents and always attach all > > > necessary verification > > > data, you produce a lot of redundant information. this can be > > > avoided and i > > > think this should be avoided. > > > nevertheless it works. > > > > > > > I am not talking about the effects of a CA key compromise > > > that might allow > > > > you to create 'good' responses for a non-existing cert, and then > > > > you estimate > > > > to be able to fake one in the future. > > > > > > i also do not consider a CA key compromise here. > > > > > > > > of course, implementing this based on CRLs will be > hard, but if > > > > the server > > > > > has access to the history of the certificates, it > should not be > > > > a big deal. > > > > > > > > > > what do you and others think of this requirement for > future OCSP > > > > Some general thoughts: > > > > > > > > So far, OCSP without extensions has been made in such a way > > > that you can > > > > create a conforming implementation if you have a > > repository of CRLs. > > > > > > yes i know about this requirement for supporting CRLs. > but this is a > > > implementation issue. > > > for me as a developer of a signature/verification terminal > > software my > > > stated question is the one that i need an answer for. > > > > > > > As far as I remember all requests to give different answers > > > are handled by > > > > the magic 'do it by an extension'. OCSP adds an archive-cut > > > off extension > > > > for example, this seems to me a simple thing to support, > > knowing the > > > > the history of the CRLs that you have isn't that difficult. > > > > > > just getting my idea in there in any non-standard extension > > > is not a very > > > disirable solution. because if i am the only one supporting > > > it, it is not > > > better than any ad-hoc protocol. > > > i posted my idea here to hear the opinion of other people > > > that use OCSP. > > > > > > regards > > > > > > Karl Scheibelhofer > > > > > > -- > > > > > > Karl Scheibelhofer, > > > Institute for Applied Information Processing and > > Communications (IAIK) > > > at Technical University of Graz, Austria, http://www.iaik.at > > > Phone: (+43) (316) 873-5540 > > > > > > From owner-ietf-pkix@imc.org Thu Aug 31 14:35:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11368 for ; Thu, 31 Aug 2000 14:35:20 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA13741; Thu, 31 Aug 2000 11:33:45 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 31 Aug 2000 11:33:38 -0700 Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13693 for ; Thu, 31 Aug 2000 11:33:37 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id LAA06446 for ; Thu, 31 Aug 2000 11:35:18 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 11:33:44 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4F93F72@vhqpostal.verisign.com> From: Michael Myers To: ietf-pkix@imc.org Subject: OCSP support for historical reference to certificate suspension Date: Thu, 31 Aug 2000 11:33:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe All, This is the same dialog I had Denis on the list regarding a requirement for historical references. That ultimately led to the Archive Cutoff definition that appears in RFC 2560. The text reads: "An OCSP responder MAY choose to retain revocation information beyond a certificate's expiration. The date obtained by subtracting this retention interval value from the producedAt time in a response is defined as the certificate's "archive cutoff" date. OCSP-enabled applications would use an OCSP archive cutoff date to contribute to a proof that a digital signature was (or was not) reliable on the date it was produced even if the certificate needed to validate the signature has long since expired. . . . To illustrate, if a server is operated with a 7-year retention interval policy and status was produced at time t1 then the value for ArchiveCutoff in the response would be (t1 - 7 years)." That is, the historical accuracy of a validation of an expired certificate related to given digital signature is only reliable up to the archive cutoff date. This date is arbitrary. It could be seven years, thirty years or whatever local digital signature rules require. What is needed, and what Denis originally advocated for, was syntax in the request that enabled specification of a date field whose semantics were "was the cert valid at this date?" However, it is unwise to predicate OCSP historical references on the presumption of CRL-based suspension mechanisms given the lack of Internet-scale support of this mechanism. A database-centric approach is much more practical. Given the current work underway regarding 2560bis, I propose to include in the 2560bis work effort an optional "ValidAt" (or some such) field in the request syntax to accomodate this requirement. Comments, anyone? Mike > -----Original Message----- > From: Simon Tardell [mailto:simon.tardell@iD2tech.com] > Sent: Thursday, August 31, 2000 7:36 AM > To: 'Ambarish Malpani' > Cc: 'Karl Scheibelhofer'; Peter Sylvester; MMyers@verisign.com; > ietf-pkix@imc.org > Subject: RE: RFC 2560 - OCSP - Clarification > > > Collect me if I'm long, but archive cutoff only indicates whether the > revocation status of a certificate is "garbage collected" after the > expiration of the said certificate (or rather, guarantees > that it won't be > until some other point in time). The responder will still > only tell you > about the current status of the certificate. I.e. if the > certificate was put > on hold and subsequently removed from CRL and is still not > expired, you will > not be told. > > Karl wants to wind back time and tell the responder: Use only the > information you had at this historical point in time, and > answer from that. > > Simon. > > Simon Tardell, Software Architect, iD2 Technologies > voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 > simon.tardell@iD2tech.com, http://www.iD2tech.com > Securing the Internet economy > > > > > -----Original Message----- > > From: Ambarish Malpani [mailto:ambarish@valicert.com] > > Sent: den 31 augusti 2000 16:18 > > To: 'Karl Scheibelhofer'; Peter Sylvester; MMyers@verisign.com; > > ietf-pkix@imc.org > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > Hi Karl, > > The Archive-Cutoff extension is one that is defined in the > > OCSP spec - it would not be a non-standard extension just made up > > by you. > > > > Regards, > > Ambarish > > > > > --------------------------------------------------------------------- > > Ambarish Malpani > > Architect > 650.567.5457 > > ValiCert, Inc. > ambarish@valicert.com > > 339 N. Bernardo Ave. > http://www.valicert.com > > Mountain View, CA 94043 > > > > > > > -----Original Message----- > > > From: Karl Scheibelhofer [mailto:Karl.Scheibelhofer@iaik.at] > > > Sent: Thursday, August 31, 2000 6:26 AM > > > To: Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org > > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr] > > > > Sent: Thursday, August 31, 2000 2:27 PM > > > > To: MMyers@verisign.com; ietf-pkix@imc.org; > > > Karl.Scheibelhofer@iaik.at > > > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > > > > > > > > > > > the current status of a certificate is very often not so > > > > important. when i > > > > > verify a signature that was created using a specific > > > > certificate, i want to > > > > > know, if the certificate was vaild, when the signature > > > was created. to > > > > > detemine the time the signature was created, one would > > ideally use > > > > > timestamps. using timestamps, it is possible to determine > > > the signature > > > > > creation time to be in an intervall [t1,t2]. here t1 > and t2 are > > > > the times of > > > > > two timestamp (taking time base errors into consideration). > > > > > what i would like to see in OCSP is a request with the > > > > following meaning: > > > > > "what was the state of certificate XYZ in the time > > > interval [t1,t2]?" > > > > > > > > I do not think that you really want to ask this question, > > see below. > > > > > > i do not simply want, in fact i must(!) have a answer to this > > > question to > > > decide whether the signature is valid. for me a certificate > > > status service > > > it is the most obvious place to get the answer for this question. > > > > > > > > the answers could be: > > > > > 1) the state of certificate XYZ was A (e.g. valid, suspended, > > > > revoked,...) > > > > > throughout the time intervall [t1,t2] > > > > > 3) certificate XYZ changed its state from state A (e.g. valid) > > > > to state B > > > > > (e.g. suspended) at tx, where t1 <= tx <= t2 > > > > > > > > > > if i get the first answer with 'valid', i can definitely say: > > > > "the signature > > > > > it was used for is valid". > > > > > moreover, this request-response supports any history model for > > > > certificate. > > > > > by now OCSP assumes that a certificate can never become valid > > > > again once it > > > > > became invalid. > > > > Hm, > > > > > > > > If a certificate was 'invalid' (suspended) and if it becomes > > > > valid later, then > > > > why would you want to get a 'suspended' status? > > > > > > simply to temporarily take away the rigths that a valid > > > certificate brings > > > with for a entity. consider a employee gets suspended for any > > > reason, the > > > company may not want to revoke the certificate before the > > > reason for this > > > suspension have been verified. and if the company finds out > > > that the reason > > > is unjustified, it may want to make the certificate valid > > > again. during the > > > period the employee is suspended, the company may not want > > him do any > > > business. > > > > > > > If it becomes definetely revoked, you get a bad answer, > > > > if the the current status is still 'pending', you get that. > > > > And for those cases you get a date, so you can compare. > > > > > > > > It is assumed that either by using a cut-off date or by > > > external knowledge > > > > you know that for which time frame you get an answer. > > > > > > collecting facts from serveral sources to get an answer is > > > what i want to > > > avoid. i would like to have a single point where is get a > > > definitive answer > > > to the question stated above. by now i have to do serveral > > > parts of this > > > processing at the client side. i think the server side would > > > be the better > > > place for this. > > > > > > > If you want to have more detailed information about the > > > history, you can > > > > also require that the signer, a cosigner, a notary, or > > > whoever you want, > > > > produce an OCSP response near the moment of the > signature and add > > > > this to the document, or you other protocols to enable > > > validity checking > > > > of the document. > > > > > > if you sign a lot of documents and always attach all > > > necessary verification > > > data, you produce a lot of redundant information. this can be > > > avoided and i > > > think this should be avoided. > > > nevertheless it works. > > > > > > > I am not talking about the effects of a CA key compromise > > > that might allow > > > > you to create 'good' responses for a non-existing cert, and then > > > > you estimate > > > > to be able to fake one in the future. > > > > > > i also do not consider a CA key compromise here. > > > > > > > > of course, implementing this based on CRLs will be > hard, but if > > > > the server > > > > > has access to the history of the certificates, it > should not be > > > > a big deal. > > > > > > > > > > what do you and others think of this requirement for > future OCSP > > > > Some general thoughts: > > > > > > > > So far, OCSP without extensions has been made in such a way > > > that you can > > > > create a conforming implementation if you have a > > repository of CRLs. > > > > > > yes i know about this requirement for supporting CRLs. > but this is a > > > implementation issue. > > > for me as a developer of a signature/verification terminal > > software my > > > stated question is the one that i need an answer for. > > > > > > > As far as I remember all requests to give different answers > > > are handled by > > > > the magic 'do it by an extension'. OCSP adds an archive-cut > > > off extension > > > > for example, this seems to me a simple thing to support, > > knowing the > > > > the history of the CRLs that you have isn't that difficult. > > > > > > just getting my idea in there in any non-standard extension > > > is not a very > > > disirable solution. because if i am the only one supporting > > > it, it is not > > > better than any ad-hoc protocol. > > > i posted my idea here to hear the opinion of other people > > > that use OCSP. > > > > > > regards > > > > > > Karl Scheibelhofer > > > > > > -- > > > > > > Karl Scheibelhofer, > > > Institute for Applied Information Processing and > > Communications (IAIK) > > > at Technical University of Graz, Austria, http://www.iaik.at > > > Phone: (+43) (316) 873-5540 > > > > > > From owner-ietf-pkix@imc.org Thu Aug 31 16:07:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12538 for ; Thu, 31 Aug 2000 16:07:59 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA16201; Thu, 31 Aug 2000 13:06:25 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 31 Aug 2000 13:06:19 -0700 Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16170 for ; Thu, 31 Aug 2000 13:06:18 -0700 (PDT) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 13:02:45 -0700 Message-ID: <69A40A314934D41190C70050DAD7F99063B5B7@MAIL> From: Mathew Butler To: "'Peter Sylvester'" , RMMyers@verisign.com, ietf-pkix@imc.org, Karl.Scheibelhofer@iaik.at Subject: RE: RFC 2560 - OCSP - Clarification Date: Thu, 31 Aug 2000 13:02:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Preparing a contract in advance, and committing to it in advance, are two separate problem domains. One is a necessary part of business; the other is fraught with legal problems. Better to not 'enforce' a particular 'legal worldview' on what is eventually going to be a globally-used protocol. (Attempting to exceed your authority to bind a corporation that you're suspended from is 'fraud' in the US, and probably other countries. The way it's usually handled, to rectify the situation if it got screwed up on paper, is to re-sign the document with the current date -- there's no reason why the same requirement not be extended to the digital world, possibly with a statement included with the new signature noting the reason for the re-signing, and a commitment to honor the agreement from the original signature date even though the original signature wasn't technically valid.) Regarding the "why allow a suspended certificate to make timestamps": How easy is it going to be to ensure that the timestamping software checks for certificate suspension via OCSP? [Yes, this is a security consideration.] Also, in the event a third-party timestamping service is used -- how is it going to be possible to ensure that the third-party timestamping service checks all arbitrary CA's and their OCSP responders for current validity of a certificate? Granted, I agree that this is "pandering to the lawyers"... but if we don't do this right, this protocol is eventually going to be challenged as a way to legally validate signatures. -Mat Butler --- Original Message --- The intial question is: "Is this document/contract/etc a valid one in my context of application etc?" A verifier can also simply ask some server (of the other company or a local company centralized server) "Is this signed document a valid one in this particular application context?" Depending on the answer, continue with the workflow this way or the other *AND* you might want to add the answer as a verifiable element to the 'dossier'. You have reduced the problem space to something that seems to be close to what OCSP could respond. --- Original Message --- The person cannot do any business during that time, since any verifier would fall on the suspended status DURING that time, and if something gets rectified later, where is the harm of having prepared a contract in advance? --- Original Message --- You don't have a signature/verification terminal. You are assuming a particular application context with a particular validity model of signatures/signed documents. Adding a little bit of 'feature' like "you may not sign during suspension" reminds me to many discussion at least 15 years ago of the kind 'if we just add a trustworthy message-id to mail, then ....'. (Sorry for the flame). But wouldn't the next question be for example: Well, in order to determine the validity of the signature, I have to know whether the signer has already used his quota of money for that certificate, or else ? How do you determine the time of the contract? Probably the signer had to add a time stamps? Why would you allow him to make time stamps during the time his signing cert is suspended? From owner-ietf-pkix@imc.org Thu Aug 31 16:08:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12549 for ; Thu, 31 Aug 2000 16:08:59 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA16327; Thu, 31 Aug 2000 13:07:32 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 31 Aug 2000 13:07:30 -0700 Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16289 for ; Thu, 31 Aug 2000 13:07:29 -0700 (PDT) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 13:03:55 -0700 Message-ID: <69A40A314934D41190C70050DAD7F99063B5B8@MAIL> From: Mathew Butler To: "'Peter Sylvester'" , ambarish@valicert.com, simon.tardell@iD2tech.com Cc: Karl.Scheibelhofer@iaik.at, MMyers@verisign.com, ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification Date: Thu, 31 Aug 2000 13:03:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I don't think "or later" should be appended. (My reasoning shows up in another message, sent 5 minutes or less before this one.) -Mat Butler -----Original Message----- From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr] Sent: Thursday, August 31, 2000 8:02 AM To: ambarish@valicert.com; simon.tardell@iD2tech.com Cc: Karl.Scheibelhofer@iaik.at; Peter.Sylvester@EdelWeb.fr; MMyers@verisign.com; ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification > > Collect me if I'm long, but archive cutoff only indicates whether the > revocation status of a certificate is "garbage collected" after the > expiration of the said certificate (or rather, guarantees that it won't be > until some other point in time). The responder will still only tell you > about the current status of the certificate. I.e. if the certificate was put > on hold and subsequently removed from CRL and is still not expired, you will > not be told. This seems right. > > Karl wants to wind back time and tell the responder: Use only the > information you had at this historical point in time, and answer from that. > This means to have a protocol that can support 'by the letter' the following spec: To meet this goal, the path validation process verifies, among other things, that a prospective certification path (a sequence of n certi- ficates) satisfies the following conditions: (i) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate x+1; (ii) certificate 1 is issued by the trust anchor; (iii) certificate n is the end entity certificate; and (iv) for all x in {1, ..., n}, the certificate was valid at the time in question. or whether the specification is an overkill and there should be added the two words 'or later' at the end ? From owner-ietf-pkix@imc.org Thu Aug 31 20:24:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14512 for ; Thu, 31 Aug 2000 20:24:28 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA20536; Thu, 31 Aug 2000 16:27:35 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 31 Aug 2000 16:27:17 -0700 Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20494 for ; Thu, 31 Aug 2000 16:27:15 -0700 (PDT) Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 19:27:26 -0400 Message-ID: From: Khaja Ahmed To: "'Karl Scheibelhofer'" , Peter Sylvester , MMyers@verisign.com, ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification Date: Thu, 31 Aug 2000 19:27:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C013A3.054F5DB0" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C013A3.054F5DB0 Content-Type: text/plain; charset="iso-8859-1" Under some circumstances or for some communities it may be possible for the sender of the signed data to send along with the signed data proof that at the time of signing (+/- some tolerance limit) the certificate was not revoked. In other words, the sender could get an ocsp response from a common trusted responder and include this with the transmission of the signed data. This approach offers the advantage that the response can be archived / stored along with the signature. At a later date when the archived / stored signed data and signature is retrieved it can be readily verified as having been valid at creation time (+/- tolerance limit). Is this not an ability that we should formalize and add to appropriate protocols like OCSP? Khaja -----Original Message----- From: Karl Scheibelhofer [mailto:Karl.Scheibelhofer@iaik.at] Sent: Thursday, August 31, 2000 6:26 AM To: Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification > -----Original Message----- > From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr] > Sent: Thursday, August 31, 2000 2:27 PM > To: MMyers@verisign.com; ietf-pkix@imc.org; Karl.Scheibelhofer@iaik.at > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > the current status of a certificate is very often not so > important. when i > > verify a signature that was created using a specific > certificate, i want to > > know, if the certificate was vaild, when the signature was created. to > > detemine the time the signature was created, one would ideally use > > timestamps. using timestamps, it is possible to determine the signature > > creation time to be in an intervall [t1,t2]. here t1 and t2 are > the times of > > two timestamp (taking time base errors into consideration). > > what i would like to see in OCSP is a request with the > following meaning: > > "what was the state of certificate XYZ in the time interval [t1,t2]?" > > I do not think that you really want to ask this question, see below. i do not simply want, in fact i must(!) have a answer to this question to decide whether the signature is valid. for me a certificate status service it is the most obvious place to get the answer for this question. > > the answers could be: > > 1) the state of certificate XYZ was A (e.g. valid, suspended, > revoked,...) > > throughout the time intervall [t1,t2] > > 3) certificate XYZ changed its state from state A (e.g. valid) > to state B > > (e.g. suspended) at tx, where t1 <= tx <= t2 > > > > if i get the first answer with 'valid', i can definitely say: > "the signature > > it was used for is valid". > > moreover, this request-response supports any history model for > certificate. > > by now OCSP assumes that a certificate can never become valid > again once it > > became invalid. > Hm, > > If a certificate was 'invalid' (suspended) and if it becomes > valid later, then > why would you want to get a 'suspended' status? simply to temporarily take away the rigths that a valid certificate brings with for a entity. consider a employee gets suspended for any reason, the company may not want to revoke the certificate before the reason for this suspension have been verified. and if the company finds out that the reason is unjustified, it may want to make the certificate valid again. during the period the employee is suspended, the company may not want him do any business. > If it becomes definetely revoked, you get a bad answer, > if the the current status is still 'pending', you get that. > And for those cases you get a date, so you can compare. > > It is assumed that either by using a cut-off date or by external knowledge > you know that for which time frame you get an answer. collecting facts from serveral sources to get an answer is what i want to avoid. i would like to have a single point where is get a definitive answer to the question stated above. by now i have to do serveral parts of this processing at the client side. i think the server side would be the better place for this. > If you want to have more detailed information about the history, you can > also require that the signer, a cosigner, a notary, or whoever you want, > produce an OCSP response near the moment of the signature and add > this to the document, or you other protocols to enable validity checking > of the document. if you sign a lot of documents and always attach all necessary verification data, you produce a lot of redundant information. this can be avoided and i think this should be avoided. nevertheless it works. > I am not talking about the effects of a CA key compromise that might allow > you to create 'good' responses for a non-existing cert, and then > you estimate > to be able to fake one in the future. i also do not consider a CA key compromise here. > > of course, implementing this based on CRLs will be hard, but if > the server > > has access to the history of the certificates, it should not be > a big deal. > > > > what do you and others think of this requirement for future OCSP > Some general thoughts: > > So far, OCSP without extensions has been made in such a way that you can > create a conforming implementation if you have a repository of CRLs. yes i know about this requirement for supporting CRLs. but this is a implementation issue. for me as a developer of a signature/verification terminal software my stated question is the one that i need an answer for. > As far as I remember all requests to give different answers are handled by > the magic 'do it by an extension'. OCSP adds an archive-cut off extension > for example, this seems to me a simple thing to support, knowing the > the history of the CRLs that you have isn't that difficult. just getting my idea in there in any non-standard extension is not a very disirable solution. because if i am the only one supporting it, it is not better than any ad-hoc protocol. i posted my idea here to hear the opinion of other people that use OCSP. regards Karl Scheibelhofer -- Karl Scheibelhofer, Institute for Applied Information Processing and Communications (IAIK) at Technical University of Graz, Austria, http://www.iaik.at Phone: (+43) (316) 873-5540 ------_=_NextPart_001_01C013A3.054F5DB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: RFC 2560 - OCSP - Clarification

Under some circumstances or for some communities it = may be possible for the sender of the signed data to send along with = the signed data proof that at the time of signing (+/- some tolerance = limit) the certificate was not revoked. In other words, the sender = could get an ocsp response from a common trusted responder and include = this with the transmission of the signed data.  This approach = offers the advantage that the response can be archived / stored along = with the signature.  At a later date when the archived / stored = signed data and signature is retrieved it can be readily verified as = having been valid at creation time (+/- tolerance limit).  =

Is this not an ability that we should formalize and = add to appropriate protocols like OCSP?

Khaja

-----Original Message-----
From: Karl Scheibelhofer [mailto:Karl.Scheibelhofer@iai= k.at]
Sent: Thursday, August 31, 2000 6:26 AM
To: Peter Sylvester; MMyers@verisign.com; = ietf-pkix@imc.org
Subject: RE: RFC 2560 - OCSP - Clarification




> -----Original Message-----
> From: Peter Sylvester [mailto:Peter.Sylvester@EdelWe= b.fr]
> Sent: Thursday, August 31, 2000 2:27 PM
> To: MMyers@verisign.com; ietf-pkix@imc.org; = Karl.Scheibelhofer@iaik.at
> Subject: RE: RFC 2560 - OCSP - = Clarification
>
>
> >
> > the current status of a certificate is = very often not so
> important. when i
> > verify a signature that was created using = a specific
> certificate, i want to
> > know, if the certificate was vaild, when = the signature was created. to
> > detemine the time the signature was = created, one would ideally use
> > timestamps. using timestamps, it is = possible to determine the signature
> > creation time to be in an intervall = [t1,t2]. here t1 and t2 are
> the times of
> > two timestamp (taking time base errors = into consideration).
> > what i would like to see in OCSP is a = request with the
> following meaning:
> > "what was the state of certificate = XYZ in the time interval [t1,t2]?"
>
> I do not think that you really want to ask this = question, see below.

i do not simply want, in fact i must(!) have a answer = to this question to
decide whether the signature is valid. for me a = certificate status service
it is the most obvious place to get the answer for = this question.

> > the answers could be:
> > 1) the state of certificate XYZ was A = (e.g. valid, suspended,
> revoked,...)
> > throughout the time intervall [t1,t2]
> > 3) certificate XYZ changed its state from = state A (e.g. valid)
> to state B
> > (e.g. suspended) at tx, where t1 <=3D = tx <=3D t2
> >
> > if i get the first answer with 'valid', i = can definitely say:
> "the signature
> > it was used for is valid".
> > moreover, this request-response supports = any history model for
> certificate.
> > by now OCSP assumes that a certificate can = never become valid
> again once it
> > became invalid.
> Hm,
>
> If a certificate was 'invalid' (suspended) and = if it becomes
> valid later, then
> why would you want to get a 'suspended' = status?

simply to temporarily take away the rigths that a = valid certificate brings
with for a entity. consider a employee gets = suspended for any reason, the
company may not want to revoke the certificate = before the reason for this
suspension have been verified. and if the company = finds out that the reason
is unjustified, it may want to make the certificate = valid again. during the
period the employee is suspended, the company may = not want him do any
business.

> If it becomes definetely revoked, you get a bad = answer,
> if the the current status is still 'pending', = you get that.
> And for those cases you get a date, so you can = compare.
>
> It is assumed that either by using a cut-off = date or by external knowledge
> you know that for which time frame you get an = answer.

collecting facts from serveral sources to get an = answer is what i want to
avoid. i would like to have a single point where is = get a definitive answer
to the question stated above. by now i have to do = serveral parts of this
processing at the client side. i think the server = side would be the better
place for this.

> If you want to have more detailed information = about the history, you can
> also require that the signer, a cosigner, a = notary, or whoever you want,
> produce an OCSP response near the moment of the = signature and add
> this to the document, or you other protocols to = enable validity checking
> of the document.

if you sign a lot of documents and always attach all = necessary verification
data, you produce a lot of redundant information. = this can be avoided and i
think this should be avoided.
nevertheless it works.

> I am not talking about the effects of a CA key = compromise that might allow
> you to create 'good' responses for a = non-existing cert, and then
> you estimate
> to be able to fake one in the future.

i also do not consider a CA key compromise = here.

> > of course, implementing this based on CRLs = will be hard, but if
> the server
> > has access to the history of the certificat= es, it should not be
> a big deal.
> >
> > what do you and others think of this = requirement for future OCSP
> Some general thoughts:
>
> So far, OCSP without extensions has been made = in such a way that you can
> create a conforming implementation if you have = a repository of CRLs.

yes i know about this requirement for supporting = CRLs. but this is a
implementation issue.
for me as a developer of a signature/verification = terminal software my
stated question is the one that i need an answer = for.

> As far as I remember all requests to give = different answers are handled by
> the magic 'do it by an extension'. OCSP adds an = archive-cut off extension
> for example, this seems to me a simple thing to = support, knowing the
> the history of the CRLs that you have isn't = that difficult.

just getting my idea in there in any non-standard = extension is not a very
disirable solution. because if i am the only one = supporting it, it is not
better than any ad-hoc protocol.
i posted my idea here to hear the opinion of other = people that use OCSP.

regards

  Karl Scheibelhofer

--

Karl Scheibelhofer, <mailto:Karl.Scheibelhofer@iai= k.at>
Institute for Applied Information Processing and = Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) (316) 873-5540

------_=_NextPart_001_01C013A3.054F5DB0-- From owner-ietf-pkix@imc.org Thu Aug 31 20:50:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14818 for ; Thu, 31 Aug 2000 20:50:25 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA21718; Thu, 31 Aug 2000 17:16:17 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 31 Aug 2000 17:12:49 -0700 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA21607 for ; Thu, 31 Aug 2000 17:12:48 -0700 (PDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id RAA10911 for ; Thu, 31 Aug 2000 17:13:53 -0700 (MST)] Received: [from az33exb01.corp.mot.com (az33exb01.corp.mot.com [199.2.84.12]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id RAA15359 for ; Thu, 31 Aug 2000 17:13:53 -0700 (MST)] Received: by AZ33EXB01 with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 17:13:52 -0700 Message-ID: <7DB8A48B5875D411875E00805F77919C974EB6@az25exm04.geg.mot.com> From: Covey Carlin-P21262 To: "'Khaja Ahmed'" , "'Karl Scheibelhofer'" , Peter Sylvester , MMyers@verisign.com, ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification Date: Thu, 31 Aug 2000 17:13:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I agree that some communities may want to know that the signature certificate was valid at the time that data was signed. However, many communities might also want to know that no event has occurred later that would cast doubt on the validity of the signature. For instance, the subject of the signature certificate might have belatedly discovered that his private key had been compromised. It seems inconvenient to send two OSCP requests, one asking "was this certificate good in this interval?" and a second asking "is this certificate good (but perhaps now expired) at the current time?" It seems like an mechanism that purports to answer the first question is obligated to implicitly answer the second. -----Original Message----- From: Khaja Ahmed [mailto:Khaja.Ahmed@identrus.com] Sent: Thursday, August 31, 2000 4:27 PM To: 'Karl Scheibelhofer'; Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification Under some circumstances or for some communities it may be possible for the sender of the signed data to send along with the signed data proof that at the time of signing (+/- some tolerance limit) the certificate was not revoked. In other words, the sender could get an ocsp response from a common trusted responder and include this with the transmission of the signed data. This approach offers the advantage that the response can be archived / stored along with the signature. At a later date when the archived / stored signed data and signature is retrieved it can be readily verified as having been valid at creation time (+/- tolerance limit). Is this not an ability that we should formalize and add to appropriate protocols like OCSP? Khaja -----Original Message----- From: Karl Scheibelhofer [ mailto:Karl.Scheibelhofer@iaik.at ] Sent: Thursday, August 31, 2000 6:26 AM To: Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification > -----Original Message----- > From: Peter Sylvester [ mailto:Peter.Sylvester@EdelWeb.fr ] > Sent: Thursday, August 31, 2000 2:27 PM > To: MMyers@verisign.com; ietf-pkix@imc.org; Karl.Scheibelhofer@iaik.at > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > the current status of a certificate is very often not so > important. when i > > verify a signature that was created using a specific > certificate, i want to > > know, if the certificate was vaild, when the signature was created. to > > detemine the time the signature was created, one would ideally use > > timestamps. using timestamps, it is possible to determine the signature > > creation time to be in an intervall [t1,t2]. here t1 and t2 are > the times of > > two timestamp (taking time base errors into consideration). > > what i would like to see in OCSP is a request with the > following meaning: > > "what was the state of certificate XYZ in the time interval [t1,t2]?" > > I do not think that you really want to ask this question, see below. i do not simply want, in fact i must(!) have a answer to this question to decide whether the signature is valid. for me a certificate status service it is the most obvious place to get the answer for this question. > > the answers could be: > > 1) the state of certificate XYZ was A (e.g. valid, suspended, > revoked,...) > > throughout the time intervall [t1,t2] > > 3) certificate XYZ changed its state from state A (e.g. valid) > to state B > > (e.g. suspended) at tx, where t1 <= tx <= t2 > > > > if i get the first answer with 'valid', i can definitely say: > "the signature > > it was used for is valid". > > moreover, this request-response supports any history model for > certificate. > > by now OCSP assumes that a certificate can never become valid > again once it > > became invalid. > Hm, > > If a certificate was 'invalid' (suspended) and if it becomes > valid later, then > why would you want to get a 'suspended' status? simply to temporarily take away the rigths that a valid certificate brings with for a entity. consider a employee gets suspended for any reason, the company may not want to revoke the certificate before the reason for this suspension have been verified. and if the company finds out that the reason is unjustified, it may want to make the certificate valid again. during the period the employee is suspended, the company may not want him do any business. > If it becomes definetely revoked, you get a bad answer, > if the the current status is still 'pending', you get that. > And for those cases you get a date, so you can compare. > > It is assumed that either by using a cut-off date or by external knowledge > you know that for which time frame you get an answer. collecting facts from serveral sources to get an answer is what i want to avoid. i would like to have a single point where is get a definitive answer to the question stated above. by now i have to do serveral parts of this processing at the client side. i think the server side would be the better place for this. > If you want to have more detailed information about the history, you can > also require that the signer, a cosigner, a notary, or whoever you want, > produce an OCSP response near the moment of the signature and add > this to the document, or you other protocols to enable validity checking > of the document. if you sign a lot of documents and always attach all necessary verification data, you produce a lot of redundant information. this can be avoided and i think this should be avoided. nevertheless it works. > I am not talking about the effects of a CA key compromise that might allow > you to create 'good' responses for a non-existing cert, and then > you estimate > to be able to fake one in the future. i also do not consider a CA key compromise here. > > of course, implementing this based on CRLs will be hard, but if > the server > > has access to the history of the certificates, it should not be > a big deal. > > > > what do you and others think of this requirement for future OCSP > Some general thoughts: > > So far, OCSP without extensions has been made in such a way that you can > create a conforming implementation if you have a repository of CRLs. yes i know about this requirement for supporting CRLs. but this is a implementation issue. for me as a developer of a signature/verification terminal software my stated question is the one that i need an answer for. > As far as I remember all requests to give different answers are handled by > the magic 'do it by an extension'. OCSP adds an archive-cut off extension > for example, this seems to me a simple thing to support, knowing the > the history of the CRLs that you have isn't that difficult. just getting my idea in there in any non-standard extension is not a very disirable solution. because if i am the only one supporting it, it is not better than any ad-hoc protocol. i posted my idea here to hear the opinion of other people that use OCSP. regards Karl Scheibelhofer -- Karl Scheibelhofer, < mailto:Karl.Scheibelhofer@iaik.at > Institute for Applied Information Processing and Communications (IAIK) at Technical University of Graz, Austria, http://www.iaik.at Phone: (+43) (316) 873-5540 From owner-ietf-pkix@imc.org Thu Aug 31 22:17:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17533 for ; Thu, 31 Aug 2000 22:17:08 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA08072; Thu, 31 Aug 2000 19:15:42 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 31 Aug 2000 19:15:35 -0700 Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA08026 for ; Thu, 31 Aug 2000 19:15:33 -0700 (PDT) Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 22:15:48 -0400 Message-ID: From: Khaja Ahmed To: "'Covey Carlin-P21262'" , Khaja Ahmed , "'Karl Scheibelhofer'" , Peter Sylvester , MMyers@verisign.com, ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification Date: Thu, 31 Aug 2000 22:15:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C013BA.874310E0" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C013BA.874310E0 Content-Type: text/plain; charset="iso-8859-1" It is certainly conceivable that validity through a period could be important to know in some circumstances. I wonder, however, if the complexity of such a dialogue requires more effort than is justified by the reward. Let us consider how this might be handled in the world of manual signatures. When a purchase officer at Bloomingdale's sends a manually signed P.O. to Lee's Shirts let us assume that an acknowledgement is immediately sent out. After a lapse of time (to build to order) the 5,000 pink shirts that were ordered are ready to be shipped. The PO is being referenced to make sure that the goods being dispatched are consistent with the PO. Would Lee's shirts want to confirm that the purchase officer is still at Bloomingdale's and that signature is still valid? I suspect not. But then for whatever application you are considering it may be necessary. If so... How does one automate the decision of a relying party when it gets the answer to the question, "was this certificate good in this interval?" It is a potentially burdensome to process the answer in an automated fashion. The answer could be: a.) that the certificate was suspended from time tx to ty, where t1 <= tx <= ty <= t2, or b.) that the certificate was revoked at tx, where t1 <= tx <= t2, or c.) that the certificate expired at tx, where t1 <= tx <= t2 If (a), is it important to know why the certificate was suspended? Does it matter if ty is in fact equal to t2 or equal to the expiry date of the certificate. It could be that the person was on administrative leave until the certificate expired after which he/she was fired. If (b) or (c), what would the relying party do? Furthermore, this requires that the CA maintain in an online database every state transition and that the OCSP responder process this information before responding. This also makes it challenging to now have a set of distributed OCSP responders because you have to distribute/replicate the database. The biggest obstacle, I think, is that the logic to process such responses at a relying party is likely to require much more decision making logic and other input than is realistically going to be provided to most applications. None of the foregoing is to say that the requirement is not legitimate or such capability is not needed or even important. I am just wondering if current realities warrant that we settle for something more modest. i.e. the ability have a dialogue like Questions.) "Is the certificate good now?" or, "Was the certificate good at time t?" Answers.) "Yes" or "No" or "Don't know." This would still require maintenance of detailed state transition information at the CA/VA end but at least the relying party doesn't have very complex decision making logic to go through. Khaja -----Original Message----- From: Covey Carlin-P21262 [mailto:Carlin.Covey@motorola.com] Sent: Thursday, August 31, 2000 5:14 PM To: 'Khaja Ahmed'; 'Karl Scheibelhofer'; Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification I agree that some communities may want to know that the signature certificate was valid at the time that data was signed. However, many communities might also want to know that no event has occurred later that would cast doubt on the validity of the signature. For instance, the subject of the signature certificate might have belatedly discovered that his private key had been compromised. It seems inconvenient to send two OSCP requests, one asking "was this certificate good in this interval?" and a second asking "is this certificate good (but perhaps now expired) at the current time?" It seems like an mechanism that purports to answer the first question is obligated to implicitly answer the second. -----Original Message----- From: Khaja Ahmed [mailto:Khaja.Ahmed@identrus.com] Sent: Thursday, August 31, 2000 4:27 PM To: 'Karl Scheibelhofer'; Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification Under some circumstances or for some communities it may be possible for the sender of the signed data to send along with the signed data proof that at the time of signing (+/- some tolerance limit) the certificate was not revoked. In other words, the sender could get an ocsp response from a common trusted responder and include this with the transmission of the signed data. This approach offers the advantage that the response can be archived / stored along with the signature. At a later date when the archived / stored signed data and signature is retrieved it can be readily verified as having been valid at creation time (+/- tolerance limit). Is this not an ability that we should formalize and add to appropriate protocols like OCSP? Khaja -----Original Message----- From: Karl Scheibelhofer [ mailto:Karl.Scheibelhofer@iaik.at ] Sent: Thursday, August 31, 2000 6:26 AM To: Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification > -----Original Message----- > From: Peter Sylvester [ mailto:Peter.Sylvester@EdelWeb.fr ] > Sent: Thursday, August 31, 2000 2:27 PM > To: MMyers@verisign.com; ietf-pkix@imc.org; Karl.Scheibelhofer@iaik.at > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > the current status of a certificate is very often not so > important. when i > > verify a signature that was created using a specific > certificate, i want to > > know, if the certificate was vaild, when the signature was created. to > > detemine the time the signature was created, one would ideally use > > timestamps. using timestamps, it is possible to determine the signature > > creation time to be in an intervall [t1,t2]. here t1 and t2 are > the times of > > two timestamp (taking time base errors into consideration). > > what i would like to see in OCSP is a request with the > following meaning: > > "what was the state of certificate XYZ in the time interval [t1,t2]?" > > I do not think that you really want to ask this question, see below. i do not simply want, in fact i must(!) have a answer to this question to decide whether the signature is valid. for me a certificate status service it is the most obvious place to get the answer for this question. > > the answers could be: > > 1) the state of certificate XYZ was A (e.g. valid, suspended, > revoked,...) > > throughout the time intervall [t1,t2] > > 3) certificate XYZ changed its state from state A (e.g. valid) > to state B > > (e.g. suspended) at tx, where t1 <= tx <= t2 > > > > if i get the first answer with 'valid', i can definitely say: > "the signature > > it was used for is valid". > > moreover, this request-response supports any history model for > certificate. > > by now OCSP assumes that a certificate can never become valid > again once it > > became invalid. > Hm, > > If a certificate was 'invalid' (suspended) and if it becomes > valid later, then > why would you want to get a 'suspended' status? simply to temporarily take away the rigths that a valid certificate brings with for a entity. consider a employee gets suspended for any reason, the company may not want to revoke the certificate before the reason for this suspension have been verified. and if the company finds out that the reason is unjustified, it may want to make the certificate valid again. during the period the employee is suspended, the company may not want him do any business. > If it becomes definetely revoked, you get a bad answer, > if the the current status is still 'pending', you get that. > And for those cases you get a date, so you can compare. > > It is assumed that either by using a cut-off date or by external knowledge > you know that for which time frame you get an answer. collecting facts from serveral sources to get an answer is what i want to avoid. i would like to have a single point where is get a definitive answer to the question stated above. by now i have to do serveral parts of this processing at the client side. i think the server side would be the better place for this. > If you want to have more detailed information about the history, you can > also require that the signer, a cosigner, a notary, or whoever you want, > produce an OCSP response near the moment of the signature and add > this to the document, or you other protocols to enable validity checking > of the document. if you sign a lot of documents and always attach all necessary verification data, you produce a lot of redundant information. this can be avoided and i think this should be avoided. nevertheless it works. > I am not talking about the effects of a CA key compromise that might allow > you to create 'good' responses for a non-existing cert, and then > you estimate > to be able to fake one in the future. i also do not consider a CA key compromise here. > > of course, implementing this based on CRLs will be hard, but if > the server > > has access to the history of the certificates, it should not be > a big deal. > > > > what do you and others think of this requirement for future OCSP > Some general thoughts: > > So far, OCSP without extensions has been made in such a way that you can > create a conforming implementation if you have a repository of CRLs. yes i know about this requirement for supporting CRLs. but this is a implementation issue. for me as a developer of a signature/verification terminal software my stated question is the one that i need an answer for. > As far as I remember all requests to give different answers are handled by > the magic 'do it by an extension'. OCSP adds an archive-cut off extension > for example, this seems to me a simple thing to support, knowing the > the history of the CRLs that you have isn't that difficult. just getting my idea in there in any non-standard extension is not a very disirable solution. because if i am the only one supporting it, it is not better than any ad-hoc protocol. i posted my idea here to hear the opinion of other people that use OCSP. regards Karl Scheibelhofer -- Karl Scheibelhofer, < mailto:Karl.Scheibelhofer@iaik.at > Institute for Applied Information Processing and Communications (IAIK) at Technical University of Graz, Austria, http://www.iaik.at Phone: (+43) (316) 873-5540 ------_=_NextPart_001_01C013BA.874310E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: RFC 2560 - OCSP - Clarification

It is certainly conceivable that validity through a = period could be important to know in some circumstances.  I = wonder, however, if the complexity of such a dialogue requires more = effort than is justified by the reward. 

Let us consider how this might be handled in the = world of manual signatures.  When a purchase officer at = Bloomingdale's sends a manually signed P.O. to Lee's Shirts let us = assume that an acknowledgement is immediately sent out.  After a = lapse of time (to build to order) the 5,000 pink shirts that were = ordered are ready to be shipped.  The PO is being referenced to = make sure that the goods being dispatched are consistent with the = PO.  Would Lee's shirts want to confirm that the purchase officer = is still at Bloomingdale's and that signature is still valid?  I = suspect not.  But then for whatever application you are = considering it may be necessary.  If so...

How does one automate the decision of a relying party = when it gets the answer to the question, "was this certificate = good in this interval?" It is a potentially burdensome to process = the answer in an automated fashion.  The answer could = be:

a.) that the certificate was suspended from time tx = to ty, where t1 <=3D tx <=3D ty <=3D t2, or
b.) that the certificate was revoked at tx, where t1 = <=3D tx <=3D t2, or
c.) that the certificate expired at tx, where t1 = <=3D tx <=3D t2

If (a), is it important to know why the certificate = was suspended?  Does it matter if ty is in fact equal to t2 or = equal to the expiry date of the certificate.  It could be that the = person was on administrative leave until the certificate expired after = which he/she was fired.

If (b) or (c), what would the relying party do?  =

Furthermore, this requires that the CA maintain in an = online database every state transition and that the OCSP responder = process this information before responding.  This also makes it = challenging to now have a set of distributed OCSP responders because = you have to distribute/replicate the database.

The biggest obstacle, I think, is that the logic to = process such responses at a relying party is likely to require much = more decision making logic and other input than is realistically going = to be provided to most applications. 

None of the foregoing is to say that the requirement = is not legitimate or such capability is not needed or even = important.  I am just wondering if current realities warrant that = we settle for something more modest.  i.e. the ability have a = dialogue like

Questions.) "Is the certificate good now?" = or, "Was the certificate good at time t?"

Answers.) "Yes" or "No" or = "Don't know."

This would still require maintenance of detailed = state transition information at the CA/VA end but at least the relying = party doesn't have very complex decision making logic to go = through.

 

Khaja

-----Original Message-----
From: Covey Carlin-P21262 [mailto:Carlin.Covey@motorola.c= om]
Sent: Thursday, August 31, 2000 5:14 PM
To: 'Khaja Ahmed'; 'Karl Scheibelhofer'; Peter = Sylvester;
MMyers@verisign.com; ietf-pkix@imc.org
Subject: RE: RFC 2560 - OCSP - Clarification


I agree that some communities may want to know that = the signature
certificate was valid at the
time that data was signed.  However, many = communities might also want to
know that no event
has occurred later that would cast doubt on the = validity of the signature.
For instance, the subject
of the signature certificate might have belatedly = discovered that his
private key had been compromised.
It seems inconvenient to send two OSCP requests, one = asking "was this
certificate good in this interval?"
and a second asking "is this certificate good = (but perhaps now expired) at
the current time?"  It seems
like an mechanism that purports to answer the first = question is obligated to
implicitly answer the second.

-----Original Message-----
From: Khaja Ahmed [mailto:Khaja.Ahmed@identrus.com= ]
Sent: Thursday, August 31, 2000 4:27 PM
To: 'Karl Scheibelhofer'; Peter Sylvester; = MMyers@verisign.com;
ietf-pkix@imc.org
Subject: RE: RFC 2560 - OCSP - Clarification



Under some circumstances or for some communities it = may be possible for the
sender of the signed data to send along with the = signed data proof that at
the time of signing (+/- some tolerance limit) the = certificate was not
revoked. In other words, the sender could get an = ocsp response from a common
trusted responder and include this with the = transmission of the signed data.
This approach offers the advantage that the response = can be archived /
stored along with the signature.  At a later = date when the archived / stored
signed data and signature is retrieved it can be = readily verified as having
been valid at creation time (+/- tolerance = limit). 

Is this not an ability that we should formalize and = add to appropriate
protocols like OCSP?

Khaja

-----Original Message-----
From: Karl Scheibelhofer [ mailto:Karl.Scheibelhofer@iai= k.at
<mailto:Karl.Scheibelhofer@iai= k.at> ]
Sent: Thursday, August 31, 2000 6:26 AM
To: Peter Sylvester; MMyers@verisign.com; = ietf-pkix@imc.org
Subject: RE: RFC 2560 - OCSP - Clarification




> -----Original Message-----
> From: Peter Sylvester [ mailto:Peter.Sylvester@EdelWe= b.fr
<mailto:Peter.Sylvester@EdelWe= b.fr> ]
> Sent: Thursday, August 31, 2000 2:27 PM
> To: MMyers@verisign.com; ietf-pkix@imc.org; = Karl.Scheibelhofer@iaik.at
> Subject: RE: RFC 2560 - OCSP - Clarification =
>
>
> >
> > the current status of a certificate is = very often not so
> important. when i
> > verify a signature that was created using = a specific
> certificate, i want to
> > know, if the certificate was vaild, when = the signature was created. to
> > detemine the time the signature was = created, one would ideally use
> > timestamps. using timestamps, it is = possible to determine the signature
> > creation time to be in an intervall = [t1,t2]. here t1 and t2 are
> the times of
> > two timestamp (taking time base errors = into consideration).
> > what i would like to see in OCSP is a = request with the
> following meaning:
> > "what was the state of certificate = XYZ in the time interval [t1,t2]?"
>
> I do not think that you really want to ask this = question, see below.

i do not simply want, in fact i must(!) have a answer = to this question to
decide whether the signature is valid. for me a = certificate status service
it is the most obvious place to get the answer for = this question.

> > the answers could be:
> > 1) the state of certificate XYZ was A = (e.g. valid, suspended,
> revoked,...)
> > throughout the time intervall [t1,t2] =
> > 3) certificate XYZ changed its state from = state A (e.g. valid)
> to state B
> > (e.g. suspended) at tx, where t1 <=3D = tx <=3D t2
> >
> > if i get the first answer with 'valid', i = can definitely say:
> "the signature
> > it was used for is valid".
> > moreover, this request-response supports = any history model for
> certificate.
> > by now OCSP assumes that a certificate can = never become valid
> again once it
> > became invalid.
> Hm,
>
> If a certificate was 'invalid' (suspended) and = if it becomes
> valid later, then
> why would you want to get a 'suspended' status? =

simply to temporarily take away the rigths that a = valid certificate brings
with for a entity. consider a employee gets = suspended for any reason, the
company may not want to revoke the certificate = before the reason for this
suspension have been verified. and if the company = finds out that the reason
is unjustified, it may want to make the certificate = valid again. during the
period the employee is suspended, the company may = not want him do any
business.

> If it becomes definetely revoked, you get a bad = answer,
> if the the current status is still 'pending', = you get that.
> And for those cases you get a date, so you can = compare.
>
> It is assumed that either by using a cut-off = date or by external knowledge

> you know that for which time frame you get an = answer.

collecting facts from serveral sources to get an = answer is what i want to
avoid. i would like to have a single point where is = get a definitive answer
to the question stated above. by now i have to do = serveral parts of this
processing at the client side. i think the server = side would be the better
place for this.

> If you want to have more detailed information = about the history, you can
> also require that the signer, a cosigner, a = notary, or whoever you want,
> produce an OCSP response near the moment of the = signature and add
> this to the document, or you other protocols to = enable validity checking
> of the document.

if you sign a lot of documents and always attach all = necessary verification
data, you produce a lot of redundant information. = this can be avoided and i
think this should be avoided.
nevertheless it works.

> I am not talking about the effects of a CA key = compromise that might allow

> you to create 'good' responses for a = non-existing cert, and then
> you estimate
> to be able to fake one in the future.

i also do not consider a CA key compromise here. =

> > of course, implementing this based on CRLs = will be hard, but if
> the server
> > has access to the history of the = certificates, it should not be
> a big deal.
> >
> > what do you and others think of this = requirement for future OCSP
> Some general thoughts:
>
> So far, OCSP without extensions has been made = in such a way that you can
> create a conforming implementation if you have = a repository of CRLs.

yes i know about this requirement for supporting = CRLs. but this is a
implementation issue.
for me as a developer of a signature/verification = terminal software my
stated question is the one that i need an answer = for.

> As far as I remember all requests to give = different answers are handled by

> the magic 'do it by an extension'. OCSP adds an = archive-cut off extension
> for example, this seems to me a simple thing to = support, knowing the
> the history of the CRLs that you have isn't = that difficult.

just getting my idea in there in any non-standard = extension is not a very
disirable solution. because if i am the only one = supporting it, it is not
better than any ad-hoc protocol.
i posted my idea here to hear the opinion of other = people that use OCSP.

regards

  Karl Scheibelhofer

--

Karl Scheibelhofer, < mailto:Karl.Scheibelhofer@iai= k.at
<mailto:Karl.Scheibelhofer@iai= k.at> >
Institute for Applied Information Processing and Comm= unications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
<http://www.iaik.at> 
Phone: (+43) (316) 873-5540

------_=_NextPart_001_01C013BA.874310E0-- Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA02894 for ; Thu, 31 Aug 2000 23:48:12 -0700 (PDT) Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A16F86C01BA; Fri, 01 Sep 2000 08:49:19 +0200 Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0beta1 14/January/2000); Fri, 01 Sep 2000 08:48:22 +0100 From: "Karl Scheibelhofer" To: "Mathew Butler" , "'Peter Sylvester'" , , Subject: RE: RFC 2560 - OCSP - Clarification Date: Fri, 1 Sep 2000 08:48:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <69A40A314934D41190C70050DAD7F99063B5B7@MAIL> > -----Original Message----- > From: Mathew Butler [mailto:mbutler@tonbu.com] > Sent: Thursday, August 31, 2000 10:03 PM > To: 'Peter Sylvester'; RMMyers@verisign.com; ietf-pkix@imc.org; > Karl.Scheibelhofer@iaik.at > Subject: RE: RFC 2560 - OCSP - Clarification > > > Preparing a contract in advance, and committing to it in advance, are two > separate problem domains. One is a necessary part of business; > the other is > fraught with legal problems. Better to not 'enforce' a particular 'legal > worldview' on what is eventually going to be a globally-used protocol. > (Attempting to exceed your authority to bind a corporation that you're > suspended from is 'fraud' in the US, and probably other > countries. The way > it's usually handled, to rectify the situation if it got screwed up on > paper, is to re-sign the document with the current date -- > there's no reason > why the same requirement not be extended to the digital world, > possibly with > a statement included with the new signature noting the reason for the > re-signing, and a commitment to honor the agreement from the original > signature date even though the original signature wasn't > technically valid.) > > Regarding the "why allow a suspended certificate to make timestamps": How > easy is it going to be to ensure that the timestamping software checks for > certificate suspension via OCSP? [Yes, this is a security consideration.] > Also, in the event a third-party timestamping service is used -- how is it > going to be possible to ensure that the third-party timestamping service > checks all arbitrary CA's and their OCSP responders for current > validity of > a certificate? > > Granted, I agree that this is "pandering to the lawyers"... but > if we don't > do this right, this protocol is eventually going to be challenged as a way > to legally validate signatures. it is the goal of our current project to create/verify legally valid signatures (following the european signature directive). regards Karl Scheibelhofer -- Karl Scheibelhofer, Institute for Applied Information Processing and Communications (IAIK) at Technical University of Graz, Austria, http://www.iaik.at Phone: (+43) (316) 873-5540 Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA02423 for ; Thu, 31 Aug 2000 23:44:25 -0700 (PDT) Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A0902A01D8; Fri, 01 Sep 2000 08:45:36 +0200 Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0beta1 14/January/2000); Fri, 01 Sep 2000 08:44:39 +0100 From: "Karl Scheibelhofer" To: "Michael Myers" , Subject: RE: OCSP support for historical reference to certificate suspension Date: Fri, 1 Sep 2000 08:44:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4F93F72@vhqpostal.verisign.com> > -----Original Message----- > From: Michael Myers [mailto:MMyers@verisign.com] > Sent: Thursday, August 31, 2000 8:34 PM > To: ietf-pkix@imc.org > Subject: OCSP support for historical reference to certificate suspension > > > All, > > This is the same dialog I had Denis on the list regarding a > requirement for > historical references. That ultimately led to the Archive Cutoff > definition > that appears in RFC 2560. > > The text reads: > > "An OCSP responder MAY choose to retain revocation information beyond > a certificate's expiration. The date obtained by subtracting this > retention interval value from the producedAt time in a response is > defined as the certificate's "archive cutoff" date. > > OCSP-enabled applications would use an OCSP archive cutoff date to > contribute to a proof that a digital signature was (or was not) > reliable on the date it was produced even if the certificate needed > to validate the signature has long since expired. > > . . . > > To illustrate, if a server is operated with a 7-year retention > interval policy and status was produced at time t1 then the value for > ArchiveCutoff in the response would be (t1 - 7 years)." > > That is, the historical accuracy of a validation of an expired certificate > related to given digital signature is only reliable up to the > archive cutoff > date. This date is arbitrary. It could be seven years, thirty years or > whatever local digital signature rules require. > > What is needed, and what Denis originally advocated for, was syntax in the > request that enabled specification of a date field whose > semantics were "was > the cert valid at this date?" However, it is unwise to predicate OCSP > historical references on the presumption of CRL-based suspension > mechanisms > given the lack of Internet-scale support of this mechanism. A > database-centric approach is much more practical. > > Given the current work underway regarding 2560bis, I propose to include in > the 2560bis work effort an optional "ValidAt" (or some such) field in the > request syntax to accomodate this requirement. normally, it will not be possible to determine the signature creation time exactly. the best i can reliable determine is, that the signature was created in a time intervall (between two time stamps). so if you plan to include a time field, i think it would be nice to consider taking an interval. you can make the second value optional. regards Karl Scheibelhofer -- Karl Scheibelhofer, Institute for Applied Information Processing and Communications (IAIK) at Technical University of Graz, Austria, http://www.iaik.at Phone: (+43) (316) 873-5540 Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA01659 for ; Thu, 31 Aug 2000 23:38:41 -0700 (PDT) Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id AF3684101BA; Fri, 01 Sep 2000 08:39:50 +0200 Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0beta1 14/January/2000); Fri, 01 Sep 2000 08:38:53 +0100 From: "Karl Scheibelhofer" To: "Peter Sylvester" , , Subject: RE: RFC 2560 - OCSP - Clarification Date: Fri, 1 Sep 2000 08:38:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <200008311453.QAA12882@emeriau.edelweb.fr> > -----Original Message----- > From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr] > Sent: Thursday, August 31, 2000 4:53 PM > To: Peter.Sylvester@EdelWeb.fr; RMMyers@verisign.com; ietf-pkix@imc.org; > Karl.Scheibelhofer@iaik.at > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > > > I do not think that you really want to ask this question, see below. > > > > i do not simply want, in fact i must(!) have a answer to this > question to > > decide whether the signature is valid. for me a certificate > status service > > it is the most obvious place to get the answer for this question. > > The intial question is: "Is this document/contract/etc a valid one in my > context of application etc?" > > A verifier can also simply ask some server (of the other company or a > local company centralized server) > > "Is this signed document a valid one in this particular > application context?" sorry, but i don't want to send my documents for verification to other companies. and i think most managers won't allow that. moreover, you have the to anser the same question at this server. no matter where you process it, for a serious validation you need to answer this question. > Depending on the answer, continue with the workflow this way or the other > *AND* you might want to add the answer as a verifiable element to > the 'dossier'. > > You have reduced the problem space to something that seems to be close to > what OCSP could respond. > > > > > If a certificate was 'invalid' (suspended) and if it becomes > > > valid later, then > > > why would you want to get a 'suspended' status? > > > > simply to temporarily take away the rigths that a valid > certificate brings > > with for a entity. consider a employee gets suspended for any > reason, the > > company may not want to revoke the certificate before the > reason for this > > suspension have been verified. and if the company finds out > that the reason > > is unjustified, it may want to make the certificate valid > again. during the > > period the employee is suspended, the company may not want him do any > > business. > > The person cannot do any business during that time, since any > verifier would > fall on the suspended status DURING that time, and if something > gets rectified > later, where is the harm of having prepared a contract in advance? you may not be allowed to sign anything because of legal issues. > > > > > > If it becomes definetely revoked, you get a bad answer, > > > if the the current status is still 'pending', you get that. > > > And for those cases you get a date, so you can compare. > > > > > > It is assumed that either by using a cut-off date or by > external knowledge > > > you know that for which time frame you get an answer. > > > > collecting facts from serveral sources to get an answer is what > i want to > > avoid. i would like to have a single point where is get a > definitive answer > > to the question stated above. by now i have to do serveral parts of this > > processing at the client side. i think the server side would be > the better > > place for this. > > You don't collect answers from several sources, you determine the > validity > of the document by using some information that you get from one server. > > You already do local processing by validating the signatures, etc. > > Why do you start with the second step of validating the cert? you > can also ask > some server to validate the whole document. yes, implementing a server for document validation makes sense. but this server also needs an answer for this question. regards Karl Scheibelhofer -- Karl Scheibelhofer, Institute for Applied Information Processing and Communications (IAIK) at Technical University of Graz, Austria, http://www.iaik.at Phone: (+43) (316) 873-5540 Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA08026 for ; Thu, 31 Aug 2000 19:15:33 -0700 (PDT) Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 22:15:48 -0400 Message-ID: From: Khaja Ahmed To: "'Covey Carlin-P21262'" , Khaja Ahmed , "'Karl Scheibelhofer'" , Peter Sylvester , MMyers@verisign.com, ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification Date: Thu, 31 Aug 2000 22:15:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C013BA.874310E0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C013BA.874310E0 Content-Type: text/plain; charset="iso-8859-1" It is certainly conceivable that validity through a period could be important to know in some circumstances. I wonder, however, if the complexity of such a dialogue requires more effort than is justified by the reward. Let us consider how this might be handled in the world of manual signatures. When a purchase officer at Bloomingdale's sends a manually signed P.O. to Lee's Shirts let us assume that an acknowledgement is immediately sent out. After a lapse of time (to build to order) the 5,000 pink shirts that were ordered are ready to be shipped. The PO is being referenced to make sure that the goods being dispatched are consistent with the PO. Would Lee's shirts want to confirm that the purchase officer is still at Bloomingdale's and that signature is still valid? I suspect not. But then for whatever application you are considering it may be necessary. If so... How does one automate the decision of a relying party when it gets the answer to the question, "was this certificate good in this interval?" It is a potentially burdensome to process the answer in an automated fashion. The answer could be: a.) that the certificate was suspended from time tx to ty, where t1 <= tx <= ty <= t2, or b.) that the certificate was revoked at tx, where t1 <= tx <= t2, or c.) that the certificate expired at tx, where t1 <= tx <= t2 If (a), is it important to know why the certificate was suspended? Does it matter if ty is in fact equal to t2 or equal to the expiry date of the certificate. It could be that the person was on administrative leave until the certificate expired after which he/she was fired. If (b) or (c), what would the relying party do? Furthermore, this requires that the CA maintain in an online database every state transition and that the OCSP responder process this information before responding. This also makes it challenging to now have a set of distributed OCSP responders because you have to distribute/replicate the database. The biggest obstacle, I think, is that the logic to process such responses at a relying party is likely to require much more decision making logic and other input than is realistically going to be provided to most applications. None of the foregoing is to say that the requirement is not legitimate or such capability is not needed or even important. I am just wondering if current realities warrant that we settle for something more modest. i.e. the ability have a dialogue like Questions.) "Is the certificate good now?" or, "Was the certificate good at time t?" Answers.) "Yes" or "No" or "Don't know." This would still require maintenance of detailed state transition information at the CA/VA end but at least the relying party doesn't have very complex decision making logic to go through. Khaja -----Original Message----- From: Covey Carlin-P21262 [mailto:Carlin.Covey@motorola.com] Sent: Thursday, August 31, 2000 5:14 PM To: 'Khaja Ahmed'; 'Karl Scheibelhofer'; Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification I agree that some communities may want to know that the signature certificate was valid at the time that data was signed. However, many communities might also want to know that no event has occurred later that would cast doubt on the validity of the signature. For instance, the subject of the signature certificate might have belatedly discovered that his private key had been compromised. It seems inconvenient to send two OSCP requests, one asking "was this certificate good in this interval?" and a second asking "is this certificate good (but perhaps now expired) at the current time?" It seems like an mechanism that purports to answer the first question is obligated to implicitly answer the second. -----Original Message----- From: Khaja Ahmed [mailto:Khaja.Ahmed@identrus.com] Sent: Thursday, August 31, 2000 4:27 PM To: 'Karl Scheibelhofer'; Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification Under some circumstances or for some communities it may be possible for the sender of the signed data to send along with the signed data proof that at the time of signing (+/- some tolerance limit) the certificate was not revoked. In other words, the sender could get an ocsp response from a common trusted responder and include this with the transmission of the signed data. This approach offers the advantage that the response can be archived / stored along with the signature. At a later date when the archived / stored signed data and signature is retrieved it can be readily verified as having been valid at creation time (+/- tolerance limit). Is this not an ability that we should formalize and add to appropriate protocols like OCSP? Khaja -----Original Message----- From: Karl Scheibelhofer [ mailto:Karl.Scheibelhofer@iaik.at ] Sent: Thursday, August 31, 2000 6:26 AM To: Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification > -----Original Message----- > From: Peter Sylvester [ mailto:Peter.Sylvester@EdelWeb.fr ] > Sent: Thursday, August 31, 2000 2:27 PM > To: MMyers@verisign.com; ietf-pkix@imc.org; Karl.Scheibelhofer@iaik.at > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > the current status of a certificate is very often not so > important. when i > > verify a signature that was created using a specific > certificate, i want to > > know, if the certificate was vaild, when the signature was created. to > > detemine the time the signature was created, one would ideally use > > timestamps. using timestamps, it is possible to determine the signature > > creation time to be in an intervall [t1,t2]. here t1 and t2 are > the times of > > two timestamp (taking time base errors into consideration). > > what i would like to see in OCSP is a request with the > following meaning: > > "what was the state of certificate XYZ in the time interval [t1,t2]?" > > I do not think that you really want to ask this question, see below. i do not simply want, in fact i must(!) have a answer to this question to decide whether the signature is valid. for me a certificate status service it is the most obvious place to get the answer for this question. > > the answers could be: > > 1) the state of certificate XYZ was A (e.g. valid, suspended, > revoked,...) > > throughout the time intervall [t1,t2] > > 3) certificate XYZ changed its state from state A (e.g. valid) > to state B > > (e.g. suspended) at tx, where t1 <= tx <= t2 > > > > if i get the first answer with 'valid', i can definitely say: > "the signature > > it was used for is valid". > > moreover, this request-response supports any history model for > certificate. > > by now OCSP assumes that a certificate can never become valid > again once it > > became invalid. > Hm, > > If a certificate was 'invalid' (suspended) and if it becomes > valid later, then > why would you want to get a 'suspended' status? simply to temporarily take away the rigths that a valid certificate brings with for a entity. consider a employee gets suspended for any reason, the company may not want to revoke the certificate before the reason for this suspension have been verified. and if the company finds out that the reason is unjustified, it may want to make the certificate valid again. during the period the employee is suspended, the company may not want him do any business. > If it becomes definetely revoked, you get a bad answer, > if the the current status is still 'pending', you get that. > And for those cases you get a date, so you can compare. > > It is assumed that either by using a cut-off date or by external knowledge > you know that for which time frame you get an answer. collecting facts from serveral sources to get an answer is what i want to avoid. i would like to have a single point where is get a definitive answer to the question stated above. by now i have to do serveral parts of this processing at the client side. i think the server side would be the better place for this. > If you want to have more detailed information about the history, you can > also require that the signer, a cosigner, a notary, or whoever you want, > produce an OCSP response near the moment of the signature and add > this to the document, or you other protocols to enable validity checking > of the document. if you sign a lot of documents and always attach all necessary verification data, you produce a lot of redundant information. this can be avoided and i think this should be avoided. nevertheless it works. > I am not talking about the effects of a CA key compromise that might allow > you to create 'good' responses for a non-existing cert, and then > you estimate > to be able to fake one in the future. i also do not consider a CA key compromise here. > > of course, implementing this based on CRLs will be hard, but if > the server > > has access to the history of the certificates, it should not be > a big deal. > > > > what do you and others think of this requirement for future OCSP > Some general thoughts: > > So far, OCSP without extensions has been made in such a way that you can > create a conforming implementation if you have a repository of CRLs. yes i know about this requirement for supporting CRLs. but this is a implementation issue. for me as a developer of a signature/verification terminal software my stated question is the one that i need an answer for. > As far as I remember all requests to give different answers are handled by > the magic 'do it by an extension'. OCSP adds an archive-cut off extension > for example, this seems to me a simple thing to support, knowing the > the history of the CRLs that you have isn't that difficult. just getting my idea in there in any non-standard extension is not a very disirable solution. because if i am the only one supporting it, it is not better than any ad-hoc protocol. i posted my idea here to hear the opinion of other people that use OCSP. regards Karl Scheibelhofer -- Karl Scheibelhofer, < mailto:Karl.Scheibelhofer@iaik.at > Institute for Applied Information Processing and Communications (IAIK) at Technical University of Graz, Austria, http://www.iaik.at Phone: (+43) (316) 873-5540 ------_=_NextPart_001_01C013BA.874310E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: RFC 2560 - OCSP - Clarification

It is certainly conceivable that validity through a = period could be important to know in some circumstances.  I = wonder, however, if the complexity of such a dialogue requires more = effort than is justified by the reward. 

Let us consider how this might be handled in the = world of manual signatures.  When a purchase officer at = Bloomingdale's sends a manually signed P.O. to Lee's Shirts let us = assume that an acknowledgement is immediately sent out.  After a = lapse of time (to build to order) the 5,000 pink shirts that were = ordered are ready to be shipped.  The PO is being referenced to = make sure that the goods being dispatched are consistent with the = PO.  Would Lee's shirts want to confirm that the purchase officer = is still at Bloomingdale's and that signature is still valid?  I = suspect not.  But then for whatever application you are = considering it may be necessary.  If so...

How does one automate the decision of a relying party = when it gets the answer to the question, "was this certificate = good in this interval?" It is a potentially burdensome to process = the answer in an automated fashion.  The answer could = be:

a.) that the certificate was suspended from time tx = to ty, where t1 <=3D tx <=3D ty <=3D t2, or
b.) that the certificate was revoked at tx, where t1 = <=3D tx <=3D t2, or
c.) that the certificate expired at tx, where t1 = <=3D tx <=3D t2

If (a), is it important to know why the certificate = was suspended?  Does it matter if ty is in fact equal to t2 or = equal to the expiry date of the certificate.  It could be that the = person was on administrative leave until the certificate expired after = which he/she was fired.

If (b) or (c), what would the relying party do?  =

Furthermore, this requires that the CA maintain in an = online database every state transition and that the OCSP responder = process this information before responding.  This also makes it = challenging to now have a set of distributed OCSP responders because = you have to distribute/replicate the database.

The biggest obstacle, I think, is that the logic to = process such responses at a relying party is likely to require much = more decision making logic and other input than is realistically going = to be provided to most applications. 

None of the foregoing is to say that the requirement = is not legitimate or such capability is not needed or even = important.  I am just wondering if current realities warrant that = we settle for something more modest.  i.e. the ability have a = dialogue like

Questions.) "Is the certificate good now?" = or, "Was the certificate good at time t?"

Answers.) "Yes" or "No" or = "Don't know."

This would still require maintenance of detailed = state transition information at the CA/VA end but at least the relying = party doesn't have very complex decision making logic to go = through.

 

Khaja

-----Original Message-----
From: Covey Carlin-P21262 [mailto:Carlin.Covey@motorola.c= om]
Sent: Thursday, August 31, 2000 5:14 PM
To: 'Khaja Ahmed'; 'Karl Scheibelhofer'; Peter = Sylvester;
MMyers@verisign.com; ietf-pkix@imc.org
Subject: RE: RFC 2560 - OCSP - Clarification


I agree that some communities may want to know that = the signature
certificate was valid at the
time that data was signed.  However, many = communities might also want to
know that no event
has occurred later that would cast doubt on the = validity of the signature.
For instance, the subject
of the signature certificate might have belatedly = discovered that his
private key had been compromised.
It seems inconvenient to send two OSCP requests, one = asking "was this
certificate good in this interval?"
and a second asking "is this certificate good = (but perhaps now expired) at
the current time?"  It seems
like an mechanism that purports to answer the first = question is obligated to
implicitly answer the second.

-----Original Message-----
From: Khaja Ahmed [mailto:Khaja.Ahmed@identrus.com= ]
Sent: Thursday, August 31, 2000 4:27 PM
To: 'Karl Scheibelhofer'; Peter Sylvester; = MMyers@verisign.com;
ietf-pkix@imc.org
Subject: RE: RFC 2560 - OCSP - Clarification



Under some circumstances or for some communities it = may be possible for the
sender of the signed data to send along with the = signed data proof that at
the time of signing (+/- some tolerance limit) the = certificate was not
revoked. In other words, the sender could get an = ocsp response from a common
trusted responder and include this with the = transmission of the signed data.
This approach offers the advantage that the response = can be archived /
stored along with the signature.  At a later = date when the archived / stored
signed data and signature is retrieved it can be = readily verified as having
been valid at creation time (+/- tolerance = limit). 

Is this not an ability that we should formalize and = add to appropriate
protocols like OCSP?

Khaja

-----Original Message-----
From: Karl Scheibelhofer [ mailto:Karl.Scheibelhofer@iai= k.at
<mailto:Karl.Scheibelhofer@iai= k.at> ]
Sent: Thursday, August 31, 2000 6:26 AM
To: Peter Sylvester; MMyers@verisign.com; = ietf-pkix@imc.org
Subject: RE: RFC 2560 - OCSP - Clarification




> -----Original Message-----
> From: Peter Sylvester [ mailto:Peter.Sylvester@EdelWe= b.fr
<mailto:Peter.Sylvester@EdelWe= b.fr> ]
> Sent: Thursday, August 31, 2000 2:27 PM
> To: MMyers@verisign.com; ietf-pkix@imc.org; = Karl.Scheibelhofer@iaik.at
> Subject: RE: RFC 2560 - OCSP - Clarification =
>
>
> >
> > the current status of a certificate is = very often not so
> important. when i
> > verify a signature that was created using = a specific
> certificate, i want to
> > know, if the certificate was vaild, when = the signature was created. to
> > detemine the time the signature was = created, one would ideally use
> > timestamps. using timestamps, it is = possible to determine the signature
> > creation time to be in an intervall = [t1,t2]. here t1 and t2 are
> the times of
> > two timestamp (taking time base errors = into consideration).
> > what i would like to see in OCSP is a = request with the
> following meaning:
> > "what was the state of certificate = XYZ in the time interval [t1,t2]?"
>
> I do not think that you really want to ask this = question, see below.

i do not simply want, in fact i must(!) have a answer = to this question to
decide whether the signature is valid. for me a = certificate status service
it is the most obvious place to get the answer for = this question.

> > the answers could be:
> > 1) the state of certificate XYZ was A = (e.g. valid, suspended,
> revoked,...)
> > throughout the time intervall [t1,t2] =
> > 3) certificate XYZ changed its state from = state A (e.g. valid)
> to state B
> > (e.g. suspended) at tx, where t1 <=3D = tx <=3D t2
> >
> > if i get the first answer with 'valid', i = can definitely say:
> "the signature
> > it was used for is valid".
> > moreover, this request-response supports = any history model for
> certificate.
> > by now OCSP assumes that a certificate can = never become valid
> again once it
> > became invalid.
> Hm,
>
> If a certificate was 'invalid' (suspended) and = if it becomes
> valid later, then
> why would you want to get a 'suspended' status? =

simply to temporarily take away the rigths that a = valid certificate brings
with for a entity. consider a employee gets = suspended for any reason, the
company may not want to revoke the certificate = before the reason for this
suspension have been verified. and if the company = finds out that the reason
is unjustified, it may want to make the certificate = valid again. during the
period the employee is suspended, the company may = not want him do any
business.

> If it becomes definetely revoked, you get a bad = answer,
> if the the current status is still 'pending', = you get that.
> And for those cases you get a date, so you can = compare.
>
> It is assumed that either by using a cut-off = date or by external knowledge

> you know that for which time frame you get an = answer.

collecting facts from serveral sources to get an = answer is what i want to
avoid. i would like to have a single point where is = get a definitive answer
to the question stated above. by now i have to do = serveral parts of this
processing at the client side. i think the server = side would be the better
place for this.

> If you want to have more detailed information = about the history, you can
> also require that the signer, a cosigner, a = notary, or whoever you want,
> produce an OCSP response near the moment of the = signature and add
> this to the document, or you other protocols to = enable validity checking
> of the document.

if you sign a lot of documents and always attach all = necessary verification
data, you produce a lot of redundant information. = this can be avoided and i
think this should be avoided.
nevertheless it works.

> I am not talking about the effects of a CA key = compromise that might allow

> you to create 'good' responses for a = non-existing cert, and then
> you estimate
> to be able to fake one in the future.

i also do not consider a CA key compromise here. =

> > of course, implementing this based on CRLs = will be hard, but if
> the server
> > has access to the history of the = certificates, it should not be
> a big deal.
> >
> > what do you and others think of this = requirement for future OCSP
> Some general thoughts:
>
> So far, OCSP without extensions has been made = in such a way that you can
> create a conforming implementation if you have = a repository of CRLs.

yes i know about this requirement for supporting = CRLs. but this is a
implementation issue.
for me as a developer of a signature/verification = terminal software my
stated question is the one that i need an answer = for.

> As far as I remember all requests to give = different answers are handled by

> the magic 'do it by an extension'. OCSP adds an = archive-cut off extension
> for example, this seems to me a simple thing to = support, knowing the
> the history of the CRLs that you have isn't = that difficult.

just getting my idea in there in any non-standard = extension is not a very
disirable solution. because if i am the only one = supporting it, it is not
better than any ad-hoc protocol.
i posted my idea here to hear the opinion of other = people that use OCSP.

regards

  Karl Scheibelhofer

--

Karl Scheibelhofer, < mailto:Karl.Scheibelhofer@iai= k.at
<mailto:Karl.Scheibelhofer@iai= k.at> >
Institute for Applied Information Processing and Comm= unications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
<http://www.iaik.at> 
Phone: (+43) (316) 873-5540

------_=_NextPart_001_01C013BA.874310E0-- Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA21607 for ; Thu, 31 Aug 2000 17:12:48 -0700 (PDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id RAA10911 for ; Thu, 31 Aug 2000 17:13:53 -0700 (MST)] Received: [from az33exb01.corp.mot.com (az33exb01.corp.mot.com [199.2.84.12]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id RAA15359 for ; Thu, 31 Aug 2000 17:13:53 -0700 (MST)] Received: by AZ33EXB01 with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 17:13:52 -0700 Message-ID: <7DB8A48B5875D411875E00805F77919C974EB6@az25exm04.geg.mot.com> From: Covey Carlin-P21262 To: "'Khaja Ahmed'" , "'Karl Scheibelhofer'" , Peter Sylvester , MMyers@verisign.com, ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification Date: Thu, 31 Aug 2000 17:13:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" I agree that some communities may want to know that the signature certificate was valid at the time that data was signed. However, many communities might also want to know that no event has occurred later that would cast doubt on the validity of the signature. For instance, the subject of the signature certificate might have belatedly discovered that his private key had been compromised. It seems inconvenient to send two OSCP requests, one asking "was this certificate good in this interval?" and a second asking "is this certificate good (but perhaps now expired) at the current time?" It seems like an mechanism that purports to answer the first question is obligated to implicitly answer the second. -----Original Message----- From: Khaja Ahmed [mailto:Khaja.Ahmed@identrus.com] Sent: Thursday, August 31, 2000 4:27 PM To: 'Karl Scheibelhofer'; Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification Under some circumstances or for some communities it may be possible for the sender of the signed data to send along with the signed data proof that at the time of signing (+/- some tolerance limit) the certificate was not revoked. In other words, the sender could get an ocsp response from a common trusted responder and include this with the transmission of the signed data. This approach offers the advantage that the response can be archived / stored along with the signature. At a later date when the archived / stored signed data and signature is retrieved it can be readily verified as having been valid at creation time (+/- tolerance limit). Is this not an ability that we should formalize and add to appropriate protocols like OCSP? Khaja -----Original Message----- From: Karl Scheibelhofer [ mailto:Karl.Scheibelhofer@iaik.at ] Sent: Thursday, August 31, 2000 6:26 AM To: Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification > -----Original Message----- > From: Peter Sylvester [ mailto:Peter.Sylvester@EdelWeb.fr ] > Sent: Thursday, August 31, 2000 2:27 PM > To: MMyers@verisign.com; ietf-pkix@imc.org; Karl.Scheibelhofer@iaik.at > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > the current status of a certificate is very often not so > important. when i > > verify a signature that was created using a specific > certificate, i want to > > know, if the certificate was vaild, when the signature was created. to > > detemine the time the signature was created, one would ideally use > > timestamps. using timestamps, it is possible to determine the signature > > creation time to be in an intervall [t1,t2]. here t1 and t2 are > the times of > > two timestamp (taking time base errors into consideration). > > what i would like to see in OCSP is a request with the > following meaning: > > "what was the state of certificate XYZ in the time interval [t1,t2]?" > > I do not think that you really want to ask this question, see below. i do not simply want, in fact i must(!) have a answer to this question to decide whether the signature is valid. for me a certificate status service it is the most obvious place to get the answer for this question. > > the answers could be: > > 1) the state of certificate XYZ was A (e.g. valid, suspended, > revoked,...) > > throughout the time intervall [t1,t2] > > 3) certificate XYZ changed its state from state A (e.g. valid) > to state B > > (e.g. suspended) at tx, where t1 <= tx <= t2 > > > > if i get the first answer with 'valid', i can definitely say: > "the signature > > it was used for is valid". > > moreover, this request-response supports any history model for > certificate. > > by now OCSP assumes that a certificate can never become valid > again once it > > became invalid. > Hm, > > If a certificate was 'invalid' (suspended) and if it becomes > valid later, then > why would you want to get a 'suspended' status? simply to temporarily take away the rigths that a valid certificate brings with for a entity. consider a employee gets suspended for any reason, the company may not want to revoke the certificate before the reason for this suspension have been verified. and if the company finds out that the reason is unjustified, it may want to make the certificate valid again. during the period the employee is suspended, the company may not want him do any business. > If it becomes definetely revoked, you get a bad answer, > if the the current status is still 'pending', you get that. > And for those cases you get a date, so you can compare. > > It is assumed that either by using a cut-off date or by external knowledge > you know that for which time frame you get an answer. collecting facts from serveral sources to get an answer is what i want to avoid. i would like to have a single point where is get a definitive answer to the question stated above. by now i have to do serveral parts of this processing at the client side. i think the server side would be the better place for this. > If you want to have more detailed information about the history, you can > also require that the signer, a cosigner, a notary, or whoever you want, > produce an OCSP response near the moment of the signature and add > this to the document, or you other protocols to enable validity checking > of the document. if you sign a lot of documents and always attach all necessary verification data, you produce a lot of redundant information. this can be avoided and i think this should be avoided. nevertheless it works. > I am not talking about the effects of a CA key compromise that might allow > you to create 'good' responses for a non-existing cert, and then > you estimate > to be able to fake one in the future. i also do not consider a CA key compromise here. > > of course, implementing this based on CRLs will be hard, but if > the server > > has access to the history of the certificates, it should not be > a big deal. > > > > what do you and others think of this requirement for future OCSP > Some general thoughts: > > So far, OCSP without extensions has been made in such a way that you can > create a conforming implementation if you have a repository of CRLs. yes i know about this requirement for supporting CRLs. but this is a implementation issue. for me as a developer of a signature/verification terminal software my stated question is the one that i need an answer for. > As far as I remember all requests to give different answers are handled by > the magic 'do it by an extension'. OCSP adds an archive-cut off extension > for example, this seems to me a simple thing to support, knowing the > the history of the CRLs that you have isn't that difficult. just getting my idea in there in any non-standard extension is not a very disirable solution. because if i am the only one supporting it, it is not better than any ad-hoc protocol. i posted my idea here to hear the opinion of other people that use OCSP. regards Karl Scheibelhofer -- Karl Scheibelhofer, < mailto:Karl.Scheibelhofer@iaik.at > Institute for Applied Information Processing and Communications (IAIK) at Technical University of Graz, Austria, http://www.iaik.at Phone: (+43) (316) 873-5540 Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20494 for ; Thu, 31 Aug 2000 16:27:15 -0700 (PDT) Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 19:27:26 -0400 Message-ID: From: Khaja Ahmed To: "'Karl Scheibelhofer'" , Peter Sylvester , MMyers@verisign.com, ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification Date: Thu, 31 Aug 2000 19:27:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C013A3.054F5DB0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C013A3.054F5DB0 Content-Type: text/plain; charset="iso-8859-1" Under some circumstances or for some communities it may be possible for the sender of the signed data to send along with the signed data proof that at the time of signing (+/- some tolerance limit) the certificate was not revoked. In other words, the sender could get an ocsp response from a common trusted responder and include this with the transmission of the signed data. This approach offers the advantage that the response can be archived / stored along with the signature. At a later date when the archived / stored signed data and signature is retrieved it can be readily verified as having been valid at creation time (+/- tolerance limit). Is this not an ability that we should formalize and add to appropriate protocols like OCSP? Khaja -----Original Message----- From: Karl Scheibelhofer [mailto:Karl.Scheibelhofer@iaik.at] Sent: Thursday, August 31, 2000 6:26 AM To: Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification > -----Original Message----- > From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr] > Sent: Thursday, August 31, 2000 2:27 PM > To: MMyers@verisign.com; ietf-pkix@imc.org; Karl.Scheibelhofer@iaik.at > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > the current status of a certificate is very often not so > important. when i > > verify a signature that was created using a specific > certificate, i want to > > know, if the certificate was vaild, when the signature was created. to > > detemine the time the signature was created, one would ideally use > > timestamps. using timestamps, it is possible to determine the signature > > creation time to be in an intervall [t1,t2]. here t1 and t2 are > the times of > > two timestamp (taking time base errors into consideration). > > what i would like to see in OCSP is a request with the > following meaning: > > "what was the state of certificate XYZ in the time interval [t1,t2]?" > > I do not think that you really want to ask this question, see below. i do not simply want, in fact i must(!) have a answer to this question to decide whether the signature is valid. for me a certificate status service it is the most obvious place to get the answer for this question. > > the answers could be: > > 1) the state of certificate XYZ was A (e.g. valid, suspended, > revoked,...) > > throughout the time intervall [t1,t2] > > 3) certificate XYZ changed its state from state A (e.g. valid) > to state B > > (e.g. suspended) at tx, where t1 <= tx <= t2 > > > > if i get the first answer with 'valid', i can definitely say: > "the signature > > it was used for is valid". > > moreover, this request-response supports any history model for > certificate. > > by now OCSP assumes that a certificate can never become valid > again once it > > became invalid. > Hm, > > If a certificate was 'invalid' (suspended) and if it becomes > valid later, then > why would you want to get a 'suspended' status? simply to temporarily take away the rigths that a valid certificate brings with for a entity. consider a employee gets suspended for any reason, the company may not want to revoke the certificate before the reason for this suspension have been verified. and if the company finds out that the reason is unjustified, it may want to make the certificate valid again. during the period the employee is suspended, the company may not want him do any business. > If it becomes definetely revoked, you get a bad answer, > if the the current status is still 'pending', you get that. > And for those cases you get a date, so you can compare. > > It is assumed that either by using a cut-off date or by external knowledge > you know that for which time frame you get an answer. collecting facts from serveral sources to get an answer is what i want to avoid. i would like to have a single point where is get a definitive answer to the question stated above. by now i have to do serveral parts of this processing at the client side. i think the server side would be the better place for this. > If you want to have more detailed information about the history, you can > also require that the signer, a cosigner, a notary, or whoever you want, > produce an OCSP response near the moment of the signature and add > this to the document, or you other protocols to enable validity checking > of the document. if you sign a lot of documents and always attach all necessary verification data, you produce a lot of redundant information. this can be avoided and i think this should be avoided. nevertheless it works. > I am not talking about the effects of a CA key compromise that might allow > you to create 'good' responses for a non-existing cert, and then > you estimate > to be able to fake one in the future. i also do not consider a CA key compromise here. > > of course, implementing this based on CRLs will be hard, but if > the server > > has access to the history of the certificates, it should not be > a big deal. > > > > what do you and others think of this requirement for future OCSP > Some general thoughts: > > So far, OCSP without extensions has been made in such a way that you can > create a conforming implementation if you have a repository of CRLs. yes i know about this requirement for supporting CRLs. but this is a implementation issue. for me as a developer of a signature/verification terminal software my stated question is the one that i need an answer for. > As far as I remember all requests to give different answers are handled by > the magic 'do it by an extension'. OCSP adds an archive-cut off extension > for example, this seems to me a simple thing to support, knowing the > the history of the CRLs that you have isn't that difficult. just getting my idea in there in any non-standard extension is not a very disirable solution. because if i am the only one supporting it, it is not better than any ad-hoc protocol. i posted my idea here to hear the opinion of other people that use OCSP. regards Karl Scheibelhofer -- Karl Scheibelhofer, Institute for Applied Information Processing and Communications (IAIK) at Technical University of Graz, Austria, http://www.iaik.at Phone: (+43) (316) 873-5540 ------_=_NextPart_001_01C013A3.054F5DB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: RFC 2560 - OCSP - Clarification

Under some circumstances or for some communities it = may be possible for the sender of the signed data to send along with = the signed data proof that at the time of signing (+/- some tolerance = limit) the certificate was not revoked. In other words, the sender = could get an ocsp response from a common trusted responder and include = this with the transmission of the signed data.  This approach = offers the advantage that the response can be archived / stored along = with the signature.  At a later date when the archived / stored = signed data and signature is retrieved it can be readily verified as = having been valid at creation time (+/- tolerance limit).  =

Is this not an ability that we should formalize and = add to appropriate protocols like OCSP?

Khaja

-----Original Message-----
From: Karl Scheibelhofer [mailto:Karl.Scheibelhofer@iai= k.at]
Sent: Thursday, August 31, 2000 6:26 AM
To: Peter Sylvester; MMyers@verisign.com; = ietf-pkix@imc.org
Subject: RE: RFC 2560 - OCSP - Clarification




> -----Original Message-----
> From: Peter Sylvester [mailto:Peter.Sylvester@EdelWe= b.fr]
> Sent: Thursday, August 31, 2000 2:27 PM
> To: MMyers@verisign.com; ietf-pkix@imc.org; = Karl.Scheibelhofer@iaik.at
> Subject: RE: RFC 2560 - OCSP - = Clarification
>
>
> >
> > the current status of a certificate is = very often not so
> important. when i
> > verify a signature that was created using = a specific
> certificate, i want to
> > know, if the certificate was vaild, when = the signature was created. to
> > detemine the time the signature was = created, one would ideally use
> > timestamps. using timestamps, it is = possible to determine the signature
> > creation time to be in an intervall = [t1,t2]. here t1 and t2 are
> the times of
> > two timestamp (taking time base errors = into consideration).
> > what i would like to see in OCSP is a = request with the
> following meaning:
> > "what was the state of certificate = XYZ in the time interval [t1,t2]?"
>
> I do not think that you really want to ask this = question, see below.

i do not simply want, in fact i must(!) have a answer = to this question to
decide whether the signature is valid. for me a = certificate status service
it is the most obvious place to get the answer for = this question.

> > the answers could be:
> > 1) the state of certificate XYZ was A = (e.g. valid, suspended,
> revoked,...)
> > throughout the time intervall [t1,t2]
> > 3) certificate XYZ changed its state from = state A (e.g. valid)
> to state B
> > (e.g. suspended) at tx, where t1 <=3D = tx <=3D t2
> >
> > if i get the first answer with 'valid', i = can definitely say:
> "the signature
> > it was used for is valid".
> > moreover, this request-response supports = any history model for
> certificate.
> > by now OCSP assumes that a certificate can = never become valid
> again once it
> > became invalid.
> Hm,
>
> If a certificate was 'invalid' (suspended) and = if it becomes
> valid later, then
> why would you want to get a 'suspended' = status?

simply to temporarily take away the rigths that a = valid certificate brings
with for a entity. consider a employee gets = suspended for any reason, the
company may not want to revoke the certificate = before the reason for this
suspension have been verified. and if the company = finds out that the reason
is unjustified, it may want to make the certificate = valid again. during the
period the employee is suspended, the company may = not want him do any
business.

> If it becomes definetely revoked, you get a bad = answer,
> if the the current status is still 'pending', = you get that.
> And for those cases you get a date, so you can = compare.
>
> It is assumed that either by using a cut-off = date or by external knowledge
> you know that for which time frame you get an = answer.

collecting facts from serveral sources to get an = answer is what i want to
avoid. i would like to have a single point where is = get a definitive answer
to the question stated above. by now i have to do = serveral parts of this
processing at the client side. i think the server = side would be the better
place for this.

> If you want to have more detailed information = about the history, you can
> also require that the signer, a cosigner, a = notary, or whoever you want,
> produce an OCSP response near the moment of the = signature and add
> this to the document, or you other protocols to = enable validity checking
> of the document.

if you sign a lot of documents and always attach all = necessary verification
data, you produce a lot of redundant information. = this can be avoided and i
think this should be avoided.
nevertheless it works.

> I am not talking about the effects of a CA key = compromise that might allow
> you to create 'good' responses for a = non-existing cert, and then
> you estimate
> to be able to fake one in the future.

i also do not consider a CA key compromise = here.

> > of course, implementing this based on CRLs = will be hard, but if
> the server
> > has access to the history of the certificat= es, it should not be
> a big deal.
> >
> > what do you and others think of this = requirement for future OCSP
> Some general thoughts:
>
> So far, OCSP without extensions has been made = in such a way that you can
> create a conforming implementation if you have = a repository of CRLs.

yes i know about this requirement for supporting = CRLs. but this is a
implementation issue.
for me as a developer of a signature/verification = terminal software my
stated question is the one that i need an answer = for.

> As far as I remember all requests to give = different answers are handled by
> the magic 'do it by an extension'. OCSP adds an = archive-cut off extension
> for example, this seems to me a simple thing to = support, knowing the
> the history of the CRLs that you have isn't = that difficult.

just getting my idea in there in any non-standard = extension is not a very
disirable solution. because if i am the only one = supporting it, it is not
better than any ad-hoc protocol.
i posted my idea here to hear the opinion of other = people that use OCSP.

regards

  Karl Scheibelhofer

--

Karl Scheibelhofer, <mailto:Karl.Scheibelhofer@iai= k.at>
Institute for Applied Information Processing and = Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) (316) 873-5540

------_=_NextPart_001_01C013A3.054F5DB0-- Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16289 for ; Thu, 31 Aug 2000 13:07:29 -0700 (PDT) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 13:03:55 -0700 Message-ID: <69A40A314934D41190C70050DAD7F99063B5B8@MAIL> From: Mathew Butler To: "'Peter Sylvester'" , ambarish@valicert.com, simon.tardell@iD2tech.com Cc: Karl.Scheibelhofer@iaik.at, MMyers@verisign.com, ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification Date: Thu, 31 Aug 2000 13:03:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" I don't think "or later" should be appended. (My reasoning shows up in another message, sent 5 minutes or less before this one.) -Mat Butler -----Original Message----- From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr] Sent: Thursday, August 31, 2000 8:02 AM To: ambarish@valicert.com; simon.tardell@iD2tech.com Cc: Karl.Scheibelhofer@iaik.at; Peter.Sylvester@EdelWeb.fr; MMyers@verisign.com; ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification > > Collect me if I'm long, but archive cutoff only indicates whether the > revocation status of a certificate is "garbage collected" after the > expiration of the said certificate (or rather, guarantees that it won't be > until some other point in time). The responder will still only tell you > about the current status of the certificate. I.e. if the certificate was put > on hold and subsequently removed from CRL and is still not expired, you will > not be told. This seems right. > > Karl wants to wind back time and tell the responder: Use only the > information you had at this historical point in time, and answer from that. > This means to have a protocol that can support 'by the letter' the following spec: To meet this goal, the path validation process verifies, among other things, that a prospective certification path (a sequence of n certi- ficates) satisfies the following conditions: (i) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate x+1; (ii) certificate 1 is issued by the trust anchor; (iii) certificate n is the end entity certificate; and (iv) for all x in {1, ..., n}, the certificate was valid at the time in question. or whether the specification is an overkill and there should be added the two words 'or later' at the end ? Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16170 for ; Thu, 31 Aug 2000 13:06:18 -0700 (PDT) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 13:02:45 -0700 Message-ID: <69A40A314934D41190C70050DAD7F99063B5B7@MAIL> From: Mathew Butler To: "'Peter Sylvester'" , RMMyers@verisign.com, ietf-pkix@imc.org, Karl.Scheibelhofer@iaik.at Subject: RE: RFC 2560 - OCSP - Clarification Date: Thu, 31 Aug 2000 13:02:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Preparing a contract in advance, and committing to it in advance, are two separate problem domains. One is a necessary part of business; the other is fraught with legal problems. Better to not 'enforce' a particular 'legal worldview' on what is eventually going to be a globally-used protocol. (Attempting to exceed your authority to bind a corporation that you're suspended from is 'fraud' in the US, and probably other countries. The way it's usually handled, to rectify the situation if it got screwed up on paper, is to re-sign the document with the current date -- there's no reason why the same requirement not be extended to the digital world, possibly with a statement included with the new signature noting the reason for the re-signing, and a commitment to honor the agreement from the original signature date even though the original signature wasn't technically valid.) Regarding the "why allow a suspended certificate to make timestamps": How easy is it going to be to ensure that the timestamping software checks for certificate suspension via OCSP? [Yes, this is a security consideration.] Also, in the event a third-party timestamping service is used -- how is it going to be possible to ensure that the third-party timestamping service checks all arbitrary CA's and their OCSP responders for current validity of a certificate? Granted, I agree that this is "pandering to the lawyers"... but if we don't do this right, this protocol is eventually going to be challenged as a way to legally validate signatures. -Mat Butler --- Original Message --- The intial question is: "Is this document/contract/etc a valid one in my context of application etc?" A verifier can also simply ask some server (of the other company or a local company centralized server) "Is this signed document a valid one in this particular application context?" Depending on the answer, continue with the workflow this way or the other *AND* you might want to add the answer as a verifiable element to the 'dossier'. You have reduced the problem space to something that seems to be close to what OCSP could respond. --- Original Message --- The person cannot do any business during that time, since any verifier would fall on the suspended status DURING that time, and if something gets rectified later, where is the harm of having prepared a contract in advance? --- Original Message --- You don't have a signature/verification terminal. You are assuming a particular application context with a particular validity model of signatures/signed documents. Adding a little bit of 'feature' like "you may not sign during suspension" reminds me to many discussion at least 15 years ago of the kind 'if we just add a trustworthy message-id to mail, then ....'. (Sorry for the flame). But wouldn't the next question be for example: Well, in order to determine the validity of the signature, I have to know whether the signer has already used his quota of money for that certificate, or else ? How do you determine the time of the contract? Probably the signer had to add a time stamps? Why would you allow him to make time stamps during the time his signing cert is suspended? Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13693 for ; Thu, 31 Aug 2000 11:33:37 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id LAA06446 for ; Thu, 31 Aug 2000 11:35:18 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 11:33:44 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4F93F72@vhqpostal.verisign.com> From: Michael Myers To: ietf-pkix@imc.org Subject: OCSP support for historical reference to certificate suspension Date: Thu, 31 Aug 2000 11:33:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" All, This is the same dialog I had Denis on the list regarding a requirement for historical references. That ultimately led to the Archive Cutoff definition that appears in RFC 2560. The text reads: "An OCSP responder MAY choose to retain revocation information beyond a certificate's expiration. The date obtained by subtracting this retention interval value from the producedAt time in a response is defined as the certificate's "archive cutoff" date. OCSP-enabled applications would use an OCSP archive cutoff date to contribute to a proof that a digital signature was (or was not) reliable on the date it was produced even if the certificate needed to validate the signature has long since expired. . . . To illustrate, if a server is operated with a 7-year retention interval policy and status was produced at time t1 then the value for ArchiveCutoff in the response would be (t1 - 7 years)." That is, the historical accuracy of a validation of an expired certificate related to given digital signature is only reliable up to the archive cutoff date. This date is arbitrary. It could be seven years, thirty years or whatever local digital signature rules require. What is needed, and what Denis originally advocated for, was syntax in the request that enabled specification of a date field whose semantics were "was the cert valid at this date?" However, it is unwise to predicate OCSP historical references on the presumption of CRL-based suspension mechanisms given the lack of Internet-scale support of this mechanism. A database-centric approach is much more practical. Given the current work underway regarding 2560bis, I propose to include in the 2560bis work effort an optional "ValidAt" (or some such) field in the request syntax to accomodate this requirement. Comments, anyone? Mike > -----Original Message----- > From: Simon Tardell [mailto:simon.tardell@iD2tech.com] > Sent: Thursday, August 31, 2000 7:36 AM > To: 'Ambarish Malpani' > Cc: 'Karl Scheibelhofer'; Peter Sylvester; MMyers@verisign.com; > ietf-pkix@imc.org > Subject: RE: RFC 2560 - OCSP - Clarification > > > Collect me if I'm long, but archive cutoff only indicates whether the > revocation status of a certificate is "garbage collected" after the > expiration of the said certificate (or rather, guarantees > that it won't be > until some other point in time). The responder will still > only tell you > about the current status of the certificate. I.e. if the > certificate was put > on hold and subsequently removed from CRL and is still not > expired, you will > not be told. > > Karl wants to wind back time and tell the responder: Use only the > information you had at this historical point in time, and > answer from that. > > Simon. > > Simon Tardell, Software Architect, iD2 Technologies > voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 > simon.tardell@iD2tech.com, http://www.iD2tech.com > Securing the Internet economy > > > > > -----Original Message----- > > From: Ambarish Malpani [mailto:ambarish@valicert.com] > > Sent: den 31 augusti 2000 16:18 > > To: 'Karl Scheibelhofer'; Peter Sylvester; MMyers@verisign.com; > > ietf-pkix@imc.org > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > Hi Karl, > > The Archive-Cutoff extension is one that is defined in the > > OCSP spec - it would not be a non-standard extension just made up > > by you. > > > > Regards, > > Ambarish > > > > > --------------------------------------------------------------------- > > Ambarish Malpani > > Architect > 650.567.5457 > > ValiCert, Inc. > ambarish@valicert.com > > 339 N. Bernardo Ave. > http://www.valicert.com > > Mountain View, CA 94043 > > > > > > > -----Original Message----- > > > From: Karl Scheibelhofer [mailto:Karl.Scheibelhofer@iaik.at] > > > Sent: Thursday, August 31, 2000 6:26 AM > > > To: Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org > > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr] > > > > Sent: Thursday, August 31, 2000 2:27 PM > > > > To: MMyers@verisign.com; ietf-pkix@imc.org; > > > Karl.Scheibelhofer@iaik.at > > > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > > > > > > > > > > > the current status of a certificate is very often not so > > > > important. when i > > > > > verify a signature that was created using a specific > > > > certificate, i want to > > > > > know, if the certificate was vaild, when the signature > > > was created. to > > > > > detemine the time the signature was created, one would > > ideally use > > > > > timestamps. using timestamps, it is possible to determine > > > the signature > > > > > creation time to be in an intervall [t1,t2]. here t1 > and t2 are > > > > the times of > > > > > two timestamp (taking time base errors into consideration). > > > > > what i would like to see in OCSP is a request with the > > > > following meaning: > > > > > "what was the state of certificate XYZ in the time > > > interval [t1,t2]?" > > > > > > > > I do not think that you really want to ask this question, > > see below. > > > > > > i do not simply want, in fact i must(!) have a answer to this > > > question to > > > decide whether the signature is valid. for me a certificate > > > status service > > > it is the most obvious place to get the answer for this question. > > > > > > > > the answers could be: > > > > > 1) the state of certificate XYZ was A (e.g. valid, suspended, > > > > revoked,...) > > > > > throughout the time intervall [t1,t2] > > > > > 3) certificate XYZ changed its state from state A (e.g. valid) > > > > to state B > > > > > (e.g. suspended) at tx, where t1 <= tx <= t2 > > > > > > > > > > if i get the first answer with 'valid', i can definitely say: > > > > "the signature > > > > > it was used for is valid". > > > > > moreover, this request-response supports any history model for > > > > certificate. > > > > > by now OCSP assumes that a certificate can never become valid > > > > again once it > > > > > became invalid. > > > > Hm, > > > > > > > > If a certificate was 'invalid' (suspended) and if it becomes > > > > valid later, then > > > > why would you want to get a 'suspended' status? > > > > > > simply to temporarily take away the rigths that a valid > > > certificate brings > > > with for a entity. consider a employee gets suspended for any > > > reason, the > > > company may not want to revoke the certificate before the > > > reason for this > > > suspension have been verified. and if the company finds out > > > that the reason > > > is unjustified, it may want to make the certificate valid > > > again. during the > > > period the employee is suspended, the company may not want > > him do any > > > business. > > > > > > > If it becomes definetely revoked, you get a bad answer, > > > > if the the current status is still 'pending', you get that. > > > > And for those cases you get a date, so you can compare. > > > > > > > > It is assumed that either by using a cut-off date or by > > > external knowledge > > > > you know that for which time frame you get an answer. > > > > > > collecting facts from serveral sources to get an answer is > > > what i want to > > > avoid. i would like to have a single point where is get a > > > definitive answer > > > to the question stated above. by now i have to do serveral > > > parts of this > > > processing at the client side. i think the server side would > > > be the better > > > place for this. > > > > > > > If you want to have more detailed information about the > > > history, you can > > > > also require that the signer, a cosigner, a notary, or > > > whoever you want, > > > > produce an OCSP response near the moment of the > signature and add > > > > this to the document, or you other protocols to enable > > > validity checking > > > > of the document. > > > > > > if you sign a lot of documents and always attach all > > > necessary verification > > > data, you produce a lot of redundant information. this can be > > > avoided and i > > > think this should be avoided. > > > nevertheless it works. > > > > > > > I am not talking about the effects of a CA key compromise > > > that might allow > > > > you to create 'good' responses for a non-existing cert, and then > > > > you estimate > > > > to be able to fake one in the future. > > > > > > i also do not consider a CA key compromise here. > > > > > > > > of course, implementing this based on CRLs will be > hard, but if > > > > the server > > > > > has access to the history of the certificates, it > should not be > > > > a big deal. > > > > > > > > > > what do you and others think of this requirement for > future OCSP > > > > Some general thoughts: > > > > > > > > So far, OCSP without extensions has been made in such a way > > > that you can > > > > create a conforming implementation if you have a > > repository of CRLs. > > > > > > yes i know about this requirement for supporting CRLs. > but this is a > > > implementation issue. > > > for me as a developer of a signature/verification terminal > > software my > > > stated question is the one that i need an answer for. > > > > > > > As far as I remember all requests to give different answers > > > are handled by > > > > the magic 'do it by an extension'. OCSP adds an archive-cut > > > off extension > > > > for example, this seems to me a simple thing to support, > > knowing the > > > > the history of the CRLs that you have isn't that difficult. > > > > > > just getting my idea in there in any non-standard extension > > > is not a very > > > disirable solution. because if i am the only one supporting > > > it, it is not > > > better than any ad-hoc protocol. > > > i posted my idea here to hear the opinion of other people > > > that use OCSP. > > > > > > regards > > > > > > Karl Scheibelhofer > > > > > > -- > > > > > > Karl Scheibelhofer, > > > Institute for Applied Information Processing and > > Communications (IAIK) > > > at Technical University of Graz, Austria, http://www.iaik.at > > > Phone: (+43) (316) 873-5540 > > > > > > Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27555 for ; Thu, 31 Aug 2000 08:11:00 -0700 (PDT) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G0500K01WW6M8@ext-mail.valicert.com> for ietf-pkix@imc.org; Thu, 31 Aug 2000 08:12:06 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G0500K0ZWW6L4@ext-mail.valicert.com>; Thu, 31 Aug 2000 08:12:06 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 08:01:31 -0700 Content-return: allowed Date: Thu, 31 Aug 2000 08:01:22 -0700 From: Ambarish Malpani Subject: RE: RFC 2560 - OCSP - Clarification To: "'Simon Tardell'" , Ambarish Malpani Cc: "'Karl Scheibelhofer'" , Peter Sylvester , MMyers@verisign.com, ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE201B831BA@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sorry, I misread Karl's message. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Simon Tardell [mailto:simon.tardell@iD2tech.com] > Sent: Thursday, August 31, 2000 7:36 AM > To: 'Ambarish Malpani' > Cc: 'Karl Scheibelhofer'; Peter Sylvester; MMyers@verisign.com; > ietf-pkix@imc.org > Subject: RE: RFC 2560 - OCSP - Clarification > > > Collect me if I'm long, but archive cutoff only indicates whether the > revocation status of a certificate is "garbage collected" after the > expiration of the said certificate (or rather, guarantees > that it won't be > until some other point in time). The responder will still > only tell you > about the current status of the certificate. I.e. if the > certificate was put > on hold and subsequently removed from CRL and is still not > expired, you will > not be told. > > Karl wants to wind back time and tell the responder: Use only the > information you had at this historical point in time, and > answer from that. > > Simon. > > Simon Tardell, Software Architect, iD2 Technologies > voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 > simon.tardell@iD2tech.com, http://www.iD2tech.com > Securing the Internet economy > > > > > -----Original Message----- > > From: Ambarish Malpani [mailto:ambarish@valicert.com] > > Sent: den 31 augusti 2000 16:18 > > To: 'Karl Scheibelhofer'; Peter Sylvester; MMyers@verisign.com; > > ietf-pkix@imc.org > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > Hi Karl, > > The Archive-Cutoff extension is one that is defined in the > > OCSP spec - it would not be a non-standard extension just made up > > by you. > > > > Regards, > > Ambarish > > > > > --------------------------------------------------------------------- > > Ambarish Malpani > > Architect > 650.567.5457 > > ValiCert, Inc. > ambarish@valicert.com > > 339 N. Bernardo Ave. > http://www.valicert.com > > Mountain View, CA 94043 > > > > > > > -----Original Message----- > > > From: Karl Scheibelhofer [mailto:Karl.Scheibelhofer@iaik.at] > > > Sent: Thursday, August 31, 2000 6:26 AM > > > To: Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org > > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr] > > > > Sent: Thursday, August 31, 2000 2:27 PM > > > > To: MMyers@verisign.com; ietf-pkix@imc.org; > > > Karl.Scheibelhofer@iaik.at > > > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > > > > > > > > > > > the current status of a certificate is very often not so > > > > important. when i > > > > > verify a signature that was created using a specific > > > > certificate, i want to > > > > > know, if the certificate was vaild, when the signature > > > was created. to > > > > > detemine the time the signature was created, one would > > ideally use > > > > > timestamps. using timestamps, it is possible to determine > > > the signature > > > > > creation time to be in an intervall [t1,t2]. here t1 > and t2 are > > > > the times of > > > > > two timestamp (taking time base errors into consideration). > > > > > what i would like to see in OCSP is a request with the > > > > following meaning: > > > > > "what was the state of certificate XYZ in the time > > > interval [t1,t2]?" > > > > > > > > I do not think that you really want to ask this question, > > see below. > > > > > > i do not simply want, in fact i must(!) have a answer to this > > > question to > > > decide whether the signature is valid. for me a certificate > > > status service > > > it is the most obvious place to get the answer for this question. > > > > > > > > the answers could be: > > > > > 1) the state of certificate XYZ was A (e.g. valid, suspended, > > > > revoked,...) > > > > > throughout the time intervall [t1,t2] > > > > > 3) certificate XYZ changed its state from state A (e.g. valid) > > > > to state B > > > > > (e.g. suspended) at tx, where t1 <= tx <= t2 > > > > > > > > > > if i get the first answer with 'valid', i can definitely say: > > > > "the signature > > > > > it was used for is valid". > > > > > moreover, this request-response supports any history model for > > > > certificate. > > > > > by now OCSP assumes that a certificate can never become valid > > > > again once it > > > > > became invalid. > > > > Hm, > > > > > > > > If a certificate was 'invalid' (suspended) and if it becomes > > > > valid later, then > > > > why would you want to get a 'suspended' status? > > > > > > simply to temporarily take away the rigths that a valid > > > certificate brings > > > with for a entity. consider a employee gets suspended for any > > > reason, the > > > company may not want to revoke the certificate before the > > > reason for this > > > suspension have been verified. and if the company finds out > > > that the reason > > > is unjustified, it may want to make the certificate valid > > > again. during the > > > period the employee is suspended, the company may not want > > him do any > > > business. > > > > > > > If it becomes definetely revoked, you get a bad answer, > > > > if the the current status is still 'pending', you get that. > > > > And for those cases you get a date, so you can compare. > > > > > > > > It is assumed that either by using a cut-off date or by > > > external knowledge > > > > you know that for which time frame you get an answer. > > > > > > collecting facts from serveral sources to get an answer is > > > what i want to > > > avoid. i would like to have a single point where is get a > > > definitive answer > > > to the question stated above. by now i have to do serveral > > > parts of this > > > processing at the client side. i think the server side would > > > be the better > > > place for this. > > > > > > > If you want to have more detailed information about the > > > history, you can > > > > also require that the signer, a cosigner, a notary, or > > > whoever you want, > > > > produce an OCSP response near the moment of the > signature and add > > > > this to the document, or you other protocols to enable > > > validity checking > > > > of the document. > > > > > > if you sign a lot of documents and always attach all > > > necessary verification > > > data, you produce a lot of redundant information. this can be > > > avoided and i > > > think this should be avoided. > > > nevertheless it works. > > > > > > > I am not talking about the effects of a CA key compromise > > > that might allow > > > > you to create 'good' responses for a non-existing cert, and then > > > > you estimate > > > > to be able to fake one in the future. > > > > > > i also do not consider a CA key compromise here. > > > > > > > > of course, implementing this based on CRLs will be > hard, but if > > > > the server > > > > > has access to the history of the certificates, it > should not be > > > > a big deal. > > > > > > > > > > what do you and others think of this requirement for > future OCSP > > > > Some general thoughts: > > > > > > > > So far, OCSP without extensions has been made in such a way > > > that you can > > > > create a conforming implementation if you have a > > repository of CRLs. > > > > > > yes i know about this requirement for supporting CRLs. > but this is a > > > implementation issue. > > > for me as a developer of a signature/verification terminal > > software my > > > stated question is the one that i need an answer for. > > > > > > > As far as I remember all requests to give different answers > > > are handled by > > > > the magic 'do it by an extension'. OCSP adds an archive-cut > > > off extension > > > > for example, this seems to me a simple thing to support, > > knowing the > > > > the history of the CRLs that you have isn't that difficult. > > > > > > just getting my idea in there in any non-standard extension > > > is not a very > > > disirable solution. because if i am the only one supporting > > > it, it is not > > > better than any ad-hoc protocol. > > > i posted my idea here to hear the opinion of other people > > > that use OCSP. > > > > > > regards > > > > > > Karl Scheibelhofer > > > > > > -- > > > > > > Karl Scheibelhofer, > > > Institute for Applied Information Processing and > > Communications (IAIK) > > > at Technical University of Graz, Austria, http://www.iaik.at > > > Phone: (+43) (316) 873-5540 > > > > > > Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26992 for ; Thu, 31 Aug 2000 08:01:33 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA10749; Thu, 31 Aug 2000 17:01:57 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 31 Aug 2000 17:01:57 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA14441; Thu, 31 Aug 2000 17:01:55 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA12887; Thu, 31 Aug 2000 17:01:54 +0200 (MET DST) Date: Thu, 31 Aug 2000 17:01:54 +0200 (MET DST) Message-Id: <200008311501.RAA12887@emeriau.edelweb.fr> To: ambarish@valicert.com, simon.tardell@iD2tech.com Subject: RE: RFC 2560 - OCSP - Clarification Cc: Karl.Scheibelhofer@iaik.at, Peter.Sylvester@EdelWeb.fr, MMyers@verisign.com, ietf-pkix@imc.org > > Collect me if I'm long, but archive cutoff only indicates whether the > revocation status of a certificate is "garbage collected" after the > expiration of the said certificate (or rather, guarantees that it won't be > until some other point in time). The responder will still only tell you > about the current status of the certificate. I.e. if the certificate was put > on hold and subsequently removed from CRL and is still not expired, you will > not be told. This seems right. > > Karl wants to wind back time and tell the responder: Use only the > information you had at this historical point in time, and answer from that. > This means to have a protocol that can support 'by the letter' the following spec: To meet this goal, the path validation process verifies, among other things, that a prospective certification path (a sequence of n certi- ficates) satisfies the following conditions: (i) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate x+1; (ii) certificate 1 is issued by the trust anchor; (iii) certificate n is the end entity certificate; and (iv) for all x in {1, ..., n}, the certificate was valid at the time in question. or whether the specification is an overkill and there should be added the two words 'or later' at the end ? Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26558 for ; Thu, 31 Aug 2000 07:52:35 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA10634; Thu, 31 Aug 2000 16:53:08 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 31 Aug 2000 16:53:08 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA14414; Thu, 31 Aug 2000 16:53:07 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA12882; Thu, 31 Aug 2000 16:53:07 +0200 (MET DST) Date: Thu, 31 Aug 2000 16:53:07 +0200 (MET DST) Message-Id: <200008311453.QAA12882@emeriau.edelweb.fr> To: Peter.Sylvester@EdelWeb.fr, RMMyers@verisign.com, ietf-pkix@imc.org, Karl.Scheibelhofer@iaik.at Subject: RE: RFC 2560 - OCSP - Clarification > > > > > I do not think that you really want to ask this question, see below. > > i do not simply want, in fact i must(!) have a answer to this question to > decide whether the signature is valid. for me a certificate status service > it is the most obvious place to get the answer for this question. The intial question is: "Is this document/contract/etc a valid one in my context of application etc?" A verifier can also simply ask some server (of the other company or a local company centralized server) "Is this signed document a valid one in this particular application context?" Depending on the answer, continue with the workflow this way or the other *AND* you might want to add the answer as a verifiable element to the 'dossier'. You have reduced the problem space to something that seems to be close to what OCSP could respond. > > If a certificate was 'invalid' (suspended) and if it becomes > > valid later, then > > why would you want to get a 'suspended' status? > > simply to temporarily take away the rigths that a valid certificate brings > with for a entity. consider a employee gets suspended for any reason, the > company may not want to revoke the certificate before the reason for this > suspension have been verified. and if the company finds out that the reason > is unjustified, it may want to make the certificate valid again. during the > period the employee is suspended, the company may not want him do any > business. The person cannot do any business during that time, since any verifier would fall on the suspended status DURING that time, and if something gets rectified later, where is the harm of having prepared a contract in advance? > > > If it becomes definetely revoked, you get a bad answer, > > if the the current status is still 'pending', you get that. > > And for those cases you get a date, so you can compare. > > > > It is assumed that either by using a cut-off date or by external knowledge > > you know that for which time frame you get an answer. > > collecting facts from serveral sources to get an answer is what i want to > avoid. i would like to have a single point where is get a definitive answer > to the question stated above. by now i have to do serveral parts of this > processing at the client side. i think the server side would be the better > place for this. You don't collect answers from several sources, you determine the validity of the document by using some information that you get from one server. You already do local processing by validating the signatures, etc. Why do you start with the second step of validating the cert? you can also ask some server to validate the whole document. > > > If you want to have more detailed information about the history, you can > > also require that the signer, a cosigner, a notary, or whoever you want, > > produce an OCSP response near the moment of the signature and add > > this to the document, or you other protocols to enable validity checking > > of the document. > > if you sign a lot of documents and always attach all necessary verification > data, you produce a lot of redundant information. this can be avoided and i > think this should be avoided. In real life contracts in an enterprise you also add several signatures and other info, like for example you use the officiel forms for contracts of the company (a verifier knows that only authorised persons have access to that), or you add a date stamp of the company and verifiers know that this stamp can only be made if the contract had been reviewed, copied, archived, etc. And you sometimes need a second signature from a financial controller. > nevertheless it works. Where do you see the redundancy: Either the signer or the verifier have to determine 'current' status info, and carrying around a response during the workflow doesn't look a redundant to me. You could also argue that the document itself is redundant because a verifier could be asked to ask a server of potential document producer to deliver all contracts on line when you are ready. > > > I am not talking about the effects of a CA key compromise that might allow > > you to create 'good' responses for a non-existing cert, and then > > you estimate > > to be able to fake one in the future. > > i also do not consider a CA key compromise here. But this could break the whole model? > > > > So far, OCSP without extensions has been made in such a way that you can > > create a conforming implementation if you have a repository of CRLs. > > yes i know about this requirement for supporting CRLs. but this is a > implementation issue. This is a design decision of OCSP, the protocol is specified in such a way that support via CRL repositories are possible. > for me as a developer of a signature/verification terminal software my > stated question is the one that i need an answer for. You don't have a signature/verification terminal. You are assuming a particular application context with a particular validity model of signatures/signed documents. Adding a little bit of 'feature' like "you may not sign during suspension" reminds me to many discussion at least 15 years ago of the kind 'if we just add a trustworthy message-id to mail, then ....'. (Sorry for the flame). But wouldn't the next question be for example: Well, in order to determine the validity of the signature, I have to know whether the signer has already used his quota of money for that certificate, or else ? How do you determine the time of the contract? Probably the signer had to add a time stamps? Why would you allow him to make time stamps during the time his signing cert is suspended? > > > As far as I remember all requests to give different answers are handled by > > the magic 'do it by an extension'. OCSP adds an archive-cut off extension > > for example, this seems to me a simple thing to support, knowing the > > the history of the CRLs that you have isn't that difficult. > > just getting my idea in there in any non-standard extension is not a very > disirable solution. because if i am the only one supporting it, it is not > better than any ad-hoc protocol. Indeed. > i posted my idea here to hear the opinion of other people that use OCSP. You have at some opinion of someone who doesn't (any more). And I share your desire. Maybe you could simply rephrase your question by asking to what extent OCSP support path validation as in : To meet this goal, the path validation process verifies, among other things, that a prospective certification path (a sequence of n certi- ficates) satisfies the following conditions: (i) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate x+1; (ii) certificate 1 is issued by the trust anchor; (iii) certificate n is the end entity certificate; and (iv) for all x in {1, ..., n}, the certificate was valid at the XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX time in question. XXXXXXXXXXXXXXXXX Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA26168 for ; Thu, 31 Aug 2000 07:48:05 -0700 (PDT) Received: FROM aunt15.ausys.se BY naigwy ; Thu Aug 31 16:45:21 2000 +0200 Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 16:47:24 +0200 Message-ID: From: Simon Tardell To: "'ietf-pkix@imc.org'" Cc: "'Karl.Scheibelhofer@iaik.at'" , "'Peter.Sylvester@EdelWeb.fr'" , "'MMyers@verisign.com'" Subject: RE: RFC 2560 - OCSP - Clarification Date: Thu, 31 Aug 2000 16:47:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" I tend to agree with both of you. That is, both models are fairly valid. It is my opinion that we should provide standard semantics for supporting both models. The trouble I can see with answering historical questions of the type "what was the status of this certificate at time t (or in the interval [t1, t2])" is that there is no corresponding question to put to a CRL. CRLs are important because (and only because, IMHO) they are the mechanism we have to resynchronize the state of an OCSP responder with that of the internal state of a CA at the time of production of the CRL (which has to be done if the responder does not have access to the internal database of the CA and misses some CRL issued or so). They are also heavily abused as a certificate validation mechanism -- but this is a akin to having a POS terminal downloading the banks account database to be able to validate a credit card purchase. Now, to support the historical question the OCSP responder has to be able to retrieve the state of certificates issued by the CA during the CAs entire history (modulo some cutoff). This means that it will have to have all CRLs that the CA has issued (after that cutoff). That will be a lot of redundant information, and also a lot of processing to get started. A better way would be to have a way to serialize the entire revocation history of certificates from a CA. We could use the CRL form and allow a certificate to appear multiple times (is this actually disallowed?...), e.g. to have entries with revocation reason certificateHold followed by an entry with removeFromCrl _in the same CRL_ if the certificate was later unsuspended (obviously the history could be arbitrarily complicated: suspend, unsuspend, suspend, unsuspend, suspend, permanent). Apparently, used this way "removeFromCrl" becomes a misnomer and should perhaps be called something else. A CRL with these semantics should be marked with a critical extension to avoid confusion. Bottom line: I am in favour of Karl's extension, and I also argue for a similar extension to CRLs to support OCSP responders that are separate from the CA. Simon. Simon Tardell, Software Architect, iD2 Technologies voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 simon.tardell@iD2tech.com, http://www.iD2tech.com Securing the Internet economy > -----Original Message----- > From: Karl Scheibelhofer [mailto:Karl.Scheibelhofer@iaik.at] > Sent: den 31 augusti 2000 15:26 > To: Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > -----Original Message----- > > From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr] > > Sent: Thursday, August 31, 2000 2:27 PM > > To: MMyers@verisign.com; ietf-pkix@imc.org; > Karl.Scheibelhofer@iaik.at > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > > > the current status of a certificate is very often not so > > important. when i > > > verify a signature that was created using a specific > > certificate, i want to > > > know, if the certificate was vaild, when the signature > was created. to > > > detemine the time the signature was created, one would ideally use > > > timestamps. using timestamps, it is possible to determine > the signature > > > creation time to be in an intervall [t1,t2]. here t1 and t2 are > > the times of > > > two timestamp (taking time base errors into consideration). > > > what i would like to see in OCSP is a request with the > > following meaning: > > > "what was the state of certificate XYZ in the time > interval [t1,t2]?" > > > > I do not think that you really want to ask this question, see below. > > i do not simply want, in fact i must(!) have a answer to this > question to > decide whether the signature is valid. for me a certificate > status service > it is the most obvious place to get the answer for this question. > > > > the answers could be: > > > 1) the state of certificate XYZ was A (e.g. valid, suspended, > > revoked,...) > > > throughout the time intervall [t1,t2] > > > 3) certificate XYZ changed its state from state A (e.g. valid) > > to state B > > > (e.g. suspended) at tx, where t1 <= tx <= t2 > > > > > > if i get the first answer with 'valid', i can definitely say: > > "the signature > > > it was used for is valid". > > > moreover, this request-response supports any history model for > > certificate. > > > by now OCSP assumes that a certificate can never become valid > > again once it > > > became invalid. > > Hm, > > > > If a certificate was 'invalid' (suspended) and if it becomes > > valid later, then > > why would you want to get a 'suspended' status? > > simply to temporarily take away the rigths that a valid > certificate brings > with for a entity. consider a employee gets suspended for any > reason, the > company may not want to revoke the certificate before the > reason for this > suspension have been verified. and if the company finds out > that the reason > is unjustified, it may want to make the certificate valid > again. during the > period the employee is suspended, the company may not want him do any > business. > > > If it becomes definetely revoked, you get a bad answer, > > if the the current status is still 'pending', you get that. > > And for those cases you get a date, so you can compare. > > > > It is assumed that either by using a cut-off date or by > external knowledge > > you know that for which time frame you get an answer. > > collecting facts from serveral sources to get an answer is > what i want to > avoid. i would like to have a single point where is get a > definitive answer > to the question stated above. by now i have to do serveral > parts of this > processing at the client side. i think the server side would > be the better > place for this. > > > If you want to have more detailed information about the > history, you can > > also require that the signer, a cosigner, a notary, or > whoever you want, > > produce an OCSP response near the moment of the signature and add > > this to the document, or you other protocols to enable > validity checking > > of the document. > > if you sign a lot of documents and always attach all > necessary verification > data, you produce a lot of redundant information. this can be > avoided and i > think this should be avoided. > nevertheless it works. > > > I am not talking about the effects of a CA key compromise > that might allow > > you to create 'good' responses for a non-existing cert, and then > > you estimate > > to be able to fake one in the future. > > i also do not consider a CA key compromise here. > > > > of course, implementing this based on CRLs will be hard, but if > > the server > > > has access to the history of the certificates, it should not be > > a big deal. > > > > > > what do you and others think of this requirement for future OCSP > > Some general thoughts: > > > > So far, OCSP without extensions has been made in such a way > that you can > > create a conforming implementation if you have a repository of CRLs. > > yes i know about this requirement for supporting CRLs. but this is a > implementation issue. > for me as a developer of a signature/verification terminal software my > stated question is the one that i need an answer for. > > > As far as I remember all requests to give different answers > are handled by > > the magic 'do it by an extension'. OCSP adds an archive-cut > off extension > > for example, this seems to me a simple thing to support, knowing the > > the history of the CRLs that you have isn't that difficult. > > just getting my idea in there in any non-standard extension > is not a very > disirable solution. because if i am the only one supporting > it, it is not > better than any ad-hoc protocol. > i posted my idea here to hear the opinion of other people > that use OCSP. > > regards > > Karl Scheibelhofer > > -- > > Karl Scheibelhofer, > Institute for Applied Information Processing and Communications (IAIK) > at Technical University of Graz, Austria, http://www.iaik.at > Phone: (+43) (316) 873-5540 > Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA25232 for ; Thu, 31 Aug 2000 07:36:14 -0700 (PDT) Received: FROM aunt15.ausys.se BY naigwy ; Thu Aug 31 16:34:36 2000 +0200 Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 16:36:39 +0200 Message-ID: From: Simon Tardell To: "'Ambarish Malpani'" Cc: "'Karl Scheibelhofer'" , Peter Sylvester , MMyers@verisign.com, ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification Date: Thu, 31 Aug 2000 16:36:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Collect me if I'm long, but archive cutoff only indicates whether the revocation status of a certificate is "garbage collected" after the expiration of the said certificate (or rather, guarantees that it won't be until some other point in time). The responder will still only tell you about the current status of the certificate. I.e. if the certificate was put on hold and subsequently removed from CRL and is still not expired, you will not be told. Karl wants to wind back time and tell the responder: Use only the information you had at this historical point in time, and answer from that. Simon. Simon Tardell, Software Architect, iD2 Technologies voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 simon.tardell@iD2tech.com, http://www.iD2tech.com Securing the Internet economy > -----Original Message----- > From: Ambarish Malpani [mailto:ambarish@valicert.com] > Sent: den 31 augusti 2000 16:18 > To: 'Karl Scheibelhofer'; Peter Sylvester; MMyers@verisign.com; > ietf-pkix@imc.org > Subject: RE: RFC 2560 - OCSP - Clarification > > > > Hi Karl, > The Archive-Cutoff extension is one that is defined in the > OCSP spec - it would not be a non-standard extension just made up > by you. > > Regards, > Ambarish > > --------------------------------------------------------------------- > Ambarish Malpani > Architect 650.567.5457 > ValiCert, Inc. ambarish@valicert.com > 339 N. Bernardo Ave. http://www.valicert.com > Mountain View, CA 94043 > > > > -----Original Message----- > > From: Karl Scheibelhofer [mailto:Karl.Scheibelhofer@iaik.at] > > Sent: Thursday, August 31, 2000 6:26 AM > > To: Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > > > > -----Original Message----- > > > From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr] > > > Sent: Thursday, August 31, 2000 2:27 PM > > > To: MMyers@verisign.com; ietf-pkix@imc.org; > > Karl.Scheibelhofer@iaik.at > > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > > > > > > > the current status of a certificate is very often not so > > > important. when i > > > > verify a signature that was created using a specific > > > certificate, i want to > > > > know, if the certificate was vaild, when the signature > > was created. to > > > > detemine the time the signature was created, one would > ideally use > > > > timestamps. using timestamps, it is possible to determine > > the signature > > > > creation time to be in an intervall [t1,t2]. here t1 and t2 are > > > the times of > > > > two timestamp (taking time base errors into consideration). > > > > what i would like to see in OCSP is a request with the > > > following meaning: > > > > "what was the state of certificate XYZ in the time > > interval [t1,t2]?" > > > > > > I do not think that you really want to ask this question, > see below. > > > > i do not simply want, in fact i must(!) have a answer to this > > question to > > decide whether the signature is valid. for me a certificate > > status service > > it is the most obvious place to get the answer for this question. > > > > > > the answers could be: > > > > 1) the state of certificate XYZ was A (e.g. valid, suspended, > > > revoked,...) > > > > throughout the time intervall [t1,t2] > > > > 3) certificate XYZ changed its state from state A (e.g. valid) > > > to state B > > > > (e.g. suspended) at tx, where t1 <= tx <= t2 > > > > > > > > if i get the first answer with 'valid', i can definitely say: > > > "the signature > > > > it was used for is valid". > > > > moreover, this request-response supports any history model for > > > certificate. > > > > by now OCSP assumes that a certificate can never become valid > > > again once it > > > > became invalid. > > > Hm, > > > > > > If a certificate was 'invalid' (suspended) and if it becomes > > > valid later, then > > > why would you want to get a 'suspended' status? > > > > simply to temporarily take away the rigths that a valid > > certificate brings > > with for a entity. consider a employee gets suspended for any > > reason, the > > company may not want to revoke the certificate before the > > reason for this > > suspension have been verified. and if the company finds out > > that the reason > > is unjustified, it may want to make the certificate valid > > again. during the > > period the employee is suspended, the company may not want > him do any > > business. > > > > > If it becomes definetely revoked, you get a bad answer, > > > if the the current status is still 'pending', you get that. > > > And for those cases you get a date, so you can compare. > > > > > > It is assumed that either by using a cut-off date or by > > external knowledge > > > you know that for which time frame you get an answer. > > > > collecting facts from serveral sources to get an answer is > > what i want to > > avoid. i would like to have a single point where is get a > > definitive answer > > to the question stated above. by now i have to do serveral > > parts of this > > processing at the client side. i think the server side would > > be the better > > place for this. > > > > > If you want to have more detailed information about the > > history, you can > > > also require that the signer, a cosigner, a notary, or > > whoever you want, > > > produce an OCSP response near the moment of the signature and add > > > this to the document, or you other protocols to enable > > validity checking > > > of the document. > > > > if you sign a lot of documents and always attach all > > necessary verification > > data, you produce a lot of redundant information. this can be > > avoided and i > > think this should be avoided. > > nevertheless it works. > > > > > I am not talking about the effects of a CA key compromise > > that might allow > > > you to create 'good' responses for a non-existing cert, and then > > > you estimate > > > to be able to fake one in the future. > > > > i also do not consider a CA key compromise here. > > > > > > of course, implementing this based on CRLs will be hard, but if > > > the server > > > > has access to the history of the certificates, it should not be > > > a big deal. > > > > > > > > what do you and others think of this requirement for future OCSP > > > Some general thoughts: > > > > > > So far, OCSP without extensions has been made in such a way > > that you can > > > create a conforming implementation if you have a > repository of CRLs. > > > > yes i know about this requirement for supporting CRLs. but this is a > > implementation issue. > > for me as a developer of a signature/verification terminal > software my > > stated question is the one that i need an answer for. > > > > > As far as I remember all requests to give different answers > > are handled by > > > the magic 'do it by an extension'. OCSP adds an archive-cut > > off extension > > > for example, this seems to me a simple thing to support, > knowing the > > > the history of the CRLs that you have isn't that difficult. > > > > just getting my idea in there in any non-standard extension > > is not a very > > disirable solution. because if i am the only one supporting > > it, it is not > > better than any ad-hoc protocol. > > i posted my idea here to hear the opinion of other people > > that use OCSP. > > > > regards > > > > Karl Scheibelhofer > > > > -- > > > > Karl Scheibelhofer, > > Institute for Applied Information Processing and > Communications (IAIK) > > at Technical University of Graz, Austria, http://www.iaik.at > > Phone: (+43) (316) 873-5540 > > > Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24448 for ; Thu, 31 Aug 2000 07:27:33 -0700 (PDT) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G0500K01UVMDA@ext-mail.valicert.com> for ietf-pkix@imc.org; Thu, 31 Aug 2000 07:28:34 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G0500JJMUVLOZ@ext-mail.valicert.com>; Thu, 31 Aug 2000 07:28:34 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 07:17:59 -0700 Content-return: allowed Date: Thu, 31 Aug 2000 07:17:52 -0700 From: Ambarish Malpani Subject: RE: RFC 2560 - OCSP - Clarification To: "'Karl Scheibelhofer'" , Peter Sylvester , MMyers@verisign.com, ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE201B831B9@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Hi Karl, The Archive-Cutoff extension is one that is defined in the OCSP spec - it would not be a non-standard extension just made up by you. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Karl Scheibelhofer [mailto:Karl.Scheibelhofer@iaik.at] > Sent: Thursday, August 31, 2000 6:26 AM > To: Peter Sylvester; MMyers@verisign.com; ietf-pkix@imc.org > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > -----Original Message----- > > From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr] > > Sent: Thursday, August 31, 2000 2:27 PM > > To: MMyers@verisign.com; ietf-pkix@imc.org; > Karl.Scheibelhofer@iaik.at > > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > > > > > the current status of a certificate is very often not so > > important. when i > > > verify a signature that was created using a specific > > certificate, i want to > > > know, if the certificate was vaild, when the signature > was created. to > > > detemine the time the signature was created, one would ideally use > > > timestamps. using timestamps, it is possible to determine > the signature > > > creation time to be in an intervall [t1,t2]. here t1 and t2 are > > the times of > > > two timestamp (taking time base errors into consideration). > > > what i would like to see in OCSP is a request with the > > following meaning: > > > "what was the state of certificate XYZ in the time > interval [t1,t2]?" > > > > I do not think that you really want to ask this question, see below. > > i do not simply want, in fact i must(!) have a answer to this > question to > decide whether the signature is valid. for me a certificate > status service > it is the most obvious place to get the answer for this question. > > > > the answers could be: > > > 1) the state of certificate XYZ was A (e.g. valid, suspended, > > revoked,...) > > > throughout the time intervall [t1,t2] > > > 3) certificate XYZ changed its state from state A (e.g. valid) > > to state B > > > (e.g. suspended) at tx, where t1 <= tx <= t2 > > > > > > if i get the first answer with 'valid', i can definitely say: > > "the signature > > > it was used for is valid". > > > moreover, this request-response supports any history model for > > certificate. > > > by now OCSP assumes that a certificate can never become valid > > again once it > > > became invalid. > > Hm, > > > > If a certificate was 'invalid' (suspended) and if it becomes > > valid later, then > > why would you want to get a 'suspended' status? > > simply to temporarily take away the rigths that a valid > certificate brings > with for a entity. consider a employee gets suspended for any > reason, the > company may not want to revoke the certificate before the > reason for this > suspension have been verified. and if the company finds out > that the reason > is unjustified, it may want to make the certificate valid > again. during the > period the employee is suspended, the company may not want him do any > business. > > > If it becomes definetely revoked, you get a bad answer, > > if the the current status is still 'pending', you get that. > > And for those cases you get a date, so you can compare. > > > > It is assumed that either by using a cut-off date or by > external knowledge > > you know that for which time frame you get an answer. > > collecting facts from serveral sources to get an answer is > what i want to > avoid. i would like to have a single point where is get a > definitive answer > to the question stated above. by now i have to do serveral > parts of this > processing at the client side. i think the server side would > be the better > place for this. > > > If you want to have more detailed information about the > history, you can > > also require that the signer, a cosigner, a notary, or > whoever you want, > > produce an OCSP response near the moment of the signature and add > > this to the document, or you other protocols to enable > validity checking > > of the document. > > if you sign a lot of documents and always attach all > necessary verification > data, you produce a lot of redundant information. this can be > avoided and i > think this should be avoided. > nevertheless it works. > > > I am not talking about the effects of a CA key compromise > that might allow > > you to create 'good' responses for a non-existing cert, and then > > you estimate > > to be able to fake one in the future. > > i also do not consider a CA key compromise here. > > > > of course, implementing this based on CRLs will be hard, but if > > the server > > > has access to the history of the certificates, it should not be > > a big deal. > > > > > > what do you and others think of this requirement for future OCSP > > Some general thoughts: > > > > So far, OCSP without extensions has been made in such a way > that you can > > create a conforming implementation if you have a repository of CRLs. > > yes i know about this requirement for supporting CRLs. but this is a > implementation issue. > for me as a developer of a signature/verification terminal software my > stated question is the one that i need an answer for. > > > As far as I remember all requests to give different answers > are handled by > > the magic 'do it by an extension'. OCSP adds an archive-cut > off extension > > for example, this seems to me a simple thing to support, knowing the > > the history of the CRLs that you have isn't that difficult. > > just getting my idea in there in any non-standard extension > is not a very > disirable solution. because if i am the only one supporting > it, it is not > better than any ad-hoc protocol. > i posted my idea here to hear the opinion of other people > that use OCSP. > > regards > > Karl Scheibelhofer > > -- > > Karl Scheibelhofer, > Institute for Applied Information Processing and Communications (IAIK) > at Technical University of Graz, Austria, http://www.iaik.at > Phone: (+43) (316) 873-5540 > Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA20072 for ; Thu, 31 Aug 2000 06:26:07 -0700 (PDT) Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id AD3056601E4; Thu, 31 Aug 2000 15:27:12 +0200 Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0beta1 14/January/2000); Thu, 31 Aug 2000 15:26:11 +0100 From: "Karl Scheibelhofer" To: "Peter Sylvester" , , Subject: RE: RFC 2560 - OCSP - Clarification Date: Thu, 31 Aug 2000 15:26:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <200008311226.OAA12849@emeriau.edelweb.fr> > -----Original Message----- > From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr] > Sent: Thursday, August 31, 2000 2:27 PM > To: MMyers@verisign.com; ietf-pkix@imc.org; Karl.Scheibelhofer@iaik.at > Subject: RE: RFC 2560 - OCSP - Clarification > > > > > > the current status of a certificate is very often not so > important. when i > > verify a signature that was created using a specific > certificate, i want to > > know, if the certificate was vaild, when the signature was created. to > > detemine the time the signature was created, one would ideally use > > timestamps. using timestamps, it is possible to determine the signature > > creation time to be in an intervall [t1,t2]. here t1 and t2 are > the times of > > two timestamp (taking time base errors into consideration). > > what i would like to see in OCSP is a request with the > following meaning: > > "what was the state of certificate XYZ in the time interval [t1,t2]?" > > I do not think that you really want to ask this question, see below. i do not simply want, in fact i must(!) have a answer to this question to decide whether the signature is valid. for me a certificate status service it is the most obvious place to get the answer for this question. > > the answers could be: > > 1) the state of certificate XYZ was A (e.g. valid, suspended, > revoked,...) > > throughout the time intervall [t1,t2] > > 3) certificate XYZ changed its state from state A (e.g. valid) > to state B > > (e.g. suspended) at tx, where t1 <= tx <= t2 > > > > if i get the first answer with 'valid', i can definitely say: > "the signature > > it was used for is valid". > > moreover, this request-response supports any history model for > certificate. > > by now OCSP assumes that a certificate can never become valid > again once it > > became invalid. > Hm, > > If a certificate was 'invalid' (suspended) and if it becomes > valid later, then > why would you want to get a 'suspended' status? simply to temporarily take away the rigths that a valid certificate brings with for a entity. consider a employee gets suspended for any reason, the company may not want to revoke the certificate before the reason for this suspension have been verified. and if the company finds out that the reason is unjustified, it may want to make the certificate valid again. during the period the employee is suspended, the company may not want him do any business. > If it becomes definetely revoked, you get a bad answer, > if the the current status is still 'pending', you get that. > And for those cases you get a date, so you can compare. > > It is assumed that either by using a cut-off date or by external knowledge > you know that for which time frame you get an answer. collecting facts from serveral sources to get an answer is what i want to avoid. i would like to have a single point where is get a definitive answer to the question stated above. by now i have to do serveral parts of this processing at the client side. i think the server side would be the better place for this. > If you want to have more detailed information about the history, you can > also require that the signer, a cosigner, a notary, or whoever you want, > produce an OCSP response near the moment of the signature and add > this to the document, or you other protocols to enable validity checking > of the document. if you sign a lot of documents and always attach all necessary verification data, you produce a lot of redundant information. this can be avoided and i think this should be avoided. nevertheless it works. > I am not talking about the effects of a CA key compromise that might allow > you to create 'good' responses for a non-existing cert, and then > you estimate > to be able to fake one in the future. i also do not consider a CA key compromise here. > > of course, implementing this based on CRLs will be hard, but if > the server > > has access to the history of the certificates, it should not be > a big deal. > > > > what do you and others think of this requirement for future OCSP > Some general thoughts: > > So far, OCSP without extensions has been made in such a way that you can > create a conforming implementation if you have a repository of CRLs. yes i know about this requirement for supporting CRLs. but this is a implementation issue. for me as a developer of a signature/verification terminal software my stated question is the one that i need an answer for. > As far as I remember all requests to give different answers are handled by > the magic 'do it by an extension'. OCSP adds an archive-cut off extension > for example, this seems to me a simple thing to support, knowing the > the history of the CRLs that you have isn't that difficult. just getting my idea in there in any non-standard extension is not a very disirable solution. because if i am the only one supporting it, it is not better than any ad-hoc protocol. i posted my idea here to hear the opinion of other people that use OCSP. regards Karl Scheibelhofer -- Karl Scheibelhofer, Institute for Applied Information Processing and Communications (IAIK) at Technical University of Graz, Austria, http://www.iaik.at Phone: (+43) (316) 873-5540 Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA17365 for ; Thu, 31 Aug 2000 05:26:12 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA08335; Thu, 31 Aug 2000 14:26:44 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 31 Aug 2000 14:26:44 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id OAA13858; Thu, 31 Aug 2000 14:26:43 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA12849; Thu, 31 Aug 2000 14:26:42 +0200 (MET DST) Date: Thu, 31 Aug 2000 14:26:42 +0200 (MET DST) Message-Id: <200008311226.OAA12849@emeriau.edelweb.fr> To: MMyers@verisign.com, ietf-pkix@imc.org, Karl.Scheibelhofer@iaik.at Subject: RE: RFC 2560 - OCSP - Clarification > > the current status of a certificate is very often not so important. when i > verify a signature that was created using a specific certificate, i want to > know, if the certificate was vaild, when the signature was created. to > detemine the time the signature was created, one would ideally use > timestamps. using timestamps, it is possible to determine the signature > creation time to be in an intervall [t1,t2]. here t1 and t2 are the times of > two timestamp (taking time base errors into consideration). > what i would like to see in OCSP is a request with the following meaning: > "what was the state of certificate XYZ in the time interval [t1,t2]?" I do not think that you really want to ask this question, see below. > > the answers could be: > 1) the state of certificate XYZ was A (e.g. valid, suspended, revoked,...) > throughout the time intervall [t1,t2] > 3) certificate XYZ changed its state from state A (e.g. valid) to state B > (e.g. suspended) at tx, where t1 <= tx <= t2 > > if i get the first answer with 'valid', i can definitely say: "the signature > it was used for is valid". > moreover, this request-response supports any history model for certificate. > by now OCSP assumes that a certificate can never become valid again once it > became invalid. Hm, If a certificate was 'invalid' (suspended) and if it becomes valid later, then why would you want to get a 'suspended' status? If it becomes definetely revoked, you get a bad answer, if the the current status is still 'pending', you get that. And for those cases you get a date, so you can compare. It is assumed that either by using a cut-off date or by external knowledge you know that for which time frame you get an answer. If you want to have more detailed information about the history, you can also require that the signer, a cosigner, a notary, or whoever you want, produce an OCSP response near the moment of the signature and add this to the document, or you other protocols to enable validity checking of the document. I am not talking about the effects of a CA key compromise that might allow you to create 'good' responses for a non-existing cert, and then you estimate to be able to fake one in the future. > of course, implementing this based on CRLs will be hard, but if the server > has access to the history of the certificates, it should not be a big deal. > > what do you and others think of this requirement for future OCSP Some general thoughts: So far, OCSP without extensions has been made in such a way that you can create a conforming implementation if you have a repository of CRLs. As far as I remember all requests to give different answers are handled by the magic 'do it by an extension'. OCSP adds an archive-cut off extension for example, this seems to me a simple thing to support, knowing the the history of the CRLs that you have isn't that difficult. PS Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA29919 for ; Thu, 31 Aug 2000 01:24:06 -0700 (PDT) Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A66673301A6; Thu, 31 Aug 2000 10:25:10 +0200 Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0beta1 14/January/2000); Thu, 31 Aug 2000 10:24:10 +0100 From: "Karl Scheibelhofer" To: "Michael Myers" , "IETF PKIX Mailing List" Subject: RE: RFC 2560 - OCSP - Clarification Date: Thu, 31 Aug 2000 10:24:10 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4F93EE6@vhqpostal.verisign.com> Michael, > Abstract > "This document specifies a protocol useful in determining the > current status > of a digital certificate without requiring CRLs." > ^^^^^^^^^^^^^^^^^^^^^^ the current status of a certificate is very often not so important. when i verify a signature that was created using a specific certificate, i want to know, if the certificate was vaild, when the signature was created. to detemine the time the signature was created, one would ideally use timestamps. using timestamps, it is possible to determine the signature creation time to be in an intervall [t1,t2]. here t1 and t2 are the times of two timestamp (taking time base errors into consideration). what i would like to see in OCSP is a request with the following meaning: "what was the state of certificate XYZ in the time interval [t1,t2]?" the answers could be: 1) the state of certificate XYZ was A (e.g. valid, suspended, revoked,...) throughout the time intervall [t1,t2] 3) certificate XYZ changed its state from state A (e.g. valid) to state B (e.g. suspended) at tx, where t1 <= tx <= t2 if i get the first answer with 'valid', i can definitely say: "the signature it was used for is valid". moreover, this request-response supports any history model for certificate. by now OCSP assumes that a certificate can never become valid again once it became invalid. of course, implementing this based on CRLs will be hard, but if the server has access to the history of the certificates, it should not be a big deal. what do you and others think of this requirement for future OCSP regards Karl Scheibelhofer -- Karl Scheibelhofer, Institute for Applied Information Processing and Communications (IAIK) at Technical University of Graz, Austria, http://www.iaik.at Phone: (+43) (316) 873-5540 Received: from Newman.GSC.GTE.Com (SYSTEM@NS0.GDGSC.Com [192.160.62.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA23931 for ; Wed, 30 Aug 2000 16:43:17 -0700 (PDT) Received: from gscex01.gsc.gte.com ("port 2437"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #38015) with SMTP id <01JTLCRRX9SG003QSB@Newman.GSC.GTE.Com> for ietf-pkix@imc.org; Wed, 30 Aug 2000 19:44:10 -0400 (EDT) Received: from 127.0.0.1 by gscex01.gsc.gte.com (InterScan E-Mail VirusWall NT) ; Wed, 30 Aug 2000 19:44:09 -0400 (Eastern Daylight Time) Received: by GSCEX01.gsc.gte.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 19:44:09 -0400 Date: Wed, 30 Aug 2000 19:44:08 -0400 From: "Heimberg, Jim" Subject: RE: Matching Rules for Constructed Syntaxes To: "'steven.legg@adacel.com.au'" , ietf-ldapext@netscape.com, ietf-pkix@imc.org, osidirectory@az05.bull.com Message-id: <2575327B6755D211A0E100805F9FF9540508062D@ndhmex02.ndhm.gsc.gte.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="ISO-8859-1" Please change my address to jimhei@cablespeed.com. Thanks. -----Original Message----- From: Steven Legg [mailto:steven.legg@adacel.com.au] Sent: Tuesday, August 29, 2000 12:06 AM To: ietf-ldapext@netscape.com; ietf-pkix@imc.org; osidirectory@az05.bull.com Subject: RE: Matching Rules for Constructed Syntaxes Following some private email discussions with Tom Gindin I've decided on some changes to the way asn1Match, componentMatch and componentFilterMatch compare strings. The asn1Match rule isn't exactly a shorthand way of writing an "and" component filter because it doesn't compare character strings like any of the existing string matching rules. It compares two strings letter for letter, so letter case and all spaces are significant, but it also returns false if two compared DirectoryStrings use different alternatives in the DirectoryString CHOICE (which will only be visible in X.500). I think asn1Match will be more useful if it behaves just like caseIgnoreMatch when it is matching string type components. The assumed behaviour could be some other string matching rule, like caseExactMatch, or a purposely defined new string matching rule. In the absence of any request for an alternative I'll stick with caseIgnoreMatch. This change would make asn1Match somewhat different from its current implementation in the Adacel directory so I propose instead to define a new matching rule, which I'll call allComponentsMatch (unless someone has a better idea), with a new OID. The DirectoryString type is actually a CHOICE type (i.e. a constructed syntax) but I was deliberately treating it like a primitive string type in the examples of componentMatch and componentFilterMatch. Since it is fairly common practice to replace a specific ASN.1 string type that turns out to be too restrictive (e.g. PrintableString) with a CHOICE between the previous string type and a more general string type (e.g. UTF8String) I propose generalizing the special treatment for DirectoryString to any CHOICE of string types. Conceptually a string "component" has an ASN.1 type which is one of the primitive string types (e.g. PrintableString, IA5String) or a CHOICE of those string types (e.g. DirectoryString, PKCS9String). Nested CHOICEs would be permitted also. Regardless of the string type, I only intend that the string encoding of ComponentAssertion will use UTF8. The CHOICE construct would not normally be evident in the string encoding, though it would still be relevant to the BER encoding. To aid in the conversion between string encoding and BER encoding I'll provide some simple rules for deciding which alternative in a CHOICE of strings to assume, and a syntax for overriding the default rules to force a particular alternative. Regards, Steven Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20951 for ; Wed, 30 Aug 2000 13:54:39 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA12488; Wed, 30 Aug 2000 13:55:55 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 13:54:21 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4F93EE6@vhqpostal.verisign.com> From: Michael Myers To: Liaquat Khan , ietf-pkix@imc.org Subject: RE: RFC 2560 - OCSP - Clarification Date: Wed, 30 Aug 2000 13:54:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Liaquat, Thanks for taking a careful look at 2560 regarding CRLs. This thread will feed productively into 2560bis. But I do need to point out that OCSP does not, nor was ever intended, to require the use of CRLs. In fact, here are a few references from 2560 as currently written: Abstract "This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs." ^^^^^^^^^^^^^^^^^^^^^^ 2. Protocol Overview "OCSP may be used to satisfy some of the operational requirements of providing more timely revocation information than is possible with CRLs . . . ." ^^^^^^^^^^^^^^^^^^^^^^^^^^ Now, that said, 2560 does recognize that CRLs are a useful input to OCSP and so we made certain to accomodate that data source in the event that periodically produced CRLs were the ONLY means by which an OCSP service could be offered. We enabled the use of CRL extensions to accomodate environments where this feature was useful. But OCSP is and was primarly intended to address immediate timeliness, a feature that is inherently beyond the scope of periodically produced CRLs. 2560bis will clarify this intent. Mike > -----Original Message----- > From: Liaquat Khan [mailto:liaquat.khan@gta.multicert.org] > Sent: Wednesday, August 30, 2000 9:02 AM > To: ietf-pkix@imc.org > Subject: Re: RFC 2560 - OCSP - Clarification > > > The problem is linked to the fact that OCSP generally uses > CRLs as the base > information (although of course this doesn't have to be the > case). And CRLs > basically contain identifiers for those certificates that > have been revoked > (or suspended). Therefore, if a particular certificates > serial number is > not on a CRL, it maybe because it is still valid or maybe > because it was > never issued in the first place. > > Note that the OCSP standard makes a reference that extensions > should be used > for providing additional information. > > Regards, > Liaquat Khan > Technical Manager > Global Trust Authority > > > > ----- Original Message ----- > From: Mathew Butler > To: 'Rich Salz' ; Sam Schaen > ; > > Sent: Monday, August 28, 2000 9:13 PM > Subject: RE: RFC 2560 - OCSP - Clarification > > > > I think that there's a problem with this idea. If the > responder doesn't > > know about the CA, or have the ability to verify the CA's > signature on the > > certificate versus the CRL, the response should be > "unknown" rather than > > "good". > > > > "Good" should indicate: "The certificate was apparently > issued by a CA > that > > the responder has current revocation information for, and > the certificate > > has not been revoked." > > > > Forgive me for not reading the draft as thoroughly as I > should have; is > > there any call for the responder to cryptographically check the > certificate > > at any point during the request? > > > > -Mat Butler > > > > -----Original Message----- > > From: Rich Salz [mailto:rsalz@caveosystems.com] > > Sent: Monday, August 28, 2000 8:08 AM > > To: Sam Schaen > > Cc: 'ietf-pkix@imc.org' > > Subject: Re: RFC 2560 - OCSP - Clarification > > > > > > The text in uppercase is contradicted by the sentence that > immediately > > follows. If good doesn't mean the certificate was issued, > then there > > need not be a CA that issued it. :) > > > > > > > 'The "good" state indicates that THE RESPONDER HAS > CURRENT REVOCATION > > > INFORMATION FROM THE CA THAT ISSUED THE CERTIFICATE AND > the certificate > > has not > > > been revoked. It > > > does not indicate whether the certificate was ever > issued, is still > valid > > or > > > any other assertion. > > > Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09668 for ; Wed, 30 Aug 2000 08:58:20 -0700 (PDT) Received: from [195.99.45.237] (helo=vaio) by gadolinium.btinternet.com with smtp (Exim 3.03 #83) id 13UAGn-0006pe-00 for ietf-pkix@imc.org; Wed, 30 Aug 2000 16:59:21 +0100 Message-ID: <003b01c0129b$b379aae0$f13863c3@vaio> Reply-To: "Liaquat Khan" From: "Liaquat Khan" To: References: <69A40A314934D41190C70050DAD7F99063B59C@MAIL> Subject: Re: RFC 2560 - OCSP - Clarification Date: Wed, 30 Aug 2000 17:01:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 The problem is linked to the fact that OCSP generally uses CRLs as the base information (although of course this doesn't have to be the case). And CRLs basically contain identifiers for those certificates that have been revoked (or suspended). Therefore, if a particular certificates serial number is not on a CRL, it maybe because it is still valid or maybe because it was never issued in the first place. Note that the OCSP standard makes a reference that extensions should be used for providing additional information. Regards, Liaquat Khan Technical Manager Global Trust Authority ----- Original Message ----- From: Mathew Butler To: 'Rich Salz' ; Sam Schaen ; Sent: Monday, August 28, 2000 9:13 PM Subject: RE: RFC 2560 - OCSP - Clarification > I think that there's a problem with this idea. If the responder doesn't > know about the CA, or have the ability to verify the CA's signature on the > certificate versus the CRL, the response should be "unknown" rather than > "good". > > "Good" should indicate: "The certificate was apparently issued by a CA that > the responder has current revocation information for, and the certificate > has not been revoked." > > Forgive me for not reading the draft as thoroughly as I should have; is > there any call for the responder to cryptographically check the certificate > at any point during the request? > > -Mat Butler > > -----Original Message----- > From: Rich Salz [mailto:rsalz@caveosystems.com] > Sent: Monday, August 28, 2000 8:08 AM > To: Sam Schaen > Cc: 'ietf-pkix@imc.org' > Subject: Re: RFC 2560 - OCSP - Clarification > > > The text in uppercase is contradicted by the sentence that immediately > follows. If good doesn't mean the certificate was issued, then there > need not be a CA that issued it. :) > > > > 'The "good" state indicates that THE RESPONDER HAS CURRENT REVOCATION > > INFORMATION FROM THE CA THAT ISSUED THE CERTIFICATE AND the certificate > has not > > been revoked. It > > does not indicate whether the certificate was ever issued, is still valid > or > > any other assertion. > Received: from sendflowersamerica.com ([206.168.43.194]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA01618; Wed, 30 Aug 2000 01:00:01 -0700 (PDT) From: sfaquestions@sendflowersamerica.com Subject: FlowerFunds - Fund Raising Program Date: Wed, 30 Aug 2000 01:32:17 Message-Id: <620.108063.29555@sendflowersamerica.com> SendFlowersAmerica is proud to introduce FlowerFunds-- This unique new concept will provide an income flow for your organization for years to come. Your organization is invited to explore the possibilities of participating in FlowerFunds. $FlowerFunds is an individualized fund raising program for non-profit organizations and schools. $FlowerFunds are cash rebates that are paid to your organization each and every time an order is placed by your members and supporters. $The best part is that it costs your organization nothing to participate!! How it works: 1. When your members and supporters order flowers or gifts through sendflowersamerica they determine the price they want to pay; be it $30, $40, $50 or $1000. Since your members and supporters determine the price, they all can participate in this program. 2. Your organization receives 20% of the purchase price of the order. Say a husband buys his wife a $50 bouquet. Your organization will receive a $10 cash rebate. Nice. This program never ends. Each and every time there is an order placed by your memebers and supporters, your organization will receive the 20% cash rebate. That's a lot of FlowerFunds, and your organization stands to benefit from a findraiser unlike any other fundraiser. For more information call 1 800 SEND 123 or http://www.sendflowersamerica.com Imagine earning money for your organization by making someone smile :-) Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA22806 for ; Tue, 29 Aug 2000 22:47:54 -0700 (PDT) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G0300D01C5CXA@ext-mail.valicert.com> for ietf-pkix@imc.org; Tue, 29 Aug 2000 22:48:48 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G0300DLDC5CIB@ext-mail.valicert.com>; Tue, 29 Aug 2000 22:48:48 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Aug 2000 22:38:18 -0700 Content-return: allowed Date: Tue, 29 Aug 2000 22:38:08 -0700 From: Ambarish Malpani Subject: RE: A question about X.509 Extensions To: "'Sebastiano Di Paola'" , ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE201B831A1@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Hi Sebastiano, your analysis is correct (if I understood it correctly). To verify that we are both thinking the same thing, you could just look at the bytes in a standard certificate that has the extension you want (or some other extension). Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Sebastiano Di Paola [mailto:zio.moe@tin.it] > Sent: Tuesday, August 29, 2000 8:28 AM > To: ietf-pkix@imc.org > Subject: A question about X.509 Extensions > > > I have a question about X.509 Extension. > I would like to know how they are codified.. > What I mean is: > Extensions are defined as: > > Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension > > Extension ::= SEQUENCE { > extnID OBJECT IDENTIFIER, > critical BOOLEAN DEFAULT FALSE, > extnValue OCTET STRING } > > What I would like to know is: if I would like to put in a > X.509 Cert the > > Extension Authority Key > Identifier defined as: > > AuthorityKeyIdentifier ::= SEQUENCE { > keyIdentifier [0] KeyIdentifier OPTIONAL, > authorityCertIssuer [1] GeneralNames OPTIONAL, > authorityCertSerialNumber [2] CertificateSerialNumber > OPTIONAL } > > KeyIdentifier ::= OCTET STRING > > If I would like to include all of the fileds > (keyIdentifier,authorityCertIssuer ,authorityCertSerialNumber) > what I have to do to put the Extension in the llist > EXTENSIONS which has > > OctetString as extn value? > I mean do I have to Der Encode the structure > AuthorityKeyIdentifier and > then create an OctetString with the encoded data or what? > The same question can be made for CrlNumber Extension where I have an > int which > should be put into an octet string. > I hope you can help me. > Kind Regards > Marco > Received: from mail02-ewr.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA14353 for ; Tue, 29 Aug 2000 20:56:10 -0700 (PDT) From: Lynn.Wheeler@firstdata.com Received: from mailgw.firstdata.com ([204.48.27.156]) by mail02-ewr.pilot.net with ESMTP id XAA11289; Tue, 29 Aug 2000 23:57:10 -0400 (EDT) Received: from lnsunr02.firstdata.com (localhost [127.0.0.1]) by mailgw.firstdata.com with SMTP id XAA12612; Tue, 29 Aug 2000 23:57:08 -0400 (EDT) Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525694B.00152EF1 ; Tue, 29 Aug 2000 23:51:22 -0400 X-Lotus-FromDomain: FDC To: "David P. Kemp" cc: ietf-pkix@imc.org Message-ID: <8525694B.00152DF9.00@lnsunr02.firstdata.com> Date: Tue, 29 Aug 2000 20:52:43 -0700 Subject: Re: Client-side revocation checking capability Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline a relying party presumably executes some protocol initiation, signing validation, certificate validation, etc. after all that is done, the relying party can compare some "bound" information in the certificates with something that the relying party may be assuming and/or expects. If the relying party is expecting a specific business name ... they could check if the business name in the certificate matches the business name they are expecting. They might also have some expectation as to the due dilligence that the certification authority exercised in validating that information (for business names ... possibly checking with D&B). Now looking at possibly a trivial occurance of relying party checking ... maybe only a trivial 99.99999999999999% of all relying party "checking" currently going on ... it would appear that the most common occurance of a relying party checking something is a SSL relying party checking a domain name. 99.999999999999% of all such checking might not seem like a valid situation to consider. Now if the most common client-side validation of certificate information (only a trivial 99.9999999999999% of all such checks) involves domain name checking ... then clients might expect that certification authorities would be checking some authority that is involved in registering domain names. Now, it is possible that certification authorities might check with their local police station with regard to who has registered an internet domain name ... or they could check with D&B ... or they could check with all the agencies in the world which are explicitly not part of registering domain names. Frequently I've heard reference to one of the reasons for certificates in the SSL protocol is because of weaknesses in the domain name system ... which can be corrected by SSL domain certificates issued by certification authorities ... who may have check with the domain name registration authority as to the validity of the domain name (or on the other hand could have just checked with their local police station as to who owns a particular domain name). A minor issue if the domain name system is weak ... then it also is weak as an authority of certification authorities to check the information that they supposedly need to be correct (but which the domain name infrastructure can't be trusted to verify as correct????). So some of the proposals are to add public key registration to the domain name process. That makes it harder to hijack domain names and leads to a more trusted domain name system. Given a trusted domain name system with public keys, then the domain name system could return the public key (associated with a domain name) at the same time it returned the IP-address. However, if a trusted domain name system returned a public key as part of the domain name process, then having an SSL domain name certificate with a public key would seem to be superfulous and redundants (at least as far as the trivial SSL case under consideration). SSL certificates are somewhat a catch-22 ... some believe they exist because of untrusted DNS ... however the SSL certificate certification authorities would appear to be dependant on an untrusted domain name system as the authority for the domain name information that they place in SSL certificates ... creating a trusted DNS with the addition of public keys ... allows the real-time DNS domain name infrastructure to the real time authority of public keys for an SSL protocol as part of the standard domain name process. In this particular scenerio, SSL certificates would appear to be superfulous and redundant (aka it isn't necessary to have a certification authority manufactor a stale certificate with stale bound information ... when a trusted DNS is providing real-time information). That doesn't say that all certificates with public keys are redundant and superfulous ... just the apparent most common scenerio ... at least in terms of relying party/clients validating information ... possibly only a trivial 99.99999999999% of the cases (the SSL scenario). If the relying party isn't doing something on the internet and requires little or no IP services (including DNS) ... but still needs some authentication process, then certificates could address the opportunity. One could do SSL with an ip-address ... rather than a domain name ... and bypass the (real time) domain name system alltogether and rely on stale information in manufactored certificates. Hopefully the certification authority would be checking some internet ip-address authority (rather than the local police station). "David P. Kemp" on 08/28/2000 04:41:45 PM Please respond to "David P. Kemp" To: ietf-pkix@imc.org cc: (bcc: Lynn Wheeler/CA/FDMS/FDC) Subject: Re: Client-side revocation checking capability Reminds me of the blurb for a new fall TV series: Student: "You mean we should go online [to check the facts on a murder]?" Reporter: "No, I mean you should put on your socks and shoes and walk down to the police station." A CA doesn't have to resort to using DNS to validate the legitimacy of requests for certificates containing DNS names. In fact, there is no point in doing so - DNS maps names to IP addresses, certificates map names to public keys. Finding a DNS record, hijacked or not, doesn't give a CA any assurance that a public key belongs to the owner of the name. Certs-by-email are cute toys for users to play with, but any merchant using such a cert shouldn't get an "XYZ seal of approval" from any legitimate XYZ auditing organization. The value added by a CA who checks with D&B and WIPO before issuing a server cert is nearly orthogonal to the value added by secure DNS (at least until DNS administrators publish their CPSs). And even if the CA and the DNS used identical identity proofing procedures, independently-issued name-to-key and name-to-IP certificates provide additional assurance. Maybe overkill for some applications, but certainly not superfluous and redundant. Dave Received: from nxs_vyr_dns.sie.cl (IDENT:root@[206.48.156.90]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17759 for ; Tue, 29 Aug 2000 09:38:15 -0700 (PDT) Received: from JPEREZ ([206.48.156.91]) by nxs_vyr_dns.sie.cl (8.9.3/8.9.3) with SMTP id IAA07045 for ; Tue, 29 Aug 2000 08:44:08 -0400 Reply-To: From: =?iso-8859-1?Q?Juan_Carlos_P=E9rez_Aguayo?= To: "Ietf-Pkix" Subject: How to define a new Distinguished Name (DN) attribute ? Date: Tue, 29 Aug 2000 12:37:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Can I define a new DN attribute, for using in the Subject or Issuer of a certificate? By example, can I say this in the DN?: "O= My company, OU=My Dept. , XX=..., C=.." Can I say XX=.... ? Here XX mean my own attribute... I understand that the attribute names (as O , OU, DN ..) have OID assigned in a standarized fashion (X.208 ?), but I don`t know if I can assign my own OID for my private attribute (i.e XX). The DN attribute names are ONLY thoses standards(O, OU, C, ...) ? If I could register my own attribute name and OID, the browsers (o client-certificate validators) could validate those too ? Thanks Juan Carlos Received: from smtp4.libero.it (smtp4.libero.it [193.70.192.54]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12935 for ; Tue, 29 Aug 2000 08:26:56 -0700 (PDT) Received: from tin.it (151.25.244.163) by smtp4.libero.it; 29 Aug 2000 17:27:19 +0200 Sender: nello Message-ID: <39ABD661.1451F2A6@tin.it> Date: Tue, 29 Aug 2000 17:27:30 +0200 From: Sebastiano Di Paola X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: A question about X.509 Extensions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have a question about X.509 Extension. I would like to know how they are codified.. What I mean is: Extensions are defined as: Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING } What I would like to know is: if I would like to put in a X.509 Cert the Extension Authority Key Identifier defined as: AuthorityKeyIdentifier ::= SEQUENCE { keyIdentifier [0] KeyIdentifier OPTIONAL, authorityCertIssuer [1] GeneralNames OPTIONAL, authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } KeyIdentifier ::= OCTET STRING If I would like to include all of the fileds (keyIdentifier,authorityCertIssuer ,authorityCertSerialNumber) what I have to do to put the Extension in the llist EXTENSIONS which has OctetString as extn value? I mean do I have to Der Encode the structure AuthorityKeyIdentifier and then create an OctetString with the encoded data or what? The same question can be made for CrlNumber Extension where I have an int which should be put into an octet string. I hope you can help me. Kind Regards Marco Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA18250 for ; Mon, 28 Aug 2000 20:05:39 -0700 (PDT) Received: (qmail 7564 invoked from network); 29 Aug 2000 03:05:47 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 29 Aug 2000 03:05:47 -0000 Reply-To: From: "Steven Legg" To: , , Subject: RE: Matching Rules for Constructed Syntaxes Date: Tue, 29 Aug 2000 14:05:41 +1000 Message-ID: <000a01c0116e$65fa9690$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Following some private email discussions with Tom Gindin I've decided on some changes to the way asn1Match, componentMatch and componentFilterMatch compare strings. The asn1Match rule isn't exactly a shorthand way of writing an "and" component filter because it doesn't compare character strings like any of the existing string matching rules. It compares two strings letter for letter, so letter case and all spaces are significant, but it also returns false if two compared DirectoryStrings use different alternatives in the DirectoryString CHOICE (which will only be visible in X.500). I think asn1Match will be more useful if it behaves just like caseIgnoreMatch when it is matching string type components. The assumed behaviour could be some other string matching rule, like caseExactMatch, or a purposely defined new string matching rule. In the absence of any request for an alternative I'll stick with caseIgnoreMatch. This change would make asn1Match somewhat different from its current implementation in the Adacel directory so I propose instead to define a new matching rule, which I'll call allComponentsMatch (unless someone has a better idea), with a new OID. The DirectoryString type is actually a CHOICE type (i.e. a constructed syntax) but I was deliberately treating it like a primitive string type in the examples of componentMatch and componentFilterMatch. Since it is fairly common practice to replace a specific ASN.1 string type that turns out to be too restrictive (e.g. PrintableString) with a CHOICE between the previous string type and a more general string type (e.g. UTF8String) I propose generalizing the special treatment for DirectoryString to any CHOICE of string types. Conceptually a string "component" has an ASN.1 type which is one of the primitive string types (e.g. PrintableString, IA5String) or a CHOICE of those string types (e.g. DirectoryString, PKCS9String). Nested CHOICEs would be permitted also. Regardless of the string type, I only intend that the string encoding of ComponentAssertion will use UTF8. The CHOICE construct would not normally be evident in the string encoding, though it would still be relevant to the BER encoding. To aid in the conversion between string encoding and BER encoding I'll provide some simple rules for deciding which alternative in a CHOICE of strings to assume, and a syntax for overriding the default rules to force a particular alternative. Regards, Steven Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA00937 for ; Mon, 28 Aug 2000 16:46:04 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id TAA17470 for ; Mon, 28 Aug 2000 19:30:52 -0400 (EDT) Message-Id: <200008282330.TAA17466@roadblock.missi.ncsc.mil> Date: Mon, 28 Aug 2000 19:41:45 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Client-side revocation checking capability To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NVxPCloTUC+pGpfrJkj3CA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Reminds me of the blurb for a new fall TV series: Student: "You mean we should go online [to check the facts on a murder]?" Reporter: "No, I mean you should put on your socks and shoes and walk down to the police station." A CA doesn't have to resort to using DNS to validate the legitimacy of requests for certificates containing DNS names. In fact, there is no point in doing so - DNS maps names to IP addresses, certificates map names to public keys. Finding a DNS record, hijacked or not, doesn't give a CA any assurance that a public key belongs to the owner of the name. Certs-by-email are cute toys for users to play with, but any merchant using such a cert shouldn't get an "XYZ seal of approval" from any legitimate XYZ auditing organization. The value added by a CA who checks with D&B and WIPO before issuing a server cert is nearly orthogonal to the value added by secure DNS (at least until DNS administrators publish their CPSs). And even if the CA and the DNS used identical identity proofing procedures, independently-issued name-to-key and name-to-IP certificates provide additional assurance. Maybe overkill for some applications, but certainly not superfluous and redundant. Dave > From: Lynn.Wheeler@firstdata.com > Date: Wed, 16 Aug 2000 10:13:33 -0700 > > The side observation is there is a requirement for such a trusted DNS > infrastructure ... just to improve the integrity of existing server-side SSL > certificates (i.e. problem with hijacking host name and then obtaining a SSL > certificate since the certification authority has to resort to using the DNS > infrastructure as the authoritative entity for validating DNS information). But > addressing that requirement then also makes the need for such servier-side SSL > certificates superfulous and redundant. Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27529 for ; Mon, 28 Aug 2000 13:17:08 -0700 (PDT) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Mon, 28 Aug 2000 13:13:27 -0700 Message-ID: <69A40A314934D41190C70050DAD7F99063B59C@MAIL> From: Mathew Butler To: "'Rich Salz'" , Sam Schaen , "'ietf-pkix@imc.org'" Subject: RE: RFC 2560 - OCSP - Clarification Date: Mon, 28 Aug 2000 13:13:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" I think that there's a problem with this idea. If the responder doesn't know about the CA, or have the ability to verify the CA's signature on the certificate versus the CRL, the response should be "unknown" rather than "good". "Good" should indicate: "The certificate was apparently issued by a CA that the responder has current revocation information for, and the certificate has not been revoked." Forgive me for not reading the draft as thoroughly as I should have; is there any call for the responder to cryptographically check the certificate at any point during the request? -Mat Butler -----Original Message----- From: Rich Salz [mailto:rsalz@caveosystems.com] Sent: Monday, August 28, 2000 8:08 AM To: Sam Schaen Cc: 'ietf-pkix@imc.org' Subject: Re: RFC 2560 - OCSP - Clarification The text in uppercase is contradicted by the sentence that immediately follows. If good doesn't mean the certificate was issued, then there need not be a CA that issued it. :) > 'The "good" state indicates that THE RESPONDER HAS CURRENT REVOCATION > INFORMATION FROM THE CA THAT ISSUED THE CERTIFICATE AND the certificate has not > been revoked. It > does not indicate whether the certificate was ever issued, is still valid or > any other assertion. Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA26231 for ; Mon, 28 Aug 2000 12:05:55 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 09397480; Mon, 28 Aug 2000 15:06:33 -0400 (EDT) Sender: rsalz Message-ID: <39AAB846.B6A95B65@caveosystems.com> Date: Mon, 28 Aug 2000 15:06:46 -0400 From: Rich Salz X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ambarish Malpani CC: "'ietf-pkix@imc.org'" Subject: Re: RFC 2560 - OCSP - Clarification References: <27FF4FAEA8CDD211B97E00902745CBE201B830EF@seine.valicert.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 > The "revoked" state indicates that the certificate has been revoked(either > permanantly or temporarily (on hold)). I prefer something like The "revoked" state indicates that the certificate is revoked at the time the responder recevied the query. The revocation may be permanent, or temporary (i.e., on hold), and this state does not imply either condition. > The "unknown" state indicates that the responder does not know, or is > unwilling to tell, whether the certificate is revoked or not. A client may > be able to get a definitive response later, or at another responder. I'd like to add A responder SHOULD use an error response when possible to indicate unwillingness, rather than lack of information. Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24148 for ; Mon, 28 Aug 2000 10:01:41 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e7SGuCY09794 for ; Mon, 28 Aug 2000 09:56:12 -0700 (PDT) Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id G00HZE03.A0K; Mon, 28 Aug 2000 10:02:02 -0700 Message-ID: <39AA9AEF.DED595C4@netscape.com> Date: Mon, 28 Aug 2000 10:01:35 -0700 From: thayes@netscape.com (Terry Hayes) X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Rich Salz CC: Sam Schaen , "'ietf-pkix@imc.org'" Subject: Re: RFC 2560 - OCSP - Clarification References: <27FF4FAEA8CDD211B97E00902745CBE201B830EF@seine.valicert.com> <39A173CA.C9EF2071@mitre.org> <39AA8069.C07ABCF6@caveosystems.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF9B896A65F40D60462DD6ABD" This is a cryptographically signed message in MIME format. --------------msF9B896A65F40D60462DD6ABD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Well, I guess the first sentence should read: "... current revocation information from the CA that APPARENTLY issued the certificate". I believe this is what is intended. Terry Hayes thayes@netscape.com Rich Salz wrote: > The text in uppercase is contradicted by the sentence that immediately > follows. If good doesn't mean the certificate was issued, then there > need not be a CA that issued it. :) > > > 'The "good" state indicates that THE RESPONDER HAS CURRENT REVOCATION > > INFORMATION FROM THE CA THAT ISSUED THE CERTIFICATE AND the certificate has not > > been revoked. It > > does not indicate whether the certificate was ever issued, is still valid or > > any other assertion. --------------msF9B896A65F40D60462DD6ABD Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIhQYJKoZIhvcNAQcCoIIIdjCCCHICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlgwggMLMIICdKADAgECAgIbDjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA0MDMxODQxMzdaFw0wMDA5MzAxODQxMzda MIGBMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIjAg BgkqhkiG9w0BCQEWE3RoYXllc0BuZXRzY2FwZS5jb20xFDASBgNVBAMTC1RlcnJ5IEhheWVz MRYwFAYKCZImiZPyLGQBARMGdGhheWVzMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCw rDkkK9RaJwlVNF5TcYLpthJh4LHe3h0OCrSR6k6wXyrjd6KEoX2Q6afsu7GNAaOmcPJ6HMQq RPW+6noGzYYa63Q8pgyT7wsZepzgbArJ+2lKiV4ACYAcYcsJHuDbQFcbMsec9vUNofVvnwQv gu2GR2edFbon+4WLdcF/P0z7/wIDAQABo34wfDARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0P AQH/BAQDAgSwMB8GA1UdIwQYMBaAFKI7ZTL39xuJ/FUNBwG8h0ha/ZA9MDYGCCsGAQUFBwEB BCowKDAmBggrBgEFBQcwAYYaaHR0cDovL25zb2NzcC5uZXRzY2FwZS5jb20wDQYJKoZIhvcN AQEEBQADgYEAAiM7sfHY5qngjeKJZToTvAhDa/99M6h4Yi2p8v8/36ioCjfORg1PY8G/AHpp lrTu3JNtYBgzjUDpVAwVxgYyCgJ1GYzFFj27DkD5Saqg2P4baU8UPVf1rnAtXkRbri+tqwoK T8OWU7GWBfYGQI7s2EAetnlfl98JzcT7BQRJLCIwggNFMIICrqADAgECAgEnMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0 aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5j b20wHhcNOTkwNjAzMjIwMDM0WhcNMDEwNjAyMjIwMDM0WjCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA4u9f LHZDiUsaX7Pl+Kpviy+BTWf/vUoPYy7E3IX2nixJJiD/ABfkiIhp3v2DV+CjERkRqtbcvO+z 0hUuVMZufL/ZucNG0wkFhOVTXEjthIWaDjs9Fgdc8LN5q5oQpbzBpNF4TAblZEH8BSVjJuvv DMduVKGMzlRXth+S2rISS40CAwEAAaNpMGcwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUE FjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwEQYJYIZIAYb4QgEBBAQDAgECMB8GA1UdIwQYMBaA FHJJwnM0xlX0C3ZygX539IfnxrIOMA0GCSqGSIb3DQEBBAUAA4GBALpQffwAsv9BtAcIOQwh 9FlJFwjMjtPPDFbxb+gLGmli6waCW2msHYQnBjnJDn41E9B+wI+cWHwDMSyHENViO3DVDrFk gDROWfrGWeZG3k5oCHVA9R2MKdaud63JPWnkQI1El0ZvvnrAWKSxH2qnDylRioENKY6d5A8z C4+NJD3sMYIB9TCCAfECAQEwgZowgZMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQG A1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRkwFwYD VQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBB dXRob3JpdHkCAhsOMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMDAwODI4MTcwMTM3WjAjBgkqhkiG9w0BCQQxFgQUjKgWjh1Ntd4l RGl2dLWT0McwORUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEgYBOjh9TLLZbXOER9vuBL0W1AQYstoX4t/EYZVy2qA5JGM50Lwq2D//k07LExOYKI7Nl quxyO6KIImN4EiuJhaBiHi0m6aCsw/3OwecTnQ1ZTVccM16/Q8WDiWE8jYvr6xIz5ptxxoEQ nrPjICuH5T8VyTR9C7coMZ22jWRFsKHWCw== --------------msF9B896A65F40D60462DD6ABD-- Received: from c008.sfo.cp.net (c008-h012.c008.sfo.cp.net [209.228.14.201]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA23980 for ; Mon, 28 Aug 2000 09:51:03 -0700 (PDT) Received: (cpmta 12908 invoked from network); 28 Aug 2000 09:51:22 -0700 Date: 28 Aug 2000 09:51:22 -0700 Message-ID: <20000828165122.12907.cpmta@c008.sfo.cp.net> X-Sent: 28 Aug 2000 16:51:22 GMT Received: from [24.4.252.3] by mail.cogence-inc.com with HTTP; 28 Aug 2000 09:51:22 PDT Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: ietf-pkix@imc.org From: "Rosemary A.Walsh" X-Mailer: Web Mail 3.7.1.4 Subject: unsubscribe unsubscribe Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA16826 for ; Mon, 28 Aug 2000 08:07:50 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 09336512; Mon, 28 Aug 2000 11:08:13 -0400 (EDT) Sender: rsalz Message-ID: <39AA8069.C07ABCF6@caveosystems.com> Date: Mon, 28 Aug 2000 11:08:25 -0400 From: Rich Salz X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Sam Schaen CC: "'ietf-pkix@imc.org'" Subject: Re: RFC 2560 - OCSP - Clarification References: <27FF4FAEA8CDD211B97E00902745CBE201B830EF@seine.valicert.com> <39A173CA.C9EF2071@mitre.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 The text in uppercase is contradicted by the sentence that immediately follows. If good doesn't mean the certificate was issued, then there need not be a CA that issued it. :) > 'The "good" state indicates that THE RESPONDER HAS CURRENT REVOCATION > INFORMATION FROM THE CA THAT ISSUED THE CERTIFICATE AND the certificate has not > been revoked. It > does not indicate whether the certificate was ever issued, is still valid or > any other assertion. Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16016 for ; Mon, 28 Aug 2000 07:38:49 -0700 (PDT) Received: from dwc-acer ([62.252.106.112]) by mta01-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20000828143939.QQRU26680.mta01-svc.ntlworld.com@dwc-acer>; Mon, 28 Aug 2000 15:39:39 +0100 From: "David Chadwick" Organization: University of Salford To: "Steven Legg" Date: Mon, 28 Aug 2000 15:38:48 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Matching Rules for Constructed Syntaxes Reply-to: d.w.chadwick@salford.ac.uk CC: , Message-ID: <39AA8788.22408.4D82210@localhost> Priority: normal In-reply-to: <000301c0109b$d9bf6bb0$b05508cb@osmium.adacel.com.au> X-mailer: Pegasus Mail for Win32 (v3.12c) Steven Being an editor of a current ID on LDAP schema and matching rules for PKIX, I find your approach very appealing. Having to write potentially dozens of new matching rules for certs and CRLs, that all do very similar things, a generic way of describing this has significant benefits from a documentation point of view. I am certainly prepared to use your work in the PKIX schema ID, if there is general approval for it to procede. I also think the work should be part of LDAPExt as we need this type of matching rule to be core to LDAP implementations, and not application specific. In this way many applications can benefit from the technology provided by a central LDAP server. David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15059 for ; Mon, 28 Aug 2000 07:00:10 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09258; Mon, 28 Aug 2000 10:00:59 -0400 (EDT) Message-Id: <200008281400.KAA09258@ietf.org> To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: The IESG SUBJECT: Last Call: Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP) to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 28 Aug 2000 10:00:59 -0400 Sender: scoya@cnri.reston.va.us The IESG has received a request from the Public-Key Infrastructure (X.509) Working Group to consider Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by September 8, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-09.txt Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA03173 for ; Sun, 27 Aug 2000 22:40:23 -0700 (PDT) Received: (qmail 19681 invoked from network); 28 Aug 2000 06:41:17 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 28 Aug 2000 06:41:17 -0000 Reply-To: From: "Steven Legg" To: , Subject: RE: Matching Rules for Constructed Syntaxes Date: Mon, 28 Aug 2000 16:40:19 +1000 Message-ID: <000801c010ba$d64288e0$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-reply-to: <000301c0109b$d9bf6bb0$b05508cb@osmium.adacel.com.au> Oops! I misread the ASN.1 for LdapACI. This: > (ldapACI:componentMatch:={ > component "subject.dn", > rule distinguishedNameMatch, > value "cn=Steven Legg, o=Adacel, c=au" }) should read: (ldapACI:componentMatch:={ component "subject.subject.dn", rule distinguishedNameMatch, value "cn=Steven Legg, o=Adacel, c=au" }) and this: > (ldapACI:componentMatch:= > { component "subject.dn.*", rule rdnMatch, value "o=Adacel" }) should read: (ldapACI:componentMatch:={ component "subject.subject.dn.*", rule rdnMatch, value "o=Adacel" }) Cheers, Steven Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA21590 for ; Sun, 27 Aug 2000 18:58:40 -0700 (PDT) Received: (qmail 31425 invoked from network); 28 Aug 2000 02:59:25 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 28 Aug 2000 02:59:25 -0000 Reply-To: From: "Steven Legg" To: , Subject: Matching Rules for Constructed Syntaxes Date: Mon, 28 Aug 2000 12:58:31 +1000 Message-ID: <000301c0109b$d9bf6bb0$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal LDAPers and PKIXers, The LDAP ACI model and PKIX both have to deal with attribute syntaxes that are complex constructed types. Matching rules for those syntaxes have recently been discussion topics so it seems like a good time to describe some ideas for matching rules that have been kicking around in the back of my head for a while. First I'll address the question of an equality matching rule for ldapACI and then go on to describe some generic matching rules for complex syntaxes that would be useful to both LDAP access control and PKIX, among other things. One approach for ldapACI is the X.500 solution where a DirectoryString label has been made a component of the ACI and the directoryStringFirstComponentMatch matching rule is used to decide the equality of two ACIs. This satisfies some basic requirements to be able to match ACIs but the equality of two ACI values doesn't really say anything about them at the semantic level. Back when I was with Telstra we defined a catch-all equality matching rule that could do a comparison of two attribute values of any arbitrary ASN.1 syntax. This rule, or something like it, could be used as the equality matching rule for the ldapACI attribute. The X.500 style definition is simply this: asn1Match MATCHING-RULE ::= { ID { 1 3 32 0 1 13 0 } } Since no assertion syntax is specified, the syntax is inherited at run time from the attribute type to which the matching rule is applied. So the assertion syntax would be LdapACI if asn1Match is used to match against the ldapACI attribute. I have a slight problem defining this matching rule in LDAP terms because the string encoding for MatchingRuleDescription doesn't allow an absent SYNTAX. This matching rule evaluates to true if and only if the attribute value and the assertion value have the same components with the same values. If the syntax is a SEQUENCE or SET type then each component in the assertion value must match each component of the attribute value. Optional components must be either both present or both absent. If the syntax is a SEQUENCE OF then the attribute value and the assertion value must have the same instances (members) in the same order. If the syntax is a SET OF then the attribute value and the assertion value must have the same instances (and the same duplicates), but order doesn't matter. If the syntax is a CHOICE then the attribute value and the assertion value must use the same CHOICE alternative. The rules apply recursively to nested constructed types. The primitive types like OBJECT IDENTIFIER, BOOLEAN, INTEGER, etc match as one would expect. The string types are just matched character for character. The asn1Match rule would be fine as the equality matching rule for the ldapACI attribute and would have much the same effect as was intended by the original use of caseIgnoreMatch and DirectoryString syntax. However, where there is a complex constructed syntax there is usually a desire to selectively match only some of the components, e.g. to match ACIs with a specific subject, or with specific rights. What usually happens is that a bunch of new matching rules are defined to cover the anticipated needs. Just look at X.509 and PKI for examples. Rather than going down this path I would like to suggest a generic way of selectively matching components in arbitrary syntaxes. The following matching rule is something I've often thought about implementing but haven't as yet. componentMatch MATCHING-RULE ::= { SYNTAX ComponentAssertion ID } ComponentAssertion ::= SEQUENCE { component [0] PrintableString, rule [1] MATCHING-RULE.&id, -- MatchingRuleId value [2] MATCHING-RULE.&AssertionType -- AssertionValue } The idea here is that the component field identifies which part of a value of a constructed syntax is to be matched, the rule indicates how that part is to be matched, and the value is what that part is matched against. X.680, section 12 already describes a way to reference the components of an arbitrary ASN.1 type but it hasn't got a BER encoding so I'm just stuffing it as text into a PrintableString. Basically the component referencing string is a series of "." separated componentIds where a componentId is usually the ASN.1 identifier for the component. The componentId can also be a positive number to reference a particular instance in a SET OF or SEQUENCE OF, "*" to reference all the instances in a SET OF or SEQUENCE OF, or the number zero, which is a conceptual count of the number of instances. An example should make this clearer. First, here is the ASN.1 definition of the syntax of the objectClasses schema attribute (not to be confused with the objectClass attribute), so that I have something reasonably familiar to base examples on. ObjectClassDescription ::= SEQUENCE { identifier OBJECT-CLASS.&id, name SET OF DirectoryString { ub-schema } OPTIONAL, description DirectoryString { ub-schema } OPTIONAL, obsolete BOOLEAN DEFAULT FALSE, information [0] ObjectClassInformation } ObjectClassInformation ::= SEQUENCE { subclassOf SET OF OBJECT-CLASS.&id OPTIONAL, kind ObjectClassKind DEFAULT structural, mandatories [3] SET OF ATTRIBUTE.&id OPTIONAL, optionals [4] SET OF ATTRIBUTE.&id OPTIONAL } OBJECT-CLASS.&id and ATTRIBUTE.&id are equivalent to the OBJECT IDENTIFIER ASN.1 type. So for a given value with the ObjectClassDescription syntax (i.e. a value of the objectClasses attribute) ... "identifier" references the OID of the object class description, "description" references the text description of the object class, "name.*" references all of the object class's names, "name.0" gives the number of names defined for the object class, "name.1" references the first of those names, "information" references the whole ObjectClassInformation nested SEQUENCE, "information.kind" references the ObjectClassKind in the nested SEQUENCE, "information.mandatories.*" references all the mandatory attribute types for the object class ... and so on. Each referenced component has a specific ASN.1 type. For example, "identifier" is of type OBJECT IDENTIFIER and "name.1" is of type DirectoryString. The type of "information.mandatories" is SET OF OBJECT IDENTIFIER but the corresponding type for "information.mandatories.*" I'll take to be OBJECT IDENTIFIER (the instance type of the SET OF). The ".0" instance counts I'll assume to be INTEGER. Now that I've got a way to reference components I need to say how they are matched. I could specify a new bunch of rules for different kinds of matching on different ASN.1 types but it is convenient to just use existing attribute matching rules. Each matching rule has a notional set of attribute syntaxes (typically one), defined as ASN.1 types, to which it may be applied. When embedded in a ComponentAssertion these matching rules apply to the same ASN.1 types, only in this context the types aren't necessarily attribute syntaxes. So the "identifier" component of an objectClasses attribute value could be matched with objectIdentifierMatch. The "name.*" component (instances) could be matched with caseIgnoreMatch, caseExactMatch, caseIgnoreOrderingMatch, or even caseIgnoreSubstringMatch. Any component, regardless of its ASN.1 type could be matched by the asn1Match rule. The assertion value that goes with the chosen matching rule will be of the syntax required by that rule. Because constructed types can have CHOICEs and OPTIONAL fields it is possible that the referenced component does not exist in an attribute value. In these cases the matching rule would evaluate to false. Now for a few example filters using the componentMatch matching rule. I don't want to go to the trouble of defining complete ABNF right now so I'm using a string encoding that is a mix of ASN.1 value notation, which I trust is verbose enough to be sufficiently clear, and LDAP string encodings for well known ASN.1 types. I've put in spacing and line breaks only as an aid to readability. The example search filters are mostly single extensible match filter items, though of course there is no reason why componentMatch can't be used in more complicated search filters. To find the object class definition for the object class called foobar use the filter: (objectClasses:componentMatch:={ component "names.*", rule caseIgnoreMatch, value "foobar" }) An object class definition can have multiple names and the above filter will match an objectClasses value if any one of the names is "foobar". To find all obsolete object classes use: (objectClasses:componentMatch:={ component "obsolete", rule booleanMatch, value TRUE }) To find all subclasses of "person" use: (objectClasses:componentMatch:={ component "information.subclassOf.*", rule objectIdentifierMatch, value person }) To find the object class definition for 2.5.6.18 use: (objectClasses:componentMatch:={ component "identifier", rule objectIdentifierMatch, value 2.5.6.18 }) A match on the "identifier" component of objectClasses values is equivalent to the objectIdentifierFirstComponentMatch matching rule applied to this attribute type. The componentMatch matching rule subsumes the objectIdentifierFirstComponentMatch, integerFirstComponentMatch and directoryStringFirstComponentMatch matching rules. To find all values of the ldapACI attribute that have my DN in the subject field I could use (refer to draft-ietf-ldapext-acl-model-06.txt for the ASN.1 type definition of the ldapACI syntax): (ldapACI:componentMatch:={ component "subject.dn", rule distinguishedNameMatch, value "cn=Steven Legg, o=Adacel, c=au" }) The subject component is a CHOICE of which "dn" is one of several possibilities. Those values with a different choice won't match the filter item. To find all ACIs that apply to the commonName attribute: (ldapACI:componentMatch:= { component "attr.attributes.*", rule objectIdentifierMatch, value cn }) The componentMatch rule allows any one component in a constructed value to be matched but there are often good reasons to want to match more than one component in the same constructed value. This is particularly true for the matching of certificates and related constructs in PKIX. Most, if not all, of the desired functionality could be achieved with the following matching rule whose assertion syntax is a filter of component matches. componentFilterMatch MATCHING-RULE ::= { SYNTAX ComponentFilter ID } ComponentFilter ::= CHOICE { item [0] ComponentAssertion, and [1] SEQUENCE OF ComponentFilter, or [2] SEQUENCE OF ComponentFilter, not [3] ComponentFilter } The component filter is evaluated over a single attribute value rather than a whole entry. Note that a matching rule like this gives us the same capability for matching components of a constructed syntax that a regular search filter would give us had the constructed syntax been exploded out as a set of attributes of simpler syntaxes in a subordinate entry. The observant will notice that componentMatch is a special case of componentFilterMatch so we don't really need componentMatch. Here are some example search filters using the componentFilterMatch matching rule. To find all object class definitions that reference the commonName AND surname attributes as mandatory attributes use: (objectClasses:componentFilterMatch:=and:{ item:{ component "information.mandatories.*", rule objectIdentifierMatch, value cn }, item:{ component "information.mandatories.*", rule objectIdentifierMatch, value sn } }) To find all object class definitions that reference the commonName AND surname attributes as either mandatory OR optional attributes: (objectClasses:componentFilterMatch:=and:{ or:{ item:{ component "information.mandatories.*", rule objectIdentifierMatch, value cn }, item:{ component "information.optionals.*", rule objectIdentifierMatch, value cn } }, or:{ item:{ component "information.mandatories.*", rule objectIdentifierMatch, value sn }, item:{ component "information.optionals.*", rule objectIdentifierMatch, value sn } } }) The next example is inspired by Sean Mullan. Sean Mullan wrote: > What happens if you want to define a matching rule to only retrieve certs > that contain a specific basic constraints value AND a certain issuer name? In > this case, you would define 2 matching rules and specify both of them in > the valuesReturnFilter control. But then you would get all certs with the > requested issuer name and any basic constraints value and all certs with > any issuer name and the requested basic constraints value. That's not > what you wanted. I think we may want to enhance the valuesReturnFilter > control (through a flag, perhaps) to allow the user to apply all of the > elements of the filter to each attribute value. Let's discuss this more > offline, if you like. Here is a component filter match on a specific value of basic constraints AND a certain issuer name: (userCertificate:componentFilterMatch:=and:{ item:{ component "extensions.*", rule asn1Match, value { extnId 2.5.29.19, extnValue '3003020102'H } }, item:{ component "issuer.rdnSequence", rule distinguishedNameMatch, value "cn=CA, o=Adacel, c=au" } }) 2.5.29.19 is the OID for the basicConstraints extension. Unfortunately the extension value (extnValue) is defined to be a DER encoding wrapped in an OCTET STRING (ugh!). In the above example it was particularly convenient to use the asn1Match rule to match the whole extension, i.e. { extnId 2.5.29.19, extnValue '3003020102'H }, in one hit, instead of writing a nested "and" filter of each of the components of the extension. The asn1Match rule is essentially a short hand for an "and" component filter specifying every component. I can imagine situations where it would be useful to test not only if a *specific* value of a particular component is present but whether *any* value of a particular component is present. Hence the following matching rule: presentMatch MATCHING-RULE ::= { SYNTAX NULL ID } When used on an attribute in a extensible match filter item it behaves like the present case of a regular search filter. In a ComponentAssertion it evaluates to true if and only if the referenced component exists. To find object class definitions that have descriptions use: (objectClasses:componentMatch:= { component "description", rule presentMatch, NULL }) To find object class definitions that don't have descriptions use: (objectClasses:componentFilterMatch:= not:item:{ component "description", rule presentMatch, NULL }) To find the object class definitions that are not marked as obsolete (the "obsolete" component is absent, or is present and set to FALSE): (objectClasses:componentFilterMatch:=or:{ not:item:{ component "obsolete", rule presentMatch, NULL }, item:{ component "obsolete", rule booleanMatch, FALSE } }) The DistinguishedName and RelativeDistinguishedName ASN.1 types are also constructed types so the component matching rules could be applied to them. For convenience, here is the stripped down ASN.1 type for DNs. DistinguishedName ::= SEQUENCE OF RelativeDistinguishedName RelativeDistinguishedName ::= SET OF AttributeTypeAndValue AttributeTypeAndValue ::= SEQUENCE { type AttributeType, -- OBJECT IDENTIFIER value AttributeValue -- ANY } To find all seeAlso attributes (DN syntax) containing the RDN "o=Adacel" use: (seeAlso:componentMatch:= { component "*", rule componentFilterMatch, value and:{ item:{ component "0", rule integerMatch, value 1 }, item:{ component "*", rule asn1Match, value { type o, value "Adacel" } } } }) This assertion tests each RDN (referenced by the first "*") to see if it has exactly one AVA (the count is given by "0") with attribute type organization and value "Adacel". Since RDNs appear all over the place it makes sense to define a matching rule that can make RDN matching more concise. rdnMatch MATCHING-RULE ::= { SYNTAX RelativeDistinguishedName ID } The rdnMatch rule evaluates to true if the component value and assertion value are the same RDN. Now the above example to find all seeAlso attributes containing the RDN "o=Adacel" becomes: (seeAlso:componentMatch:={ component "*", rule rdnMatch, value "o=Adacel" }) The rdnMatch can be useful wherever DNs appear. To find all values of the ldapACI attribute that have "o=Adacel" somewhere in the DN in the subject field use: (ldapACI:componentMatch:= { component "subject.dn.*", rule rdnMatch, value "o=Adacel" }) To find all seeAlso values with "o=Adacel, c=au" as a "suffix" (noting that the string encoding of LDAPDN puts the RDNs in reverse order) use: (seeAlso:componentFilterMatch:=and:{ item:{ component "1", rule rdnMatch, value "c=au" }, item:{ component "2", rule rdnMatch, value "o=Adacel" } }) There's a case for being able to specify a match against the last component, or second last component, etc, but we'd have to invent a syntax for that. Okay, so what do people think ? The value of componentFilterMatch and friends is that they implicitly define a bunch of useful matching rule semantics for a new attribute syntax the moment the ASN.1 type is written down, and are automatically extended if the ASN.1 type is later extended. We might never need to define another matching rule for a constructed syntax. What would be missing though is a definition of the string encoding, so having a predictable way of generating the ABNF from the ASN.1 type would be particularly valuable. For the examples above I didn't formally define the string encoding for ComponentAssertion and ComponentFilter, themselves constructed types, but I was consistently following a set of rules. Those rules would be my preferred solution for algorithmically derived string encodings for new attribute and assertion syntaxes. Since the componentFilterMatch is generally useful, and can be applied to any ASN.1 type, it makes more sense for me to write it up as a separate Internet draft under the auspices of LDAPEXT, rather than incorporating its definition into either the LDAP ACL model or the PKIX LDAP schema. So is there support out there for me to go ahead and write this up as an ID ? Will LDAP access control and PKIX make use of it ? Regards, Steven Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26500 for ; Fri, 25 Aug 2000 11:32:28 -0700 (PDT) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Fri, 25 Aug 2000 11:28:35 -0700 Message-ID: <69A40A314934D41190C70050DAD7F99063B597@MAIL> From: Mathew Butler To: "'Mitchell Arnone'" , IETF-PKIX LIST Subject: RE: certificate management tools Date: Fri, 25 Aug 2000 11:28:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" OpenSSL, at www.openssl.org. Use 'openssl x509 -noout -text -in ' (where is not a literal less-than/greater-than, but the name of the file that contains the PEM-encoded certificate). -Mat -----Original Message----- From: Mitchell Arnone [mailto:mitchell.arnone@tidepoint.net] Sent: Friday, August 25, 2000 11:19 AM To: IETF-PKIX LIST Subject: certificate management tools I am looking for some tools that will allow me to convert PEM encoded certificates (ASCII or Binary) into simple readable text. Does anyone know where there might be some freeware or shareware utilities for digital certificates? Thanks Mitch Received: from mailhost.tdpt.net ([63.146.0.238]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25362 for ; Fri, 25 Aug 2000 11:19:42 -0700 (PDT) Received: from tidepoint.net ([192.168.10.52]) by mailhost.tdpt.net (Netscape Messaging Server 4.15) with ESMTP id FZV1LD00.U6R for ; Fri, 25 Aug 2000 14:20:01 -0400 Message-ID: <39A6B8A2.C6B2548A@tidepoint.net> Date: Fri, 25 Aug 2000 14:19:14 -0400 From: "Mitchell Arnone" Organization: TidePoint X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF-PKIX LIST Subject: certificate management tools Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msB55DFE58D568D791D191F597" This is a cryptographically signed message in MIME format. --------------msB55DFE58D568D791D191F597 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am looking for some tools that will allow me to convert PEM encoded certificates (ASCII or Binary) into simple readable text. Does anyone know where there might be some freeware or shareware utilities for digital certificates? Thanks Mitch --------------msB55DFE58D568D791D191F597 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIKwYJKoZIhvcNAQcCoIIIHDCCCBgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BcwwggLXMIICQKADAgECAhEArBkEZgAAAnwAAAAVAAAACTANBgkqhkiG9w0BAQUFADCBtjEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCE1hcnlsYW5kMRIwEAYDVQQHEwlCYWx0aW1vcmUxHjAc BgNVBAoTFVRpZGVQb2ludCBDb3Jwb3JhdGlvbjEMMAoGA1UECxMDUEtJMR8wHQYDVQQDExZU aWRlUG9pbnQgQ29ycG9yYXRlIENBMTEwLwYJKoZIhvcNAQkBFiJicmlhbi5kaWxsZXlAYjJi Y29tbXVuaWNhdGlvbnMuY29tMB4XDTAwMDgwMTE0NTcxNloXDTAzMDcwMzIwMTgxNlowgYox CzAJBgNVBAYTAnVzMREwDwYDVQQIEwhNYXJ5bGFuZDESMBAGA1UEBxMJQmFsdGltb3JlMR4w HAYDVQQKExVUaWRlUG9pbnQgQ29ycG9yYXRpb24xDDAKBgNVBAsTA1BLSTEmMCQGA1UEAxMd TWl0Y2hlbGwgVCBBcm5vbmUgKFNpZ25hdHVyZSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALRwJhDwGHIxVV5FNHITbjGCeccK70+6vZ5xegTDflWwoJXb2T1eEqHZTZ+NUmgHTaNj ckbS4RP0CbO7bnthENbknm/dj77gzMQy1ouZgctMNbkR9ktry4MGvn1sNkCnNJD4I5eRlWuw FDIwn3OB8Q4Mm45omq9+9TWeSKYzRJbJAgMBAAGjDzANMAsGA1UdDwQEAwIHgDANBgkqhkiG 9w0BAQUFAAOBgQCHSm7EfCrk9ZDWvKxTbu4xWgCq+z2unLCnI2lSU8QJpRtqk1qfrCx1ZoE7 C6kcef+oo36NNJQWSX6lI6IvwA0GRM20aW/J11keuiZvNnOG2xqYbp8GAtiCpY2c4j06a1wW JyHLiPrT+APVq+9HGYv+aC1a9q7hXHHd4Z3yZWaSWTCCAu0wggJWAhEArBkEZQAAAnwAAAAC AAAABDANBgkqhkiG9w0BAQUFADCBtjELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE1hcnlsYW5k MRIwEAYDVQQHEwlCYWx0aW1vcmUxHjAcBgNVBAoTFVRpZGVQb2ludCBDb3Jwb3JhdGlvbjEM MAoGA1UECxMDUEtJMRwwGgYDVQQDExNUaWRlUG9pbnQgUHJpbmNpcGxlMTQwMgYJKoZIhvcN AQkBFiVtaXRjaGVsbC5hcm5vbmVAYjJiY29tbXVuaWNhdGlvbnMuY29tMB4XDTAwMDcwNjIw MTk1N1oXDTAzMDcwNjIwMTk1N1owgbYxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNYXJ5bGFu ZDESMBAGA1UEBxMJQmFsdGltb3JlMR4wHAYDVQQKExVUaWRlUG9pbnQgQ29ycG9yYXRpb24x DDAKBgNVBAsTA1BLSTEfMB0GA1UEAxMWVGlkZVBvaW50IENvcnBvcmF0ZSBDQTExMC8GCSqG SIb3DQEJARYiYnJpYW4uZGlsbGV5QGIyYmNvbW11bmljYXRpb25zLmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEA1/CKGYEMULAuj6+5EYuFl1R6NvmslYywzTFL5suvKNeEH5rA jH8jlV6qv7ugoryeL+130Atsh1muS+bKDYUTg+eCSNTZ0G0Pi4qLzzNwZPxTk7prJvErD0b8 3ByEZb+7LJ0wXeI5TxU8n2sLWecHKnXmQTpVrxA6Ub0uOxFbbKsCAwEAATANBgkqhkiG9w0B AQUFAAOBgQBIAW6ADXwSIanrFKnX66xdWXlblwc2pfasIr3uDrPBRSpwrvt8RyCM+eWUByAi G03AD+y40G0hdMEoljZMgZabeZ5fwtM3zLm13z9G/ec7oU2jUNy7N9MQ6HNg8kd2kDNNoSDR yG1sYLPBSIPgtghDZg2MnxBxc40GVDzxaUXVGzGCAicwggIjAgEBMIHMMIG2MQswCQYDVQQG EwJVUzERMA8GA1UECBMITWFyeWxhbmQxEjAQBgNVBAcTCUJhbHRpbW9yZTEeMBwGA1UEChMV VGlkZVBvaW50IENvcnBvcmF0aW9uMQwwCgYDVQQLEwNQS0kxHzAdBgNVBAMTFlRpZGVQb2lu dCBDb3Jwb3JhdGUgQ0ExMTAvBgkqhkiG9w0BCQEWImJyaWFuLmRpbGxleUBiMmJjb21tdW5p Y2F0aW9ucy5jb20CEQCsGQRmAAACfAAAABUAAAAJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwODI1MTgxOTE0WjAjBgkqhkiG 9w0BCQQxFgQUSfZ3Ymdww0aIu5lM2+qKELcw1TkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcN AwICASgwDQYJKoZIhvcNAQEBBQAEgYB/RIuOx0miMmCLelOETl1OIYA7sUjpTebQFfFJl/BH yAr7/fEJDGpYhIrOWKbYbqKrSohNc3dDYnrzO1JHs6Rb+HBdVEOzc45v9zl2IRA5mYp/4Uty Hv/s6ZDNpAgbc2IPQ/ITiFkdvDk1Q1+9iQnk3y4Te2UREiki/0F9NcsJwg== --------------msB55DFE58D568D791D191F597-- Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.121.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA13644 for ; Fri, 25 Aug 2000 00:35:08 -0700 (PDT) Received: from [38.29.124.224] (ip224.phoenix12.az.pub-ip.psi.net [38.29.124.224]) by harrier.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id AAA00520; Fri, 25 Aug 2000 00:35:32 -0700 (PDT) Mime-Version: 1.0 X-Sender: hoytkesterson@mail.earthlink.net Message-Id: In-Reply-To: <3120721CA75DD411B8340090273D20B1271F0E@sottmxs06.entrust.com> References: <3120721CA75DD411B8340090273D20B1271F0E@sottmxs06.entrust.com> Date: Thu, 24 Aug 2000 23:55:18 -0700 To: Sharon Boeyen , "'d.w.chadwick@salford.ac.uk'" , ietf-pkix@imc.org From: "Hoyt L. Kesterson II" Subject: RE: Undefined combinations of extensions Cc: "Kurt D. Zeilenga" , osidirectory@az05.bull.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" i want to support sharon on her statement on the intent of the DR. the text that will be added to the standard to resolve the defect report will make it clear that if an implementation "recognizes" an extension, then that implementation shall support THAT extension according to the syntax and procedures specified in the clauses defining THAT extension. one of the problems of viewing the x.509 standard by itself is that we have lost the valuable concept of the statement of conformance. i hope that the approved text will correct this lack. this concern about relationships between extensions can be addressed in a variety of ways. for example, an environment, such as a vertical sector, could decide that certain extensions must be present (regardless of criticality settings) before a certificate is acceptable. in addition, permitted and disallowed combinations of extensions, or values within those extensions, could also be specified in a profile for that environment. only implementations with statements of proper conformance would be deployed into that environment. however, the reason for extensibility, including criticality, must always be kept in mind - correct interoperation using an acceptable, commonly understood subset of information in a certificate. one is permitted to define a new extension,X, that, if present, influences the interpretation of one or more other extensions, Y. however, if the issuer of a certificate wants to ensure that Y will always be interpreted in the new fashion, it must declare X critical (or know that the certificate will only be used within an environment that understands, and requires the presence of, X). if the issuer does not adhere to this principle, an implementation that is unaware of the definition of X will ignore X but will process Y according to the rules the implementation understand, i.e. without the nuances associated with the presence of X. hoyt At 1:07 PM -0400 8/23/00, Sharon Boeyen wrote: >The defect report is clarifying, not changing, the way criticality >is treated for certificate extensions. Criticality applies to each >extension independent of all others. Clearly, if one extension is >included in a certificate as critical (e.g. certificate policies) >and another is included as non-critical (e.g. policy mappings), then >there will be different results by relying party systems that do >support policy mappings and ones that do not. However, there should >be no difference in relying party systems that do support the extensions >regardless of their criticality. > > > >A CA sets the criticality flag for each and every extension as it sees >fit. By setting an extension non-critical, the CA is accepting the fact >that relying party systems that do not understand this extension will ignore >it when processing the certificate and relying party systems that do >understand it will process it. When it sets the flag critical it is >limiting the relying parties to ONLY those that understand the extension. > >Any semantic relationship between two or more extensions (e.g. among the >policy related ones) needs to be addressed by the issuer (for instance >it doesn't make a lot of sense to issue a certificate with critical >policy mappings but non-critical certificate policies). This is a policy >issue though not one that the criticality flag should be used to solve. > >If there is a situation where two extensions may cause conflicting >impacts (e.g. the issuingDistributionPoint extension and the crlScope >extension), then the definition of the extensions themselves should >contain the semantics of what is to be done (see the definition of >crlScope which states that these 2 are not intended to be used together >but states what the rule is if both happen to be present). > >If the problem you are trying to solve is that extensions have not >been properly or fully defined, then that problem should be fixed in >the extension definitions themselves, not by trying to invert the meaning >of critical and non critical in the standard. > >Is there a concrete example you can share, that might bring to light some >point I'm missing? > > >Sharon > > > > > > >> -----Original Message----- >> From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk] >> Sent: Wednesday, August 23, 2000 12:36 PM >> To: ietf-pkix@imc.org >> Cc: Kurt D. Zeilenga; osidirectory@az05.bull.com >> Subject: Undefined combinations of extensions >> >> >> On the LDAPExt list we have been discussing the effects of >> combinations of extensions (controls in LDAP jargon) on the LDAP > > server performing an LDAP operation, when the effects of the > > combination of one or more extensions is not understood by the > > server. The server may understand each separate extension, but >> not the semantics of them in combination. >> >> It seems to me that PKIX/X.509 will have (or already may have >> encountered) this same problem for COMBINATIONS of certificate >> extensions (some of which may be private, some de-facto, some >> critical, some not) that are thought to be understood by the issuing >> CA, but are not fully understood by the relying party / validation >> engine. >> >> What text does anyone have for this situation? I believe the recently >> issued X.509 defect report 244, raised by Sharon, only discusses >> the case of a single extension in isolation, and does not discuss the >> effects of combinations of extensions. >> >> The most interesting cases are when the RP finds combinations of >> extensions, where each extension on its own is understood, but >> where the combined semantics are not fully understood (possibly >> due to incomplete or ambiguous specification of extension >> interactions when the extensions are written by different >> groups). In >> this case, LDAP is suggesting that a receiver may ignore non- >> critical extensions (even those it recognizes) to establish the >> semantics of the operation. This is in direct contrast to the wording >> of defect report 244, which states that an understood non-critical >> extension must be obeyed. The LDAP work would suggest an >> addition to DR244 along the lines of >> >> " A validation engine that does not understand the interaction of a >> non-critical extension with another extension (critical or >> non-critical), >> may ignore the non-critical extension (even if it understands the >> semantics of the extension in isolation to the others), and >> accept the >> certificate (unless factors other than this extension cause it to be >> rejected). >> >> A validation engine that does not understand the interaction of two >> critical extensions, must reject the certificate (even if it >> understands >> the semantics of both extensions in isolation to each other)." >> >> David >> >> >> >> *************************************************** >> >> David Chadwick >> IS Institute, University of Salford, Salford M5 4WT >> Tel +44 161 295 5351 Fax +44 161 745 8169 >> Mobile +44 790 167 0359 >> Email D.W.Chadwick@salford.ac.uk >> Home Page http://www.salford.ac.uk/its024/chadwick.htm >> Understanding X.500 http://www.salford.ac.uk/its024/X500.htm >> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm >> Entrust key validation string MLJ9-DU5T-HV8J >> >> *************************************************** >> Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA17745 for ; Thu, 24 Aug 2000 06:51:29 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Aug 2000 09:51:29 -0400 Message-ID: <3120721CA75DD411B8340090273D20B1271F19@sottmxs06.entrust.com> From: Sharon Boeyen To: "'Stephen Kent'" , d.w.chadwick@salford.ac.uk Cc: ietf-pkix@imc.org, "Kurt D. Zeilenga" , osidirectory@az05.bull.com Subject: RE: Undefined combinations of extensions Date: Thu, 24 Aug 2000 09:47:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" I agree that this would be a valuable profiling activity and would hopefully address the issues David raised without any impact on the criticality flag. PKIX could certainly impose requirements on the set of combinations that are valid for a PKIX issued certificate, however validation engines still need to be able to cope with PKIX and non-PKIX issued certificates. Sharon -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Wednesday, August 23, 2000 3:34 PM To: d.w.chadwick@salford.ac.uk Cc: ietf-pkix@imc.org; Kurt D. Zeilenga; osidirectory@az05.bull.com Subject: Re: Undefined combinations of extensions David, Your question about combinations of extensions, and base certificate/CRL fields, is a good one. Tim Polk and I discussed this issue during the last PKIX WG meeting, in a more limited context. I proposed that we include a table that described syntactic constraints among all the fields in a cert or CRL, to address the question of which combinations of fields and values are valid. One cannot do this for really private extensions, and doing it for new extensions that are publicly disclosed is an ongoing task. But, at least we should provide folks with a base set of constraints. I think 2459 should do this and I volunteered to provide a draft table for this. Steve Received: from scog-ws3.gsa.gov (host.159-142-144-58.gsa.gov [159.142.144.58]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA13271 for ; Thu, 24 Aug 2000 04:19:02 -0700 (PDT) From: judith.spencer@gsa.gov Received: from 159.142.144.55 by scog-ws3.gsa.gov with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Thu, 24 Aug 2000 07:19:28 -0400 X-Server-Uuid: cb2f616c-ae65-11d3-874c-00508b6362bc Subject: RE: President Clinton digital signing To: mbutler@tonbu.com cc: judith.spencer@gsa.gov, William.Flanigan@bmdo.osd.mil, pbaker@verisign.com, terri.hobson@gsa.gov, marion.royal@gsa.gov, ietf-pkix@imc.org Sender: judith.spencer@gsa.gov Date: Thu, 24 Aug 2000 07:19:17 -0400 Message-ID: X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on SCOG-NOTESSMTP1/GSAEXTERNAL(Release 5.0.1b|September 30, 1999) at 08/24/2000 07:19:28 AM MIME-Version: 1.0 X-WSS-ID: 15BBDB4A251669-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA13272 The certificate used by the President was signed by the ACES CA. ACES is a GSA-sponsored governmentwide pki capability that includes the issuance of certificates under a Certificate Policy developed by the General Services Administration, Office of Governmentwide Policy. We do have a copy of the electronically signed bill and the signature can be verified. It is not available on line at this time, but it should be made available in the next few weeks. Ditto the certificate used by the President. I will let you know when it is available. Judy Spencer Office of Information Security General Services Administration "Mathew Butler" on 08/23/2000 02:25:42 PM To: "'judith.spencer@gsa.gov'" , William.Flanigan@bmdo.osd.mil cc: pbaker@verisign.com, terri.hobson@gsa.gov, marion.royal@gsa.gov, ietf-pkix@imc.org Subject: RE: President Clinton digital signing The question is, "Is there some certification authority that was designated by [whoever has the power to make the designation, be it Congress or the GSA or the GAO or whoever], that signed the certificate that President Clinton used to sign the bill, in order to ensure the authenticity and integrity of the signature [in order to make it legally binding]?" I know that there is nothing in law (even with the signing of this bill) that allows the President to ratify a bill with anything other than a physical signature and seal. Therefore, the entire question is completely ludicrous in the first place, as the answer is patently "No". However, there's a few questions I have... what CA -did- sign the certificate that President Clinton used? Is there an actual copy of the electronically signed version of the bill, including signature, online that we can look at? Also, can we get a copy of the certificate that he used, along with the entire certificate chain to the certificate for the root? (Rather than spamming the list, is there a URL on the GSA's website that would provide access to this information?) Thanks! -Mat Butler -----Original Message----- From: judith.spencer@gsa.gov [mailto:judith.spencer@gsa.gov] Sent: Wednesday, August 23, 2000 9:55 AM To: William.Flanigan@bmdo.osd.mil Cc: pbaker@verisign.com; terri.hobson@gsa.gov; judith.spencer@gsa.gov; marion.royal@gsa.gov; ietf-pkix@imc.org Subject: RE: President Clinton digital signing The e-signing of the bill was a demonstration of the technology. You're right. The bill was officially signed with a pen and then a wax seal was applied. I'm having a little trouble with your "circular reference" statement and that the bill is a "self-signed certificate". Perhaps you'd be willing to explain your reasoning to me more fully. Judy Spencer "Flanigan, William, CIV,BMDO/DSC" on 08/23/2000 09:37:06 AM To: "'Philip Hallam-Baker'" cc: terri.hobson@gsa.gov, judith.spencer@gsa.gov, "'marion.royal@gsa.gov'" , ietf-pkix@imc.org Subject: RE: President Clinton digital signing Right on Philip (as usual)!  But it seems unlikely that the bill was not "signed" twice, one being a wet signature (with no photo op).  Does anyone know for sure? Bill Flanigan -----Original Message----- From: Philip Hallam-Baker [mailto:pbaker@verisign.com] Sent: Tuesday, August 22, 2000 9:08 PM To: 'marion.royal@gsa.gov'; ietf-pkix@imc.org Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov Subject: RE: President Clinton digital signing [snip] And it was totally illogical to use a digital signature for the purpose. The act is now effectively a self-signed cert! The validity of the authentication on the act is established through a circular reference to the act itself.               Phill Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA25851 for ; Wed, 23 Aug 2000 21:47:29 -0700 (PDT) From: Lynn.Wheeler@firstdata.com Received: from mailgw.firstdata.com ([204.48.27.156]) by mail01-ewr.pilot.net with ESMTP id AAA10739; Thu, 24 Aug 2000 00:47:58 -0400 (EDT) Received: from lnsunr02.firstdata.com (localhost [127.0.0.1]) by mailgw.firstdata.com with SMTP id AAA02475; Thu, 24 Aug 2000 00:47:55 -0400 (EDT) Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256945.0019D1D1 ; Thu, 24 Aug 2000 00:42:01 -0400 X-Lotus-FromDomain: FDC To: Tom Strickland cc: Liaquat Khan , ietf-pkix@imc.org Message-ID: <85256944.006F22E1.00@lnsunr02.firstdata.com> Date: Wed, 23 Aug 2000 13:14:45 -0700 Subject: Re: President Clinton digital signing Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline a number of financial infrastructures not only need real-time status ... but also things like real time inforatmion, no single point of failrues and some even five nines availability. also looking at it from a transaction flow aspect, the transaction has to hit the account record (for other real time informaiton reasons ... like account balance) ... and involve an infrastructure that have existing business infrastructures with both authentication and authorization. For these types of financial infrastructures ... they need to control their own infrastructure including things like RAs ... where they do the public key registration in the account record ... and returning a copy of relying-party only certificate to the account holder (for liability and privacy reasons). The interesting thing is that these protocols appends a copy of the certificate to a signed message that is sent to the financial institution ... when the financial institution has the original of the certificate in the account record (an account record that has to be read in any case to perform the financial ttransaction). The simpler process is to recognize that it is superfulous and redundant to return a copy of a certificate (appended to every signed message) sent to a financial institution, a financial insitution that will be reading a record containing the original of the certificate. Since the master account record with not only real-time status as well real-time information is being read as part of executing the operation ... it not only eliminates the extraneous transmission of appended certificates, eliminates requirements for both CRL & OCSP checking, minimizes points of failures, and improves availability. misc. refs: http://www.garlic.com/~lynn/99.html#71 http://www.garlic.com/~lynn/99.html#128 http://www.garlic.com/~lynn/ansiepay.htm#aadsnew2 http://www.garlic.com/~lynn/aepay2.htm#position mapping of the draft x9.59 financial standard to existing online networks: http://www.garlic.com/~lynn/8583flow.htm Tom Strickland on 08/23/2000 05:31:12 AM ...... Example: If a company does not have a requirement for current information, a CRL is sufficient. If a company requires real time data (i.e. a bank or government) due to high value transactions or security, then I would highly recommend OCSP. The risk is if you use CRLs for the latter, the company may get a false sense of security believing their "high value" transactions are guarded by real time data. If the batch CRL is latent, you may continue processing utilizing old data. The risk is a cert believed to be revoked may still be considered good in the system exposing the company to potential fraud or negligence. In an OCSP environment, if you must trust real time data and someone executes a DoS attack, the responder may slow down or worst case, stop working. This is an added value because I would rather slow down or stop processing than to rely on old data. The risk here is slower response time but guaranteed accurate information. Received: from imo-r16.mx.aol.com (imo-r16.mx.aol.com [152.163.225.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22694 for ; Wed, 23 Aug 2000 20:03:20 -0700 (PDT) From: TeamDaguio@aol.com Received: from TeamDaguio@aol.com by imo-r16.mx.aol.com (mail_out_v28.15.) id o.ae.9ae2b68 (4207); Wed, 23 Aug 2000 23:01:23 -0400 (EDT) Message-ID: Date: Wed, 23 Aug 2000 23:01:22 EDT Subject: Re: President Clinton digital signing To: mbutler@tonbu.com, azb@llnl.gov, pbaker@verisign.com, bjueneman@novell.com, William.Flanigan@bmdo.osd.mil CC: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 119 Dear Friends, The use of the dst or abaecom ca generated certificate to sign the bill electronically was certainly meaningful in a politically symbolic sense, but not the legal signature that transformed the bill into law. The President used his pen first and will continue to do so because of tradition. I suggest that the technical issues involved in the signing are not only not really meaningful, but also not interesting. We passed the bill we wanted by ignoring the technology and focusing on the issues that are meaningful to politicians and ordinary people. I repeately said, "This effort is not about technology or technology vendors. This effort is about the freedom to contract and the right to expect contracts to be enforced." I argued that the Federal and state governments should not interfere with voluntary contracts and should instead support and enforced such arrangements. We won on this basis without having to explain how the crypto or biometrics might work. The push to get where we are has taken a lot of time and effort, and I am proud to say that at no time has political fundraising or partisan politics played a role in the outcome. We won this one on the strength of our arguments and the soundness of our strategy. The path to legal certainty was a long one and the strategy required collaboration between a number of old Washington hands running both strategy and interference to prevent less fair and less reasonable approaches from gaining ground. I have been lobbying on these issues for nearly a decade and was pleased to see the basic underpinnings for a supportive legal infrastructure for electronic commerce created. (I worked at the US Treasury and the American Bankers Association doing technology strategy, policy, and standards for the industry) HISTORY OF THE EFFORT The federal government has had the power to determine itself what forms of legal arrangements can bind the executive, legislative, and judiciary branches to writings or agreements of any sort. Quite some time ago the Executive Branch (administrative, not political officers) exercising its legitimate sovereignty published a policy that clearly supported electronic authentication as a legitimate contracting mechanism that could bind the government and contractors to agreements. (this was not a spontaneous act) We followed up by pushing for and getting reduced regulatory overhead on an agency by agency and department by department basis. A little later the Government Paperwork Elimination Act reinforced and broadened the Federal legal infrastructure's support for electronic agreements between the government, individuals, and firms. (this incremental bit of legislation was critical to positioning the next and later steps) We again broadened and further supported the legal framework for electronic commerce by passing the most recent act, which provides for purely voluntary and arbitrary agreements between contracting parties. We have a bit of fine tuning to go and more to do. Some part of e-enabling commerce still requires that we push policy changes, but much more work is required to make the technologies offered as solutions meet the practical requirements of the real world. I suggest that the arrogance of technologists and technology vendors is the greatest obstacle to adoption and acceptance that PKI faces. We have the basic supportive legal infrastructure built (effective in october). I am looking foward to addressing the challenges presented by both the lack of a sufficiently supportive technological infrastructures and the lack of support for the deployment of the technology on a business case basis as well as a whole host of other business issues. I hope that each of you can help to make PKI more practical so that we can get pragmatists to see its value, buy it, pay for it, use it, and recommend it to each other. aloha...kawika kawika daguio 301 332 5224 Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19479 for ; Wed, 23 Aug 2000 18:09:35 -0700 (PDT) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 18:05:43 -0700 Message-ID: <69A40A314934D41190C70050DAD7F99063B58F@MAIL> From: Mathew Butler To: "'Tony Bartoletti'" , Mathew Butler , Philip Hallam-Baker , "'Bob Jueneman'" , William.Flanigan@bmdo.osd.mil, Philip Hallam-Baker Cc: ietf-pkix@imc.org Subject: RE: President Clinton digital signing Date: Wed, 23 Aug 2000 18:05:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" This is why I wanted the certificates all the way up to the root, as well as the signed digital representation of the bill. -Mat -----Original Message----- From: Tony Bartoletti [mailto:azb@llnl.gov] Sent: Wednesday, August 23, 2000 5:57 PM To: Mathew Butler; Philip Hallam-Baker; 'Bob Jueneman'; William.Flanigan@bmdo.osd.mil; Philip Hallam-Baker Cc: ietf-pkix@imc.org Subject: RE: President Clinton digital signing At 05:27 PM 8/23/00 -0700, Mathew Butler wrote: >There is no digital key that can sign "documents of office". The >legislation changed how certain high-value monetary transactions can be >signed -- it didn't modify how the president does his job. Understood, thank you. The "act" of digitally signing the bill in question was an empty gesture, so to speak. Out of curiosity, was it accomplished with an entirely arbitrary "signing key" (a string of zeros, perhaps) or was the (empty) formalism carried further (formal parameters, certificate, etc.)? Is the signature formally (if not legally) verifiable? ___tony___ >At 04:44 PM 8/23/00 -0700, Philip Hallam-Baker wrote: > > > >I believe that the bill was in fact signed twice, once with a pen, but > >I also believe that >the concern about circularity is a red herring. > > > >It was a humorous observation I didn't expect you folk to make a federal > >case out of it! > >:) > >And I enjoyed the story of the Stuart King. > >But for the sake of "formalism" (and curiosity) doe anyone know just >what CA has certified this key? Or what the precise DN looks like? > >More to the point, was the entire exercise of signing with this key >just a cute charade, or does the U.S. President (now, officially) >have a digital key with which to sign "documents of the office", and >if so, what are the attributes of the corresponding certificate? > >(It must expire soon ;) > >The question of "who certifies the President's digital signature" >is an interesting one, in my view, not only now but in general. > >___tony___ > > >Tony Bartoletti 925-422-3881 >Information Operations, Warfare and Assurance Center >Lawrence Livermore National Laboratory >Livermore, CA 94551-9900 Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17959 for ; Wed, 23 Aug 2000 17:47:56 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id RAA03036; Wed, 23 Aug 2000 17:46:56 -0700 (PDT) Message-Id: <4.2.2.20000823175057.00aabc00@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 23 Aug 2000 17:56:53 -0700 To: Mathew Butler , Philip Hallam-Baker , "'Bob Jueneman'" , William.Flanigan@bmdo.osd.mil, Philip Hallam-Baker From: Tony Bartoletti Subject: RE: President Clinton digital signing Cc: ietf-pkix@imc.org In-Reply-To: <69A40A314934D41190C70050DAD7F99063B58E@MAIL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 05:27 PM 8/23/00 -0700, Mathew Butler wrote: >There is no digital key that can sign "documents of office". The >legislation changed how certain high-value monetary transactions can be >signed -- it didn't modify how the president does his job. Understood, thank you. The "act" of digitally signing the bill in question was an empty gesture, so to speak. Out of curiosity, was it accomplished with an entirely arbitrary "signing key" (a string of zeros, perhaps) or was the (empty) formalism carried further (formal parameters, certificate, etc.)? Is the signature formally (if not legally) verifiable? ___tony___ >At 04:44 PM 8/23/00 -0700, Philip Hallam-Baker wrote: > > > >I believe that the bill was in fact signed twice, once with a pen, but > >I also believe that >the concern about circularity is a red herring. > > > >It was a humorous observation I didn't expect you folk to make a federal > >case out of it! > >:) > >And I enjoyed the story of the Stuart King. > >But for the sake of "formalism" (and curiosity) doe anyone know just >what CA has certified this key? Or what the precise DN looks like? > >More to the point, was the entire exercise of signing with this key >just a cute charade, or does the U.S. President (now, officially) >have a digital key with which to sign "documents of the office", and >if so, what are the attributes of the corresponding certificate? > >(It must expire soon ;) > >The question of "who certifies the President's digital signature" >is an interesting one, in my view, not only now but in general. > >___tony___ > > >Tony Bartoletti 925-422-3881 >Information Operations, Warfare and Assurance Center >Lawrence Livermore National Laboratory >Livermore, CA 94551-9900 Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17450 for ; Wed, 23 Aug 2000 17:31:45 -0700 (PDT) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 17:27:52 -0700 Message-ID: <69A40A314934D41190C70050DAD7F99063B58E@MAIL> From: Mathew Butler To: "'Tony Bartoletti'" , Philip Hallam-Baker , "'Bob Jueneman'" , William.Flanigan@bmdo.osd.mil, Philip Hallam-Baker Cc: ietf-pkix@imc.org Subject: RE: President Clinton digital signing Date: Wed, 23 Aug 2000 17:27:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" There is no digital key that can sign "documents of office". The legislation changed how certain high-value monetary transactions can be signed -- it didn't modify how the president does his job. -Mat Butler -----Original Message----- From: Tony Bartoletti [mailto:azb@llnl.gov] Sent: Wednesday, August 23, 2000 5:24 PM To: Philip Hallam-Baker; 'Bob Jueneman'; William.Flanigan@bmdo.osd.mil; Philip Hallam-Baker Cc: ietf-pkix@imc.org Subject: RE: President Clinton digital signing At 04:44 PM 8/23/00 -0700, Philip Hallam-Baker wrote: > >I believe that the bill was in fact signed twice, once with a pen, but >I also believe that >the concern about circularity is a red herring. > >It was a humorous observation I didn't expect you folk to make a federal >case out of it! :) And I enjoyed the story of the Stuart King. But for the sake of "formalism" (and curiosity) doe anyone know just what CA has certified this key? Or what the precise DN looks like? More to the point, was the entire exercise of signing with this key just a cute charade, or does the U.S. President (now, officially) have a digital key with which to sign "documents of the office", and if so, what are the attributes of the corresponding certificate? (It must expire soon ;) The question of "who certifies the President's digital signature" is an interesting one, in my view, not only now but in general. ___tony___ Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17091 for ; Wed, 23 Aug 2000 17:15:04 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id RAA22999; Wed, 23 Aug 2000 17:14:04 -0700 (PDT) Message-Id: <4.2.2.20000823170442.00aa8340@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 23 Aug 2000 17:24:02 -0700 To: Philip Hallam-Baker , "'Bob Jueneman'" , William.Flanigan@bmdo.osd.mil, Philip Hallam-Baker From: Tony Bartoletti Subject: RE: President Clinton digital signing Cc: ietf-pkix@imc.org In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F408EBEB@vhqpostal.verisign. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 04:44 PM 8/23/00 -0700, Philip Hallam-Baker wrote: > >I believe that the bill was in fact signed twice, once with a pen, but >I also believe that >the concern about circularity is a red herring. > >It was a humorous observation I didn't expect you folk to make a federal >case out of it! :) And I enjoyed the story of the Stuart King. But for the sake of "formalism" (and curiosity) doe anyone know just what CA has certified this key? Or what the precise DN looks like? More to the point, was the entire exercise of signing with this key just a cute charade, or does the U.S. President (now, officially) have a digital key with which to sign "documents of the office", and if so, what are the attributes of the corresponding certificate? (It must expire soon ;) The question of "who certifies the President's digital signature" is an interesting one, in my view, not only now but in general. ___tony___ Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16527 for ; Wed, 23 Aug 2000 16:46:07 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id QAA27716; Wed, 23 Aug 2000 16:46:21 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 16:44:46 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EBEB@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'Bob Jueneman'" , William.Flanigan@bmdo.osd.mil, Philip Hallam-Baker Cc: ietf-pkix@imc.org Subject: RE: President Clinton digital signing Date: Wed, 23 Aug 2000 16:44:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_000F_01C00D3A.C524EE50"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C00D3A.C524EE50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit >I believe that the bill was in fact signed twice, once with a pen, but I also believe that >the concern about circularity is a red herring. It was a humorous observation I didn't expect you folk to make a federal case out of it! The bill had to be signed twice because the whole premise of the act was legitimizing the use of digital signatures. If the digital signature alone was sufficient to sign an act of Congress then they were good enought for government work without the act. If the act was essential but only signed with a signature that was invalid absent the act there would be a circularity of reference. I agree that from that point of view, the bill itself was probably unnecessary to the extent that we all know that English Common Law (and its colonial derrivatives) is very tolerant of what is recognized as a 'signature'. There was actually an English Constitutional crisis when one of the Stuart Kings absconded, chucking the great seal of office in the Thames during his escape in an attempt to prevent parliament doing anything in his absence. But for the chance recovery of the seal by a fisherman the paliamentary faction would doubtless have decided that some arcane ceremony involving the parliamentary maces and such sanctified a new seal... In the case of the US Constitution however, the act didn't actually need signing at all - absent a veto the bill would have become law in any case. Phill ------=_NextPart_000_000F_01C00D3A.C524EE50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINaDCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEFDCCA32gAwIBAgIQ AxTuqrYcesW8jpUyudZ0/DANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNOTkxMjIwMDAwMDAwWhcNMDAx MjE5MjM1OTU5WjBsMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNTAzBgNVBAMTLHBiYWtlciAoUGhpbGlwIEhhbGxhbS1CYWtlciwgVmVyaVNpZ24s IEluYy4pMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3f0kRIy2AU5cHhfnUwuHecFNq6dnf /wsvxS//4Nt8rFgr2KdvQETKaQ6wGl6mVijB6udZW9dUKVoE1lnu2MMcIhtAL3+Q2dsrxlrTInfq PKAdxu/Fvb4n3Y0RItW9zh1MzFWZ8Q9z6eF2HuBwG6ANfRzfJgironyftbbitRyaxQIDAQABo4IB dDCCAXAwCQYDVR0TBAIwADBVBgNVHR8ETjBMMEqgSKBGhkRodHRwOi8vb25zaXRlY3JsLnZlcmlz aWduLmNvbS9WZXJpU2lnbkluY0V4Y2hhbmdlRW1wbG95ZWVzL0xhdGVzdENSTDALBgNVHQ8EBAMC BaAwHgYDVR0RBBcwFYETcGJha2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgB hvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4g YnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeA MB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQAaUApBXCjc mPE5dFPHlQVl4n9WoOU7AE487xxC7vcR1MDhF8p/0GMu6zOyZe9CFVaOndaYCRgv69qKTVoANmsM F/eFsQn/HaoXEz+jHPNgWcPyBu3dujO9s2PLQbuBXE3rIaDiVyTftVgoNvO0fcknSlNOWxqHvbaH 9RYvhMghkjGCAvgwggL0AgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVy bXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVy aVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAJBgUrDgMCGgUAoIIB jDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDA4MjMyMzQ2MDNa MCMGCSqGSIb3DQEJBDEWBBTIZs8w7YDiVjc5ZYv8EJtezbBxfjBYBgkqhkiG9w0BCQ8xSzBJMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjAKBggqhkiG9w0CBTCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEl MCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAN BgkqhkiG9w0BAQEFAASBgA3IIgVHSehgLrghinZdqsgD94eoztqLPsr1jC1hSs2RLvxH4LT7ucHs 3KbBcLdbkb9MQlGV+WpWNqFQNbBPaGdDIjophIp+fAo9OqJssvAnn6Ea5fZe+Mu5gPXBGF+Sejha 8dM0cjDhhUqRGOTaaQbtfJmi01ZAEJpJTjy9AcdpAAAAAAAA ------=_NextPart_000_000F_01C00D3A.C524EE50-- Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12907 for ; Wed, 23 Aug 2000 12:37:58 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA05597; Wed, 23 Aug 2000 15:38:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <39A40B6C.20716.17FCDF7@localhost> References: <39A40B6C.20716.17FCDF7@localhost> Date: Wed, 23 Aug 2000 15:33:47 -0400 To: d.w.chadwick@salford.ac.uk From: Stephen Kent Subject: Re: Undefined combinations of extensions Cc: ietf-pkix@imc.org, "Kurt D. Zeilenga" , osidirectory@az05.bull.com Content-Type: multipart/alternative; boundary="============_-1245062893==_ma============" --============_-1245062893==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" David, Your question about combinations of extensions, and base certificate/CRL fields, is a good one. Tim Polk and I discussed this issue during the last PKIX WG meeting, in a more limited context. I proposed that we include a table that described syntactic constraints among all the fields in a cert or CRL, to address the question of which combinations of fields and values are valid. One cannot do this for really private extensions, and doing it for new extensions that are publicly disclosed is an ongoing task. But, at least we should provide folks with a base set of constraints. I think 2459 should do this and I volunteered to provide a draft table for this. Steve --============_-1245062893==_ma============ Content-Type: text/enriched; charset="us-ascii" David, Your question about combinations of extensions, and base certificate/CRL fields, is a good one. Tim Polk and I discussed this issue during the last PKIX WG meeting, in a more limited context. I proposed that we include a table that described syntactic constraints among all the fields in a cert or CRL, to address the question of which combinations of fields and values are valid. One cannot do this for really private extensions, and doing it for new extensions that are publicly disclosed is an ongoing task. But, at least we should provide folks with a base set of constraints. I think 2459 should do this and I volunteered to provide a draft table for this. Steve --============_-1245062893==_ma============-- Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA10635 for ; Wed, 23 Aug 2000 11:29:38 -0700 (PDT) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 11:25:44 -0700 Message-ID: <69A40A314934D41190C70050DAD7F99063B587@MAIL> From: Mathew Butler To: "'judith.spencer@gsa.gov'" , William.Flanigan@bmdo.osd.mil Cc: pbaker@verisign.com, terri.hobson@gsa.gov, marion.royal@gsa.gov, ietf-pkix@imc.org Subject: RE: President Clinton digital signing Date: Wed, 23 Aug 2000 11:25:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA10636 The question is, "Is there some certification authority that was designated by [whoever has the power to make the designation, be it Congress or the GSA or the GAO or whoever], that signed the certificate that President Clinton used to sign the bill, in order to ensure the authenticity and integrity of the signature [in order to make it legally binding]?" I know that there is nothing in law (even with the signing of this bill) that allows the President to ratify a bill with anything other than a physical signature and seal. Therefore, the entire question is completely ludicrous in the first place, as the answer is patently "No". However, there's a few questions I have... what CA -did- sign the certificate that President Clinton used? Is there an actual copy of the electronically signed version of the bill, including signature, online that we can look at? Also, can we get a copy of the certificate that he used, along with the entire certificate chain to the certificate for the root? (Rather than spamming the list, is there a URL on the GSA's website that would provide access to this information?) Thanks! -Mat Butler -----Original Message----- From: judith.spencer@gsa.gov [mailto:judith.spencer@gsa.gov] Sent: Wednesday, August 23, 2000 9:55 AM To: William.Flanigan@bmdo.osd.mil Cc: pbaker@verisign.com; terri.hobson@gsa.gov; judith.spencer@gsa.gov; marion.royal@gsa.gov; ietf-pkix@imc.org Subject: RE: President Clinton digital signing The e-signing of the bill was a demonstration of the technology. You're right. The bill was officially signed with a pen and then a wax seal was applied. I'm having a little trouble with your "circular reference" statement and that the bill is a "self-signed certificate". Perhaps you'd be willing to explain your reasoning to me more fully. Judy Spencer "Flanigan, William, CIV,BMDO/DSC" on 08/23/2000 09:37:06 AM To: "'Philip Hallam-Baker'" cc: terri.hobson@gsa.gov, judith.spencer@gsa.gov, "'marion.royal@gsa.gov'" , ietf-pkix@imc.org Subject: RE: President Clinton digital signing Right on Philip (as usual)!  But it seems unlikely that the bill was not "signed" twice, one being a wet signature (with no photo op).  Does anyone know for sure? Bill Flanigan -----Original Message----- From: Philip Hallam-Baker [mailto:pbaker@verisign.com] Sent: Tuesday, August 22, 2000 9:08 PM To: 'marion.royal@gsa.gov'; ietf-pkix@imc.org Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov Subject: RE: President Clinton digital signing [snip] And it was totally illogical to use a digital signature for the purpose. The act is now effectively a self-signed cert! The validity of the authentication on the act is established through a circular reference to the act itself.               Phill Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA09439 for ; Wed, 23 Aug 2000 11:12:01 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 23 Aug 2000 12:11:52 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 23 Aug 2000 12:11:53 -0600 From: "Bob Jueneman" To: , Cc: Subject: OCSP vs. CRLs Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_1E468EF8.A7C6A346" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_1E468EF8.A7C6A346 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable As one of the original proponents (with Sead Muftic) of an on-line = document (not certificate) validation service, I'd like to support Steve's = assertion that "it depends" on whether OCSP is "better" than CRLs. I contend that it is very important to carefully consider the risk, the = computational load imposed on the server, the "freshness" of either the = CRL or OCSP response, the availability of caching, and most importantly, = the availability of full-time available connections in coming to that = decision. If updated CRLs are reliably made available to anyone who inquires as soon = as the decision to revoke a certificate is made, then I would argue that = they are nearly as good as OCSP. (Not quite as good, because OCSP at = least provides the option of including the hash of the document in = question, which avoids all sorts of time-stamping issues. But it isn't = clear that OCSP in fact does that.) However, the overhead of OCSP in terms of both server computational load = and bandwidth makes it completely ridiculous to even consider for certain = applications. For example, suppose that every .EXE and .DLL in Windows = was signed by Microsoft, and that the loader validated that signature = every time the module was invoked. Obviously this would be helpful in = preventing certain classes of viruses, right? And arguably, at least, it = would be desirable for the certificate chain to be checked to make sure = that the signing key hadn't been compromised, or that Microsoft was no = longer Microsoft, but was now a Baby Bill. But going back to the CA every time a module was invoked would obviously = bring the user's computer, the Internet, and VeriSign to its knees, in = that order. OK, so maybe we don't check it every time -- maybe just when = booting up, or every 24 hours. In other words, "I didn't mean THAT = real-time!" But in that case, a CRL would do equally well, and in fact = better, since CRLS can be cached locally in any of a number of different = ways. Now consider the case of the Navy, steaming around the ocean during either = peacetime or wartime. On a carrier, there are lots of sailors, and they = may need to either encrypt or sign e-mail. They may also receive e-mail = from home, or from shore-based installations. But in general, the CAs are = not part of the fleet, they are in San Diego, or Norfolk, or at Ft. Meade, = or somewhere else back on shore. Do you suppose that those ships would be willing to waste their very = precious bandwidth going back to shore via OCSP to revalidate the = certificate status of say the Chief of Naval Operations, if he sends out a = message or order to everyone in the fleet? Or to validate the certificate = of someone on-board that ship? I certainly don't think so. Instead, a = cached CRL that is updated once a day or even once a week would be = perfectly adequate, and highly preferable. There are many other instances where the requirement for up-to-the-nanoseco= nd validation of a certificate, or even a particular transaction, is = simply not justified. In fact, given all of the other safeguards and = legal back-stops that exist, the need for such verification is more likely = NOT to be the case. I'm not saying that OCSP is of no value, nor am I saying that CRLs are = invariable superior. Or vice versa. "It depends." Bob >>> Stephen Kent 08/23/00 08:03AM >>> Tom, >Hello Ambarish, > >Thanks for your reply. I agree that OCSP services are by far better than >CRLs. I think this is an over generalization, i.e., OCSP is bettr in some=20 cases, but not in all cases. >In general, as everyone knows, a CRL is a batch job that updates a >database over certain intervals. From an audit standpoint, one of the = many >issues with CRLs is that they can be beat. For example, it is very easy = to >perform any series of denial of service attacks against the server. Which server? A directory? A CRL has the advantage that it can be=20 replicated at any numnber of servers, without imbuing these serves=20 with trust (re integrity and authenticity). While it is certainly=20 true that one can engage in a DoS attack against directories, the=20 same is also true for OCSP servers. I don't think we have enough=20 experience with both types of servers to determine if one is more=20 susceptible than the other, as a class, or if it's just an issue of=20 implementation and local management quality. >This >could cause longer than expected delays in the execution of the batch job >or worse, prevent the batch job from running causing latent (or corrupted)= >CRL publishing. Batch job? Now it sounds like your talking about a CA preparing a=20 CRL. A CA component generating a CRL need not be online and thus=20 need not be very susceptible to DoS attacks, so I'm puzzled by this=20 line of reasoning. >Also, if someone is savvy enough, they could also issue >hundreds of back to back CRL job requests resulting in multiple jobs >waiting on shared services again causing problematic CRLs. I know this = may >sound farfetched but they are risks to be considered. CRL job requests? I've been involved with the design of several CAs=20 over time and none offered an external interface which could be=20 manipulated inthe fashion you suggest. >As you may guess I am not a proponent of CRLs for obvious reasons. I have >heard claims by some that their products are OCSP compliant. In reality = it >is just a batch job publishing to a database but still they have inherent >CRL batch job latency. The latency issue re CRLs is a red herring, in almost all cases. The=20 time required to generate a CRL is fairly small for almost any PKI of=20 a reasonable size. The external, non-technical factors associated=20 with deciding that a compromise has occurred or that an attribute has=20 changed and thus a cert should be revoked almost always swamp the CRL=20 production activity. >As for the CAM, I am not familiar enough with that to argue for or = against >its use. I do know however that the Xcert product has a non proprietary >real time OCSP LDAP out of the box resulting in a more robust product. = Note >that the Sentry CA product can publish CRLs to non OCSP products to offer >backwards compatibility when needed. Also, the Sentry product can import >other vendors CRLs and place them in the real time OCSP LDAP. Oh, OCSp and LDAP? That combination suggests an DoS opportunity that=20 might be the sum of the two server interfaces :-). >Also one of the several reasons that Sentry CA was chosen was due to its >ability to cross certify against other CAs (cross certification). It is >very easy to setup trust to another company's CA allowing multiple CAs or >PKI vendors within a central Sentry OCSP environment. No more product endorsements, OK? Steve --=_1E468EF8.A7C6A346 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As one of the original proponents (with Sead Muftic) = of an=20 on-line document (not certificate) validation service, I'd like to sup= port=20 Steve's assertion that "it depends" on whether OCSP is "better" than=20 CRLs.
 
I contend that it is very important to carefully = consider the=20 risk, the computational load imposed on the server, the "freshness" of = either=20 the CRL or OCSP response, the availability of caching, and most importantly= , the=20 availability of full-time available connections in coming to that=20 decision.
 
If updated CRLs are reliably made available to anyone = who=20 inquires as soon as the decision to revoke a certificate is made, then I = would=20 argue that they are nearly as good as OCSP.  (Not quite as good, = because=20 OCSP at least provides the option of including the hash of the document = in=20 question, which avoids all sorts of time-stamping issues. But it isn't = clear=20 that OCSP in fact does that.)
 
However, the overhead of OCSP in terms of both = server=20 computational load and bandwidth makes it completely ridiculous to even = consider=20 for certain applications.  For example, suppose that every .EXE and = .DLL in=20 Windows was signed by Microsoft, and that the loader validated that = signature=20 every time the module was invoked.  Obviously this would be = helpful=20 in preventing certain classes of viruses, right?  And arguably, at = least,=20 it would be desirable for the certificate chain to be checked to make sure = that=20 the signing key hadn't been compromised, or that Microsoft was no = longer=20 Microsoft, but was now a Baby Bill.
 
But going back to the CA every time a module was = invoked would=20 obviously bring the user's computer, the Internet, and VeriSign to its = knees, in=20 that order.  OK, so maybe we don't check it every time -- maybe just = when=20 booting up, or every 24 hours.  In other words, "I didn't mean = THAT=20 real-time!"  But in that case, a CRL would do equally well, and in = fact=20 better, since CRLS can be cached locally in any of a number of different=20= ways.
 
Now consider the case of the Navy, steaming around the = ocean=20 during either peacetime or wartime.  On a carrier, there are lots = of=20 sailors, and they may need to either encrypt or sign e-mail.  They = may also=20 receive e-mail from home, or from shore-based installations.  But = in=20 general, the CAs are not part of the fleet, they are in San Diego, or = Norfolk,=20 or at Ft. Meade, or somewhere else back on shore.
 
Do you suppose that those ships would be willing to = waste=20 their very precious bandwidth going back to shore via OCSP to revalidate = the=20 certificate status of say the Chief of Naval Operations, if he sends out = a=20 message or order to everyone in the fleet?  Or to validate the = certificate=20 of someone on-board that ship? I certainly don't think so.  Instead, = a=20 cached CRL that is updated once a day or even once a week would be = perfectly=20 adequate, and highly preferable.
 
There are many other instances where the requirement = for=20 up-to-the-nanosecond validation of a certificate, or even a particular=20 transaction, is simply not justified.  In fact, given all of the = other=20 safeguards and legal back-stops that exist, the need for such verification = is=20 more likely NOT to be the case.
 
I'm not saying that OCSP is of no value, nor am I = saying that=20 CRLs are invariable superior.  Or vice versa.
 
"It depends."
 
Bob
 
 
>>> Stephen Kent <kent@bbn.com> 08/23/00 08:03AM=20 >>>
Tom,

>Hello Ambarish,
>
>Thanks for = your=20 reply. I agree that OCSP services are by far better than
>CRLs.
I=20 think this is an over generalization, i.e., OCSP is bettr in some =
cases, but=20 not in all cases.

>In general, as everyone knows, a CRL is a = batch job=20 that updates a
>database over certain intervals. From an audit = standpoint,=20 one of the many
>issues with CRLs is that they can be beat. For = example,=20 it is very easy to
>perform any series of denial of service = attacks=20 against the server.

Which server? A directory?  A CRL has = the=20 advantage that it can be
replicated at any numnber of servers, = without=20 imbuing these serves
with trust (re integrity and authenticity).  = While=20 it is certainly
true that one can engage in  a DoS attack = against=20 directories, the
same is also true for OCSP servers. I don't think we = have=20 enough
experience with both types of servers to determine if one is = more=20
susceptible than the other, as a class, or if it's just an issue of=20
implementation and local management quality.

>This
>cou= ld=20 cause longer than expected delays in the execution of the batch job
>= or=20 worse, prevent the batch job from running causing latent (or=20 corrupted)
>CRL publishing.

Batch job?  Now it sounds = like=20 your talking about a CA preparing a
CRL.  A CA component = generating a=20 CRL need not be online and thus
need not be very susceptible to DoS = attacks,=20 so I'm puzzled by this
line of reasoning.

>Also, if someone = is=20 savvy enough, they could also issue
>hundreds of back to back CRL = job=20 requests resulting in multiple jobs
>waiting on shared services = again=20 causing problematic CRLs. I know this may
>sound farfetched but they = are=20 risks to be considered.

CRL job requests?  I've been involved = with=20 the design of several CAs
over time and none offered an external = interface=20 which could be
manipulated inthe fashion you suggest.

>As = you may=20 guess I am not a proponent of CRLs for obvious reasons. I have
>heard= =20 claims by some that their products are OCSP compliant. In reality = it
>is=20 just a batch job publishing to a database but still they have=20 inherent
>CRL batch job latency.

The latency issue re CRLs is = a red=20 herring, in almost all cases. The
time required to generate a CRL is = fairly=20 small for almost any PKI of
a reasonable size.  The external,=20 non-technical factors associated
with deciding that a compromise = has=20 occurred or that an attribute has
changed and thus a cert should be = revoked=20 almost always swamp the CRL
production activity.

>As for the = CAM,=20 I am not familiar enough with that to argue for or against
>its use. = I do=20 know however that the Xcert product has a non proprietary
>real time = OCSP=20 LDAP out of the box resulting in a more robust product. Note
>that = the=20 Sentry CA product can publish CRLs to non OCSP products to=20 offer
>backwards compatibility when needed. Also, the Sentry product = can=20 import
>other vendors CRLs and place them in the real time OCSP=20 LDAP.

Oh, OCSp and LDAP?  That combination suggests an DoS=20 opportunity that
might be the sum of the two server interfaces=20 :-).

>Also one of the several reasons that Sentry CA was chosen = was=20 due to its
>ability to cross certify against other CAs (cross=20 certification). It is
>very easy to setup trust to another company's = CA=20 allowing multiple CAs or
>PKI vendors within a central Sentry = OCSP=20 environment.


No more product endorsements,=20 OK?

Steve

--=_1E468EF8.A7C6A346-- Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06819 for ; Wed, 23 Aug 2000 10:12:05 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 13:12:04 -0400 Message-ID: <3120721CA75DD411B8340090273D20B1271F0E@sottmxs06.entrust.com> From: Sharon Boeyen To: "'d.w.chadwick@salford.ac.uk'" , ietf-pkix@imc.org Cc: "Kurt D. Zeilenga" , osidirectory@az05.bull.com Subject: RE: Undefined combinations of extensions Date: Wed, 23 Aug 2000 13:07:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" The defect report is clarifying, not changing, the way criticality is treated for certificate extensions. Criticality applies to each extension independent of all others. Clearly, if one extension is included in a certificate as critical (e.g. certificate policies) and another is included as non-critical (e.g. policy mappings), then there will be different results by relying party systems that do support policy mappings and ones that do not. However, there should be no difference in relying party systems that do support the extensions regardless of their criticality. A CA sets the criticality flag for each and every extension as it sees fit. By setting an extension non-critical, the CA is accepting the fact that relying party systems that do not understand this extension will ignore it when processing the certificate and relying party systems that do understand it will process it. When it sets the flag critical it is limiting the relying parties to ONLY those that understand the extension. Any semantic relationship between two or more extensions (e.g. among the policy related ones) needs to be addressed by the issuer (for instance it doesn't make a lot of sense to issue a certificate with critical policy mappings but non-critical certificate policies). This is a policy issue though not one that the criticality flag should be used to solve. If there is a situation where two extensions may cause conflicting impacts (e.g. the issuingDistributionPoint extension and the crlScope extension), then the definition of the extensions themselves should contain the semantics of what is to be done (see the definition of crlScope which states that these 2 are not intended to be used together but states what the rule is if both happen to be present). If the problem you are trying to solve is that extensions have not been properly or fully defined, then that problem should be fixed in the extension definitions themselves, not by trying to invert the meaning of critical and non critical in the standard. Is there a concrete example you can share, that might bring to light some point I'm missing? Sharon > -----Original Message----- > From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk] > Sent: Wednesday, August 23, 2000 12:36 PM > To: ietf-pkix@imc.org > Cc: Kurt D. Zeilenga; osidirectory@az05.bull.com > Subject: Undefined combinations of extensions > > > On the LDAPExt list we have been discussing the effects of > combinations of extensions (controls in LDAP jargon) on the LDAP > server performing an LDAP operation, when the effects of the > combination of one or more extensions is not understood by the > server. The server may understand each separate extension, but > not the semantics of them in combination. > > It seems to me that PKIX/X.509 will have (or already may have > encountered) this same problem for COMBINATIONS of certificate > extensions (some of which may be private, some de-facto, some > critical, some not) that are thought to be understood by the issuing > CA, but are not fully understood by the relying party / validation > engine. > > What text does anyone have for this situation? I believe the recently > issued X.509 defect report 244, raised by Sharon, only discusses > the case of a single extension in isolation, and does not discuss the > effects of combinations of extensions. > > The most interesting cases are when the RP finds combinations of > extensions, where each extension on its own is understood, but > where the combined semantics are not fully understood (possibly > due to incomplete or ambiguous specification of extension > interactions when the extensions are written by different > groups). In > this case, LDAP is suggesting that a receiver may ignore non- > critical extensions (even those it recognizes) to establish the > semantics of the operation. This is in direct contrast to the wording > of defect report 244, which states that an understood non-critical > extension must be obeyed. The LDAP work would suggest an > addition to DR244 along the lines of > > " A validation engine that does not understand the interaction of a > non-critical extension with another extension (critical or > non-critical), > may ignore the non-critical extension (even if it understands the > semantics of the extension in isolation to the others), and > accept the > certificate (unless factors other than this extension cause it to be > rejected). > > A validation engine that does not understand the interaction of two > critical extensions, must reject the certificate (even if it > understands > the semantics of both extensions in isolation to each other)." > > David > > > > *************************************************** > > David Chadwick > IS Institute, University of Salford, Salford M5 4WT > Tel +44 161 295 5351 Fax +44 161 745 8169 > Mobile +44 790 167 0359 > Email D.W.Chadwick@salford.ac.uk > Home Page http://www.salford.ac.uk/its024/chadwick.htm > Understanding X.500 http://www.salford.ac.uk/its024/X500.htm > X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm > Entrust key validation string MLJ9-DU5T-HV8J > > *************************************************** > Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06048 for ; Wed, 23 Aug 2000 10:03:35 -0700 (PDT) Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 13:03:26 -0400 Message-ID: From: Khaja Ahmed To: "'Stephen Kent'" , Tom Strickland , ietf-pkix@imc.org Subject: RE: President Clinton digital signing Date: Wed, 23 Aug 2000 13:03:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00D24.0CB58C50" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C00D24.0CB58C50 Content-Type: text/plain; charset="iso-8859-1" Re Steve's point that CRLs can be replicated at any number of servers... It is also possible to have a number of OCSP servers that get CRLs fed to them based on which they respond to OCSP requests. Unless I am much mistaken, nothing in the OCSP protocol prevents an OCSP server from having a distributed / widely replicated presence. While this is more expensive** than having CRLs available at multiple servers it offers the advantages that are associated with getting OCSP responses rather than CRLs to a relying party. In some cases this may be quite acceptable. Khaja ** An OCSP server has security requirements and performance requirements that do not get imposed on a web server that simply has a CRL available for download. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Wednesday, August 23, 2000 7:03 AM To: Tom Strickland Cc: ietf-pkix@imc.org Subject: Re: President Clinton digital signing Tom, >Hello Ambarish, > >Thanks for your reply. I agree that OCSP services are by far better than >CRLs. I think this is an over generalization, i.e., OCSP is bettr in some cases, but not in all cases. >In general, as everyone knows, a CRL is a batch job that updates a >database over certain intervals. From an audit standpoint, one of the many >issues with CRLs is that they can be beat. For example, it is very easy to >perform any series of denial of service attacks against the server. Which server? A directory? A CRL has the advantage that it can be replicated at any numnber of servers, without imbuing these serves with trust (re integrity and authenticity). While it is certainly true that one can engage in a DoS attack against directories, the same is also true for OCSP servers. I don't think we have enough experience with both types of servers to determine if one is more susceptible than the other, as a class, or if it's just an issue of implementation and local management quality. >This >could cause longer than expected delays in the execution of the batch job >or worse, prevent the batch job from running causing latent (or corrupted) >CRL publishing. Batch job? Now it sounds like your talking about a CA preparing a CRL. A CA component generating a CRL need not be online and thus need not be very susceptible to DoS attacks, so I'm puzzled by this line of reasoning. >Also, if someone is savvy enough, they could also issue >hundreds of back to back CRL job requests resulting in multiple jobs >waiting on shared services again causing problematic CRLs. I know this may >sound farfetched but they are risks to be considered. CRL job requests? I've been involved with the design of several CAs over time and none offered an external interface which could be manipulated inthe fashion you suggest. >As you may guess I am not a proponent of CRLs for obvious reasons. I have >heard claims by some that their products are OCSP compliant. In reality it >is just a batch job publishing to a database but still they have inherent >CRL batch job latency. The latency issue re CRLs is a red herring, in almost all cases. The time required to generate a CRL is fairly small for almost any PKI of a reasonable size. The external, non-technical factors associated with deciding that a compromise has occurred or that an attribute has changed and thus a cert should be revoked almost always swamp the CRL production activity. >As for the CAM, I am not familiar enough with that to argue for or against >its use. I do know however that the Xcert product has a non proprietary >real time OCSP LDAP out of the box resulting in a more robust product. Note >that the Sentry CA product can publish CRLs to non OCSP products to offer >backwards compatibility when needed. Also, the Sentry product can import >other vendors CRLs and place them in the real time OCSP LDAP. Oh, OCSp and LDAP? That combination suggests an DoS opportunity that might be the sum of the two server interfaces :-). >Also one of the several reasons that Sentry CA was chosen was due to its >ability to cross certify against other CAs (cross certification). It is >very easy to setup trust to another company's CA allowing multiple CAs or >PKI vendors within a central Sentry OCSP environment. No more product endorsements, OK? Steve ------_=_NextPart_001_01C00D24.0CB58C50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: President Clinton digital signing

Re Steve's point that CRLs can be replicated at any = number of servers...

It is also possible to have a number of OCSP servers = that get CRLs fed to them based on which they respond to OCSP = requests.  Unless I am much mistaken, nothing in the OCSP protocol = prevents an OCSP server from having a distributed / widely replicated = presence.

While this is more expensive** than having CRLs = available at multiple servers it offers the advantages that are = associated with getting OCSP responses rather than CRLs to a relying = party.  In some cases this may be quite acceptable.

Khaja

** An OCSP server has security requirements and = performance requirements that do not get imposed on a web server that = simply has a CRL available for download.


-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Wednesday, August 23, 2000 7:03 AM
To: Tom Strickland
Cc: ietf-pkix@imc.org
Subject: Re: President Clinton digital = signing


Tom,

>Hello Ambarish,
>
>Thanks for your reply. I agree that OCSP = services are by far better than
>CRLs.

I think this is an over generalization, i.e., OCSP is = bettr in some
cases, but not in all cases.

>In general, as everyone knows, a CRL is a batch = job that updates a
>database over certain intervals. From an audit = standpoint, one of the many
>issues with CRLs is that they can be beat. For = example, it is very easy to
>perform any series of denial of service attacks = against the server.

Which server? A directory?  A CRL has the = advantage that it can be
replicated at any numnber of servers, without = imbuing these serves
with trust (re integrity and authenticity).  = While it is certainly
true that one can engage in  a DoS attack = against directories, the
same is also true for OCSP servers. I don't think we = have enough
experience with both types of servers to determine = if one is more
susceptible than the other, as a class, or if it's = just an issue of
implementation and local management quality.

>This
>could cause longer than expected delays in the = execution of the batch job
>or worse, prevent the batch job from running = causing latent (or corrupted)
>CRL publishing.

Batch job?  Now it sounds like your talking = about a CA preparing a
CRL.  A CA component generating a CRL need not = be online and thus
need not be very susceptible to DoS attacks, so I'm = puzzled by this
line of reasoning.

>Also, if someone is savvy enough, they could also = issue
>hundreds of back to back CRL job requests = resulting in multiple jobs
>waiting on shared services again causing = problematic CRLs. I know this may
>sound farfetched but they are risks to be = considered.

CRL job requests?  I've been involved with the = design of several CAs
over time and none offered an external interface = which could be
manipulated inthe fashion you suggest.

>As you may guess I am not a proponent of CRLs for = obvious reasons. I have
>heard claims by some that their products are = OCSP compliant. In reality it
>is just a batch job publishing to a database but = still they have inherent
>CRL batch job latency.

The latency issue re CRLs is a red herring, in almost = all cases. The
time required to generate a CRL is fairly small for = almost any PKI of
a reasonable size.  The external, non-technical = factors associated
with deciding that a compromise has occurred or that = an attribute has
changed and thus a cert should be revoked almost = always swamp the CRL
production activity.

>As for the CAM, I am not familiar enough with = that to argue for or against
>its use. I do know however that the Xcert = product has a non proprietary
>real time OCSP LDAP out of the box resulting in = a more robust product. Note
>that the Sentry CA product can publish CRLs to = non OCSP products to offer
>backwards compatibility when needed. Also, the = Sentry product can import
>other vendors CRLs and place them in the real = time OCSP LDAP.

Oh, OCSp and LDAP?  That combination suggests an = DoS opportunity that
might be the sum of the two server interfaces = :-).

>Also one of the several reasons that Sentry CA = was chosen was due to its
>ability to cross certify against other CAs = (cross certification). It is
>very easy to setup trust to another company's CA = allowing multiple CAs or
>PKI vendors within a central Sentry OCSP = environment.


No more product endorsements, OK?

Steve

------_=_NextPart_001_01C00D24.0CB58C50-- Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA06004 for ; Wed, 23 Aug 2000 10:03:30 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 23 Aug 2000 11:03:14 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 23 Aug 2000 11:03:10 -0600 From: "Bob Jueneman" To: , Cc: Subject: RE: President Clinton digital signing Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_346CA4C2.29482D28" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_346CA4C2.29482D28 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I believe that the bill was in fact signed twice, once with a pen, but I = also believe that the concern about circularity is a red herring.=20 I would argue that it is the President's approval , rather than his = signature, that causes a Bill to become law. His signature is but one of = many means of evidencing and memorializing that approval -- witnesses, = photo ops, etc., could very reasonably be considered evidence of such = approval as well, and would actually be far more compelling than the = mechanical pen signature that I understand is routinely used for bills of = less than stellar significance.=20 In any case, because he didn't veto the bill and return it to the = Congress, it would have become binding within ten days in any case, except = if it had occurred at the end of the Congressional term (a "pocket veto"), = which was not the case.=20 So it would have become the law of the land no matter how it was signed, = or absent any signature at all.=20 Article I, Section 7 of the Constitution of the United states reads as = follows:=20 Section. 7. All Bills for raising Revenue shall originate in the=20 House of Representatives; but the Senate may propose or concur with=20 amendments as on other Bills.=20 Every Bill which shall have passed the House of Representatives=20 and the Senate, shall, before it become a law, be presented to the=20 President of the United States: If he approve he shall sign it, but if=20 not he shall return it, with his Objections to that House in which it=20 shall have originated, who shall enter the Objections at large on their=20 Journal, and proceed to reconsider it. If after such Reconsideration = two=20 thirds of that House shall agree to pass the Bill, it shall be sent,=20 together with the Objections, to the other House, by which it shall=20 likewise be reconsidered, and if approved by two thirds of that House,=20 it shall become a Law. But in all such Cases the Votes of both Houses=20 shall be determined by Yeas and Nays, and the Names of the Persons=20 voting for and against the Bill shall be entered on the Journal of each=20 House respectively. If any Bill shall not be returned by the President=20 within ten Days (Sundays excepted) after it shall have been presented = to=20 him, the Same shall be a Law, in like Manner as if he had signed it,=20 unless the Congress by their Adjournment prevent its Return, in which=20 Case it shall not be a Law=20 Every Order, Resolution, or Vote to which the Concurrence of the=20 Senate and House of Representatives may be necessary (except on a=20 question of Adjournment) shall be presented to the President of the=20 United States; and before the Same shall take Effect, shall be approved=20 by him, or being disapproved by him, shall be repassed by two thirds of=20 the Senate and House of Representatives, according to the Rules and=20 Limitations prescribed in the Case of a Bill.=20 The merits of the bill, however, are a different issue.=20 Bob=20 >>>< William.Flanigan@bmdo.osd.mil > 08/23/00 07:37AM >>>=20 Right on Philip (as usual)! But it seems unlikely that the bill was not = "signed" twice, one being a wet signature (with no photo op). Does anyone = know for sure?=20 Bill Flanigan=20 -----Original Message-----=20 From: Philip Hallam-Baker [ mailto:pbaker@verisign.com=20 Sent: Tuesday, August 22, 2000 9:08 PM=20 To: ' marion.royal@gsa.gov' ; ietf-pkix@imc.org=20 Cc: terri.hobson@gsa.gov ; judith.spencer@gsa.gov=20 Subject: RE: President Clinton digital signing=20 [snip]=20 And it was totally illogical to use a digital signature for the purpose.=20= The act is now effectively a self-signed cert! The validity of the=20 authentication on the act is established through a circular reference=20 to the act itself.=20 Phill=20 --=_346CA4C2.29482D28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I believe that the bill was in fact signed twice, once with a = pen, but I=20 also believe that the concern about circularity is a red herring. =

I=20 would argue that it is the President's approval , rather than = his=20 signature, that causes a Bill to become law. His signature is but one of = many=20 means of evidencing and memorializing that approval -- witnesses, photo = ops,=20 etc., could very reasonably be considered evidence of such approval as = well, and=20 would actually be far more compelling than the mechanical pen signature = that I=20 understand is routinely used for bills of less than stellar significance.= =20

In any case, because he didn't veto the bill and return it to = the=20 Congress, it would have become binding within ten days in any case, except = if it=20 had occurred at the end of the Congressional term (a "pocket veto"), which = was=20 not the case.

So it would have become the law of the land no = matter how=20 it was signed, or absent any signature at all.

Article I, Section = 7 of=20 the Constitution of the United states reads as follows:

Section. = 7. All=20 Bills for raising Revenue shall originate in the
House of Representativ= es;=20 but the Senate may propose or concur with
amendments as on other = Bills.=20
Every Bill which shall have passed the = House of=20 Representatives
and the Senate, shall, before it become a law, be = presented=20 to the
President of the United States: If he approve he shall sign = it,=20 but if
not he shall return it, with = his=20 Objections to that House in which it
shall have originated, who shall = enter=20 the Objections at large on their
Journal, and proceed to reconsider = it. If=20 after such Reconsideration two
thirds of that House shall agree to = pass the=20 Bill, it shall be sent,
together with the Objections, to the other = House, by=20 which it shall
likewise be reconsidered, and if approved by two thirds = of=20 that House,
it shall become a Law. But in all such Cases the Votes of = both=20 Houses
shall be determined by Yeas and Nays, and the Names of the = Persons=20
voting for and against the Bill shall be entered on the Journal of = each=20
House respectively. If any Bill shall = not be=20 returned by the President
within ten Days (Sundays excepted) after it = shall=20 have been presented to
him, the Same shall be a Law, in like Manner as = if he=20 had signed it,
unless the Congress by = their=20 Adjournment prevent its Return, in which
Case it shall not be a Law=20
Every Order, Resolution, or Vote to which the Concurrence of the =
Senate=20 and House of Representatives may be necessary (except on a
question = of=20 Adjournment) shall be presented to the = President of=20 the
United States; and before the Same shall take Effect, shall be = approved=20
by him, or being disapproved by him, = shall be=20 repassed by two thirds of
the Senate and House of Representatives, = according=20 to the Rules and
Limitations prescribed in the Case of a Bill.=20


The merits of the bill, however, are a different issue.=20


Bob


>>>< William.Flanigan@bmdo.osd.mil= =20 > 08/23/00 07:37AM >>>


Right on Philip (as usual)! = But=20 it seems unlikely that the bill was not "signed" twice, one being a wet=20 signature (with no photo op). Does anyone know for sure?
Bill = Flanigan=20
-----Original Message-----
From: Philip Hallam-Baker [ mailto:pbaker@verisign.com =
Sent:=20 Tuesday, August 22, 2000 9:08 PM
To: ' marion.royal@gsa.gov' ; = ietf-pkix@imc.org
Cc: = terri.hobson@gsa.gov ; = judith.spencer@gsa.gov =
Subject:=20 RE: President Clinton digital signing
[snip]
And it was totally=20 illogical to use a digital signature for the purpose.
The act is = now=20 effectively a self-signed cert! The validity of the
authentication on = the=20 act is established through a circular reference
to the act itself.=20

Phill
--=_346CA4C2.29482D28-- Received: from scog-ws3.gsa.gov (host.159-142-144-58.gsa.gov [159.142.144.58]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA05313 for ; Wed, 23 Aug 2000 09:55:03 -0700 (PDT) From: judith.spencer@gsa.gov Received: from 159.142.144.55 by scog-ws3.gsa.gov with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Wed, 23 Aug 2000 12:55:25 -0400 X-Server-Uuid: cb2f616c-ae65-11d3-874c-00508b6362bc Subject: RE: President Clinton digital signing To: William.Flanigan@bmdo.osd.mil cc: pbaker@verisign.com, terri.hobson@gsa.gov, judith.spencer@gsa.gov, marion.royal@gsa.gov, ietf-pkix@imc.org Sender: judith.spencer@gsa.gov Date: Wed, 23 Aug 2000 12:55:14 -0400 Message-ID: X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on SCOG-NOTESSMTP1/GSAEXTERNAL(Release 5.0.1b|September 30, 1999) at 08/23/2000 12:55:25 PM MIME-Version: 1.0 X-WSS-ID: 15BADE76137946-03-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA05314 The e-signing of the bill was a demonstration of the technology. You're right. The bill was officially signed with a pen and then a wax seal was applied. I'm having a little trouble with your "circular reference" statement and that the bill is a "self-signed certificate". Perhaps you'd be willing to explain your reasoning to me more fully. Judy Spencer "Flanigan, William, CIV,BMDO/DSC" on 08/23/2000 09:37:06 AM To: "'Philip Hallam-Baker'" cc: terri.hobson@gsa.gov, judith.spencer@gsa.gov, "'marion.royal@gsa.gov'" , ietf-pkix@imc.org Subject: RE: President Clinton digital signing Right on Philip (as usual)!  But it seems unlikely that the bill was not "signed" twice, one being a wet signature (with no photo op).  Does anyone know for sure? Bill Flanigan -----Original Message----- From: Philip Hallam-Baker [mailto:pbaker@verisign.com] Sent: Tuesday, August 22, 2000 9:08 PM To: 'marion.royal@gsa.gov'; ietf-pkix@imc.org Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov Subject: RE: President Clinton digital signing [snip] And it was totally illogical to use a digital signature for the purpose. The act is now effectively a self-signed cert! The validity of the authentication on the act is established through a circular reference to the act itself.               Phill Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05083 for ; Wed, 23 Aug 2000 09:54:20 -0700 (PDT) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0FZR00A018BA1E@ext-mail.valicert.com> for ietf-pkix@imc.org; Wed, 23 Aug 2000 09:54:46 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0FZR0095F8BASG@ext-mail.valicert.com>; Wed, 23 Aug 2000 09:54:46 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 09:44:38 -0700 Content-return: allowed Date: Wed, 23 Aug 2000 09:44:35 -0700 From: Peter Williams Subject: RE: Undefined combinations of extensions To: "'d.w.chadwick@salford.ac.uk'" , ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE201C08720@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" 5 years ago, based on academic research, I specified a pre-PKIX1 PKI architecture in which variations of the X.500 structure and content rules were applied to certificate extensions to address this problem; It was 5 year too early (like many of the things I do.) The architecture exploited all the work of hierarchical distributed schema specification, delegation and administration accomplished by X.500 design for controlling the security of distributed directories. The objects controlled happened to be extensions, versus attributes of entries, but the security management properties were the same. Perhaps you could reuse this idea, and invent something? Perhaps the time has come, now that chains are beginning to matter. Even better, as trusted directories are now coming to the fore (based on modern X.500's standardization of distributed directory security techniques), perhaps we should make the directory the host for the schema rules controlling cert extensions - rather than embedding the structure/content rule in the superior certificate of a chain. -----Original Message----- From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk] Sent: Wednesday, August 23, 2000 9:36 AM To: ietf-pkix@imc.org Cc: Kurt D. Zeilenga; osidirectory@az05.bull.com Subject: Undefined combinations of extensions On the LDAPExt list we have been discussing the effects of combinations of extensions (controls in LDAP jargon) on the LDAP server performing an LDAP operation, when the effects of the combination of one or more extensions is not understood by the server. The server may understand each separate extension, but not the semantics of them in combination. It seems to me that PKIX/X.509 will have (or already may have encountered) this same problem for COMBINATIONS of certificate extensions (some of which may be private, some de-facto, some critical, some not) that are thought to be understood by the issuing CA, but are not fully understood by the relying party / validation engine. What text does anyone have for this situation? I believe the recently issued X.509 defect report 244, raised by Sharon, only discusses the case of a single extension in isolation, and does not discuss the effects of combinations of extensions. The most interesting cases are when the RP finds combinations of extensions, where each extension on its own is understood, but where the combined semantics are not fully understood (possibly due to incomplete or ambiguous specification of extension interactions when the extensions are written by different groups). In this case, LDAP is suggesting that a receiver may ignore non- critical extensions (even those it recognizes) to establish the semantics of the operation. This is in direct contrast to the wording of defect report 244, which states that an understood non-critical extension must be obeyed. The LDAP work would suggest an addition to DR244 along the lines of " A validation engine that does not understand the interaction of a non-critical extension with another extension (critical or non-critical), may ignore the non-critical extension (even if it understands the semantics of the extension in isolation to the others), and accept the certificate (unless factors other than this extension cause it to be rejected). A validation engine that does not understand the interaction of two critical extensions, must reject the certificate (even if it understands the semantics of both extensions in isolation to each other)." David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA04520 for ; Wed, 23 Aug 2000 09:44:48 -0700 (PDT) Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 12:44:25 -0400 Message-ID: From: Khaja Ahmed To: "'Liaquat Khan'" , ietf-pkix@imc.org Subject: RE: President Clinton digital signing Date: Wed, 23 Aug 2000 12:44:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00D21.64BA2AB0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C00D21.64BA2AB0 Content-Type: text/plain; charset="iso-8859-1" Liaquat, You are quite right. In fact, this is the easiest (perhaps only standard based) way of capturing authoritative snapshots that can then be used for archiving - for 7 yr record keeping requirements, etc. If a certificate was suspended for a week and during that period no OCSP request was made on the status of this certificate you would still have a record of this in archives. This can be invaluable for future dispute resolution proceedings for example. For this reason many PKIs mandate that CRLs be generated on every revocation event in addition to periodic CRL publishing. Khaja =========================================== Khaja E. Ahmed Chief Technology Officer Identrus, LLC. 16th Floor 140 E 45th St. New York, NY 10017 USA Telephone: 01.212.622.0673 Fax: 01.212.622.9196 Khaja.ahmed@identrus.com Cell Phone: 01.925.989.6564 Home office: 01.925.462.0453 ============================================ -----Original Message----- From: Liaquat Khan [mailto:liaquat.khan@gta.multicert.org] Sent: Wednesday, August 23, 2000 8:02 AM To: ietf-pkix@imc.org Subject: Re: President Clinton digital signing Tom, Isn't it a good idea to generate CRLs anyway, even if you are using OCSP? The main reason I have in mind is so that the CRL acts as a historical record of when the certificate was revoked. On the other hand, an OCSP response would only be sent subsequent to receiving an appropriate OCSP request message. Regards, Liaquat Khan Technical Manager Global Trust Authority (GTA) ----- Original Message ----- From: Tom Strickland To: Sam Schaen Cc: Liaquat Khan ; Sent: Wednesday, August 23, 2000 2:20 PM Subject: Re: President Clinton digital signing > If you are using a mixture or hybrid OCSP environment to perform checking with an import > of CRL data, yes the result could be the same. > > However, if you are using a true OCSP LDAP environment (i.e. no CRLs), part of your > system may slow down due to the DoS but the validity would always be accurate. > > In the Sentry product, each Registration Authority (RA) has a built in real time OCSP > LDAP. This allows a complete OCSP enterprise without the need for any CRLs (unless you > want to cross certify a CRL from other non OCSP PKI vendors). This means that your risk > of DoS attacks may only slow down one leg (RA) or department of your PKI environment, > not the whole enterprise ensuring accurate real time information. > > Sam Schaen wrote: > > > If the DoS prevents the OCSP responder from receiving a CRL from which it determines > > validity status, the result is the same. > > > > Tom Strickland wrote: > > > > > Liaquat, > > > > > > You bring up a very good point, DoS attacks are a risk in each environment. > > > However if your environment has critical need for current data (such as a bank > > > or government), then a CRL has a higher risk. > > > > > > Example: If a company does not have a requirement for current information, a CRL > > > is sufficient. If a company requires real time data (i.e. a bank or government) > > > due to high value transactions or security, then I would highly recommend OCSP. > > > The risk is if you use CRLs for the latter, the company may get a false sense of > > > security believing their "high value" transactions are guarded by real time > > > data. If the batch CRL is latent, you may continue processing utilizing old > > > data. The risk is a cert believed to be revoked may still be considered good in > > > the system exposing the company to potential fraud or negligence. > > > > > > In an OCSP environment, if you must trust real time data and someone executes a > > > DoS attack, the responder may slow down or worst case, stop working. This is an > > > added value because I would rather slow down or stop processing than to rely on > > > old data. The risk here is slower response time but guaranteed accurate > > > information. > > > > > > This is a question that each company must answer by performing a risk assessment > > > to determine their acceptable level of "pain", risk and exposure. > > > > > > I am not trying to be confrontational in my recent "typings". I am just trying > > > to bring added value to everyone here. As an auditor that has performed audits > > > on several PKI environments, I am just trying to help elevate certain risks that > > > sometimes get overlooked. > > > > > > Best regards, > > > > > > Tom > > > > > > Liaquat Khan wrote: > > > > > > > You have to assume that access to the server which issues CRLs is protected > > > > from denial of service attacks. For example, generally only trusted > > > > operators can authorise the generation of CRLs, after having their > > > > identities authenticated by the server. Also access to the CRL issuer has > > > > to be protected through firewalls, etc. > > > > > > > > If an attacker can perform a DoS attack on a CRL issuer, what is there to > > > > stop him/her launching a similar attack on an OCSP server (e.g. by issuing > > > > an extremely large amount of OCSP requests)? > > > > > > > > Regards, > > > > Liaquat Khan > > > > Technical Manager > > > > Global Trust Authority (GTA) > > > > > > > > ----- Original Message ----- > > > > From: Tom Strickland > > > > To: Ambarish Malpani > > > > Cc: ; > > > > Sent: Wednesday, August 23, 2000 5:11 AM > > > > Subject: Re: President Clinton digital signing > > > > > > > > > Hello Ambarish, > > > > > > > > > > Thanks for your reply. I agree that OCSP services are by far better than > > > > > CRLs. In general, as everyone knows, a CRL is a batch job that updates a > > > > > database over certain intervals. From an audit standpoint, one of the many > > > > > issues with CRLs is that they can be beat. For example, it is very easy to > > > > > perform any series of denial of service attacks against the server. This > > > > > could cause longer than expected delays in the execution of the batch job > > > > > or worse, prevent the batch job from running causing latent (or corrupted) > > > > > CRL publishing. Also, if someone is savvy enough, they could also issue > > > > > hundreds of back to back CRL job requests resulting in multiple jobs > > > > > waiting on shared services again causing problematic CRLs. I know this may > > > > > sound farfetched but they are risks to be considered. > > > > > > > > > > As you may guess I am not a proponent of CRLs for obvious reasons. I have > > > > > heard claims by some that their products are OCSP compliant. In reality it > > > > > is just a batch job publishing to a database but still they have inherent > > > > > CRL batch job latency. > > > > > > > > > > As for the CAM, I am not familiar enough with that to argue for or against > > > > > its use. I do know however that the Xcert product has a non proprietary > > > > > real time OCSP LDAP out of the box resulting in a more robust product. > > > > Note > > > > > that the Sentry CA product can publish CRLs to non OCSP products to offer > > > > > backwards compatibility when needed. Also, the Sentry product can import > > > > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > > > > > > > Also one of the several reasons that Sentry CA was chosen was due to its > > > > > ability to cross certify against other CAs (cross certification). It is > > > > > very easy to setup trust to another company's CA allowing multiple CAs or > > > > > PKI vendors within a central Sentry OCSP environment. > > > > > > > > > > Best regards, > > > > > > > > > > Tom > > > > > > > > > > > > > > > Ambarish Malpani wrote: > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > > > > create a new CRL whenever a new revocation happens. > > > > > > > > > > > > Think of this CRL as a snapshot of the CA's revocation database > > > > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > > > > server that the snapshot has changed. > > > > > > > > > > > > Really, an OCSP server can be set up to be as current as any other > > > > > > software to provide revocation information, either with or without > > > > > > CRLs. > > > > > > > > > > > > It is completely unclear to me why the CAM solution is any > > > > > > more real time than OCSP. I believe the real reason for the > > > > > > CAM solution was just that OCSP didn't exist as a standard till > > > > > > late in the ACES project as indicated by the mails from both > > > > > > Judith and Tim. I have a suspicion that it still might be faster > > > > > > and cheaper for ACES to go with OCSP, rather than try to stick to > > > > > > a non-standard protocol. > > > > > > > > > > > > Regards, > > > > > > Ambarish > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > Ambarish Malpani > > > > > > Architect 650.567.5457 > > > > > > ValiCert, Inc. ambarish@valicert.com > > > > > > 339 N. Bernardo Ave. http://www.valicert.com > > > > > > Mountain View, CA 94043 > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > > > > dosent seem to want to > > > > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > > > > programs)??". > > > > > > > You have to remember that ACES does have built in OCSP. The > > > > > > > product that they > > > > > > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > > > > > > > > > > > Please review the following URLs to see how and why Xcert was chosen: > > > > > > > > > > > > > > ACES announcement: > > > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > > > > > > > Reference to digital signature law: > > > > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > > > > > > > Sentry CA functionality: > > > > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > > > > > > > this is very interexting, can somebody please comment on > > > > > > > why the US govt > > > > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > > > > they call it sems > > > > > > > > to be an alternative mechanism....a duplication of much of > > > > > > > the work OCSP has > > > > > > > > already worked through... > > > > > > > > > > > > > > > > -j > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > > > > To: ietf-pkix@imc.org > > > > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > > > > > > > Terri suggests that the real significance of the > > > > > > > certificate and smart card > > > > > > > > used by President Clinton is that they were obtained > > > > > > > through the Access > > > > > > > > Certificates for Electronic Services (ACES) contract at > > > > > > > GSA. Through the > > > > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > > > > effectively a parser > > > > > > > > and validation tool (offered to public domain by GSA), > > > > > > > multiple CA's are > > > > > > > > made available to the government applications. > > > > > > > > > > > > > > > > More info at > > > > > > > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > > > > > > > To me, though, the most significant thing is that the > > > > > > > E-Sign bill was > > > > > > > > signed, regardless of the technology utilized. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > ------_=_NextPart_001_01C00D21.64BA2AB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: President Clinton digital signing

Liaquat,

You are quite right.  In fact, this is the = easiest (perhaps only standard based) way of capturing authoritative = snapshots that can then be used for archiving - for 7 yr record keeping = requirements, etc.  If a certificate was suspended for a week and = during that period no OCSP request was made on the status of this = certificate you would still have a record of this in archives.  = This can be invaluable for future dispute resolution proceedings for = example.

For this reason many PKIs mandate that CRLs be = generated on every revocation event in addition to periodic CRL = publishing.

Khaja
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =

Khaja E. Ahmed
Chief Technology Officer

Identrus, LLC.
16th Floor
140 E 45th St.
New York, NY 10017 USA
Telephone: 01.212.622.0673
Fax: 01.212.622.9196

Khaja.ahmed@identrus.com
Cell Phone: 01.925.989.6564
Home office: 01.925.462.0453
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =



-----Original Message-----
From: Liaquat Khan [mailto:liaquat.khan@gta.m= ulticert.org]
Sent: Wednesday, August 23, 2000 8:02 AM
To: ietf-pkix@imc.org
Subject: Re: President Clinton digital = signing


Tom,

Isn't it a good idea to generate CRLs anyway, even if = you are using OCSP?
The main reason I have in mind is so that the CRL = acts as a historical
record of when the certificate was revoked.
On the other hand, an OCSP response would only be = sent subsequent to
receiving an appropriate OCSP request = message.

Regards,
Liaquat Khan
Technical Manager
Global Trust Authority (GTA)

----- Original Message -----
From: Tom Strickland = <tstrickland@xcert.com>
To: Sam Schaen <schaen@mitre.org>
Cc: Liaquat Khan = <liaquat.khan@gta.multicert.org>; = <ietf-pkix@imc.org>
Sent: Wednesday, August 23, 2000 2:20 PM
Subject: Re: President Clinton digital = signing


> If you are using a mixture or hybrid OCSP = environment to perform checking
with an import
> of CRL data, yes the result could be the = same.
>
> However, if you are using a true OCSP LDAP = environment (i.e. no CRLs),
part of your
> system may slow down due to the DoS but the = validity would always be
accurate.
>
> In the Sentry product, each Registration = Authority (RA) has a built in
real time OCSP
> LDAP. This allows a complete OCSP enterprise = without the need for any CRLs
(unless you
> want to cross certify a CRL from other non OCSP = PKI vendors). This means
that your risk
> of DoS attacks may only slow down one leg (RA) = or department of your PKI
environment,
> not the whole enterprise ensuring accurate real = time information.
>
> Sam Schaen wrote:
>
> > If the DoS prevents the OCSP responder = from receiving a CRL from which
it determines
> > validity status, the result is the = same.
> >
> > Tom Strickland wrote:
> >
> > > Liaquat,
> > >
> > > You bring up a very good point, DoS = attacks are a risk in each
environment.
> > > However if your environment has = critical need for current data (such
as a bank
> > > or government), then a CRL has a = higher risk.
> > >
> > > Example: If a company does not have a = requirement for current
information, a CRL
> > > is sufficient. If a company requires = real time data (i.e. a bank or
government)
> > > due to high value transactions or = security, then I would highly
recommend OCSP.
> > > The risk is if you use CRLs for the = latter, the company may get a
false sense of
> > > security believing their "high = value" transactions are guarded by real
time
> > > data. If the batch CRL is latent, you = may continue processing
utilizing old
> > > data. The risk is a cert believed to = be revoked may still be
considered good in
> > > the system exposing the company to = potential fraud or negligence.
> > >
> > > In an OCSP environment, if you must = trust real time data and someone
executes a
> > > DoS attack, the responder may slow = down or worst case, stop working.
This is an
> > > added value because I would rather = slow down or stop processing than
to rely on
> > > old data. The risk here is slower = response time but guaranteed
accurate
> > > information.
> > >
> > > This is a question that each company = must answer by performing a risk
assessment
> > > to determine their acceptable level = of "pain", risk and exposure.
> > >
> > > I am not trying to be confrontational = in my recent "typings". I am
just trying
> > > to bring added value to everyone = here. As an auditor that has
performed audits
> > > on several PKI environments, I am = just trying to help elevate certain
risks that
> > > sometimes get overlooked.
> > >
> > > Best regards,
> > >
> > > Tom
> > >
> > > Liaquat Khan wrote:
> > >
> > > > You have to assume that access = to the server which issues CRLs is
protected
> > > > from denial of service = attacks.  For example, generally only trusted
> > > > operators can authorise the = generation of CRLs, after having their
> > > > identities authenticated by the = server.  Also access to the CRL
issuer has
> > > > to be protected through = firewalls, etc.
> > > >
> > > > If an attacker can perform a DoS = attack on a CRL issuer, what is
there to
> > > > stop him/her launching a similar = attack on an OCSP server (e.g. by
issuing
> > > > an extremely large amount of = OCSP requests)?
> > > >
> > > > Regards,
> > > > Liaquat Khan
> > > > Technical Manager
> > > > Global Trust Authority = (GTA)
> > > >
> > > > ----- Original Message = -----
> > > > From: Tom Strickland = <tstrickland@xcert.com>
> > > > To: Ambarish Malpani = <ambarish@valicert.com>
> > > > Cc: = <spinneyj@flashcom.net>; <ietf-pkix@imc.org>
> > > > Sent: Wednesday, August 23, 2000 = 5:11 AM
> > > > Subject: Re: President Clinton = digital signing
> > > >
> > > > > Hello Ambarish,
> > > > >
> > > > > Thanks for your reply. I = agree that OCSP services are by far
better than
> > > > > CRLs. In general, as = everyone knows, a CRL is a batch job that
updates a
> > > > > database over certain = intervals. From an audit standpoint, one of
the many
> > > > > issues with CRLs is that = they can be beat. For example, it is very
easy to
> > > > > perform any series of = denial of service attacks against the
server. This
> > > > > could cause longer than = expected delays in the execution of the
batch job
> > > > > or worse, prevent the batch = job from running causing latent (or
corrupted)
> > > > > CRL publishing. Also, if = someone is savvy enough, they could also
issue
> > > > > hundreds of back to back = CRL job requests resulting in multiple
jobs
> > > > > waiting on shared services = again causing problematic CRLs. I know
this may
> > > > > sound farfetched but they = are risks to be considered.
> > > > >
> > > > > As you may guess I am not a = proponent of CRLs for obvious reasons.
I have
> > > > > heard claims by some that = their products are OCSP compliant. In
reality it
> > > > > is just a batch job = publishing to a database but still they have
inherent
> > > > > CRL batch job = latency.
> > > > >
> > > > > As for the CAM, I am not = familiar enough with that to argue for or
against
> > > > > its use. I do know however = that the Xcert product has a non
proprietary
> > > > > real time OCSP LDAP out of = the box resulting in a more robust
product.
> > > > Note
> > > > > that the Sentry CA product = can publish CRLs to non OCSP products
to offer
> > > > > backwards compatibility = when needed. Also, the Sentry product can
import
> > > > > other vendors CRLs and = place them in the real time OCSP LDAP.
> > > > >
> > > > > Also one of the several = reasons that Sentry CA was chosen was due
to its
> > > > > ability to cross certify = against other CAs (cross certification).
It is
> > > > > very easy to setup trust to = another company's CA allowing multiple
CAs or
> > > > > PKI vendors within a = central Sentry OCSP environment.
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Tom
> > > > >
> > > > >
> > > > > Ambarish Malpani = wrote:
> > > > >
> > > > > > Hi Tom,
> > > > > >
> > > > > > It really isn't that = hard to set up quite a few of the CAs to
> > > > > > create a new CRL = whenever a new revocation happens.
> > > > > >
> > > > > > Think of this CRL as a = snapshot of the CA's revocation database
> > > > > > and the publishing of = a new CRL as a trigger to tell the OCSP
> > > > > > server that the = snapshot has changed.
> > > > > >
> > > > > > Really, an OCSP server = can be set up to be as current as any
other
> > > > > > software to provide = revocation information, either with or
without
> > > > > > CRLs.
> > > > > >
> > > > > = >     It is completely unclear to me why the CAM = solution is any
> > > > > > more real time than = OCSP. I believe the real reason for the
> > > > > > CAM solution was just = that OCSP didn't exist as a standard till
> > > > > > late in the ACES = project as indicated by the mails from both
> > > > > > Judith and Tim. I have = a suspicion that it still might be faster
> > > > > > and cheaper for ACES = to go with OCSP, rather than try to stick
to
> > > > > > a non-standard = protocol.
> > > > > >
> > > > > > Regards,
> > > > > > Ambarish
> > > > > >
> > > > >
> = ---------------------------------------------------------------------
> > > > > > Ambarish = Malpani
> > > > > > Architect
650.567.5457
> > > > > > ValiCert, Inc.
ambarish@valicert.com
> > > > > > 339 N. Bernardo = Ave.
http://www.valicert.com
> > > > > > Mountain View, CA = 94043
> > > > > >
> > > > > > > -----Original = Message-----
> > > > > > > From: Tom = Strickland [mailto:tstrickland@xcert.com]<= /FONT>
> > > > > > > Sent: Tuesday, = August 22, 2000 9:18 AM
> > > > > > > To: = spinneyj@flashcom.net; ietf-pkix@imc.org
> > > > > > > Subject: Re: = President Clinton digital signing
> > > > > > >
> > > > > > >
> > > > > > > You are correct = to ask "why the US govt (GSA, at least)
> > > > > > > dosent seem to = want to
> > > > > > > embrace OCSP as a = validation mechanism for ACES (and other
> > > > > > > = programs)??".
> > > > > > > You have to = remember that ACES does have built in OCSP. The
> > > > > > > product that = they
> > > > > > > chose includes an = OCSP "real time" responder, not antiquated
CRLs.
> > > > > > >
> > > > > > > Please review the = following URLs to see how and why Xcert was
chosen:
> > > > > > >
> > > > > > > ACES = announcement:
> > > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-ac= es.html
> > > > > > >
> > > > > > > Reference to = digital signature law:
> > > > > > > http://www.xcert.com/resources/esign/index.html
> > > > > > >
> > > > > > > Sentry CA = functionality:
> > > > > > > http://www.xcert.com/software/sentryca.html=
> > > > > > >
> > > > > > > Scalability to = manage over 8 million certs on one CA and box:
> > > > > > >
http://www.xcert.com/corp/Press_Releases/2000-05-15-8m= illion.html
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > = jspinney@securify.com wrote:
> > > > > > >
> > > > > > > > this is very = interexting, can somebody please comment on
> > > > > > > why the US = govt
> > > > > > > > (GSA, at = least) doesnt seem to want to embrace OCSP as a
validation
> > > > > > > > mechanism = for ACES (and other programs)??   the 'CAM' as
> > > > > > > they call it = sems
> > > > > > > > to be an = alternative mechanism....a duplication of much of
> > > > > > > the work OCSP = has
> > > > > > > > already = worked through...
> > > > > > > >
> > > > > > > > -j
> > > > > > > >
> > > > > > > > = -----Original Message-----
> > > > > > > > From: = marion.royal@gsa.gov [mailto:marion.royal@gsa.gov]
> > > > > > > > Sent: = Tuesday, August 22, 2000 8:52 AM
> > > > > > > > To: = ietf-pkix@imc.org
> > > > > > > > Cc: = terri.hobson@gsa.gov; judith.spencer@gsa.gov
> > > > > > > > Subject: RE: = President Clinton digital signing
> > > > > > > >
> > > > > > > > Terri = suggests that the real significance of the
> > > > > > > certificate and = smart card
> > > > > > > > used by = President Clinton is that they were obtained
> > > > > > > through the = Access
> > > > > > > > Certificates = for Electronic Services (ACES) contract at
> > > > > > > GSA.  = Through the
> > > > > > > > use of a = Certificate Arbitrator Module (CAM), which is
> > > > > > > effectively a = parser
> > > > > > > > and = validation tool (offered to public domain by GSA),
> > > > > > > multiple CA's = are
> > > > > > > > made = available to the government applications.
> > > > > > > >
> > > > > > > > More info = at
> > > > > > > >
> > > > > > > > http://www.gsa.gov/aces/
> > > > > > > >
> > > > > > > > To me, = though, the most significant thing is that the
> > > > > > > E-Sign bill = was
> > > > > > > > signed, = regardless of the technology utilized.
> > > > > > > >
> > > > > > > > = Cheers,
> > > > > > >
> > > > >
>

------_=_NextPart_001_01C00D21.64BA2AB0-- Received: from crack.x509.com (root@crack.x509.com [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA04145 for ; Wed, 23 Aug 2000 09:41:04 -0700 (PDT) Received: from xcert.com (home.x509.com [199.175.150.4]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e7NGfQS16832; Wed, 23 Aug 2000 09:41:26 -0700 (PDT) Message-ID: <39A3FF92.A556AE47@xcert.com> Date: Wed, 23 Aug 2000 12:45:07 -0400 From: Tom Strickland X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Liaquat Khan CC: ietf-pkix@imc.org Subject: Re: President Clinton digital signing References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> <001c01c00cde$64c6d840$68bc01d5@vaio> <39A3C410.72912219@xcert.com> <002b01c00d0a$7ef392e0$ed3863c3@vaio> Content-Type: multipart/mixed; boundary="------------1682A732A9CBD0CA1EED02F1" This is a multi-part message in MIME format. --------------1682A732A9CBD0CA1EED02F1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Liaquat Khan wrote: > Tom, > > I generally agree with you, but I think the issue of launching a DoS attack > on CRLs has been mixed in with the periodic nature of CRLs. There are two > separate risks: > > 1) a CRL has expired and a new one has not been generated in time (e.g. due > to a DoS attack). In this case the relying party should not really depend > on the CRL as it should be obvious from reading the available CRL that it is > out of date. Therefore, certificates may have been revoked in the meantime > but there is no fresh CRL to check, so you abort the transaction. This is > DoS. I agree. However in several audit reviews of PKI infrastructures, I have always seen the most recent CRL utilized as "good" regardless of the age. If all enterprises mitigated this risk by checking and aborting transactions according to age restrictions, this would be an adequate practice (until OCSP was the standard, not the exception.) > > > 2) a certificate is revoked but the next CRL is not due to be issued until > later. Therefore, this scenario is not related to a DoS attack. To > overcome this you need to ensure that CRLs are issued with a frequency which > is acceptable. By using OCSP, it doesn't necessarily mean this issue goes > away...you will still need to work out how long it will take from the time a > decision is made to revoke a certificate to the time that the OCSP server > becomes aware of this (e.g. note that the OCSP server may be fed using > periodic CRLs). Once again you are correct. However "certain PKI products" have the OCSP SSL-LDAP server integrated within the CA and RA. This ensures that once the cert is revoked or suspended, the next instance that it is checked for validity (even within seconds), it gives an accurate reflection of status without latency. Best regards, Tom > > > Regards, > Liaquat Khan > Technical Manager > Global Trust Authority (GTA) > > A relying > ----- Original Message ----- > From: Tom Strickland > To: Liaquat Khan > Cc: > Sent: Wednesday, August 23, 2000 1:31 PM > Subject: Re: President Clinton digital signing > > > Liaquat, > > > > You bring up a very good point, DoS attacks are a risk in each > environment. > > However if your environment has critical need for current data (such as a > bank > > or government), then a CRL has a higher risk. > > > > Example: If a company does not have a requirement for current information, > a CRL > > is sufficient. If a company requires real time data (i.e. a bank or > government) > > due to high value transactions or security, then I would highly recommend > OCSP. > > The risk is if you use CRLs for the latter, the company may get a false > sense of > > security believing their "high value" transactions are guarded by real > time > > data. If the batch CRL is latent, you may continue processing utilizing > old > > data. The risk is a cert believed to be revoked may still be considered > good in > > the system exposing the company to potential fraud or negligence. > > > > In an OCSP environment, if you must trust real time data and someone > executes a > > DoS attack, the responder may slow down or worst case, stop working. This > is an > > added value because I would rather slow down or stop processing than to > rely on > > old data. The risk here is slower response time but guaranteed accurate > > information. > > > > This is a question that each company must answer by performing a risk > assessment > > to determine their acceptable level of "pain", risk and exposure. > > > > I am not trying to be confrontational in my recent "typings". I am just > trying > > to bring added value to everyone here. As an auditor that has performed > audits > > on several PKI environments, I am just trying to help elevate certain > risks that > > sometimes get overlooked. > > > > Best regards, > > > > Tom > > > > Liaquat Khan wrote: > > > > > You have to assume that access to the server which issues CRLs is > protected > > > from denial of service attacks. For example, generally only trusted > > > operators can authorise the generation of CRLs, after having their > > > identities authenticated by the server. Also access to the CRL issuer > has > > > to be protected through firewalls, etc. > > > > > > If an attacker can perform a DoS attack on a CRL issuer, what is there > to > > > stop him/her launching a similar attack on an OCSP server (e.g. by > issuing > > > an extremely large amount of OCSP requests)? > > > > > > Regards, > > > Liaquat Khan > > > Technical Manager > > > Global Trust Authority (GTA) > > > > > > ----- Original Message ----- > > > From: Tom Strickland > > > To: Ambarish Malpani > > > Cc: ; > > > Sent: Wednesday, August 23, 2000 5:11 AM > > > Subject: Re: President Clinton digital signing > > > > > > > Hello Ambarish, > > > > > > > > Thanks for your reply. I agree that OCSP services are by far better > than > > > > CRLs. In general, as everyone knows, a CRL is a batch job that updates > a > > > > database over certain intervals. From an audit standpoint, one of the > many > > > > issues with CRLs is that they can be beat. For example, it is very > easy to > > > > perform any series of denial of service attacks against the server. > This > > > > could cause longer than expected delays in the execution of the batch > job > > > > or worse, prevent the batch job from running causing latent (or > corrupted) > > > > CRL publishing. Also, if someone is savvy enough, they could also > issue > > > > hundreds of back to back CRL job requests resulting in multiple jobs > > > > waiting on shared services again causing problematic CRLs. I know this > may > > > > sound farfetched but they are risks to be considered. > > > > > > > > As you may guess I am not a proponent of CRLs for obvious reasons. I > have > > > > heard claims by some that their products are OCSP compliant. In > reality it > > > > is just a batch job publishing to a database but still they have > inherent > > > > CRL batch job latency. > > > > > > > > As for the CAM, I am not familiar enough with that to argue for or > against > > > > its use. I do know however that the Xcert product has a non > proprietary > > > > real time OCSP LDAP out of the box resulting in a more robust product. > > > Note > > > > that the Sentry CA product can publish CRLs to non OCSP products to > offer > > > > backwards compatibility when needed. Also, the Sentry product can > import > > > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > > > > > Also one of the several reasons that Sentry CA was chosen was due to > its > > > > ability to cross certify against other CAs (cross certification). It > is > > > > very easy to setup trust to another company's CA allowing multiple CAs > or > > > > PKI vendors within a central Sentry OCSP environment. > > > > > > > > Best regards, > > > > > > > > Tom > > > > > > > > > > > > Ambarish Malpani wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > > > create a new CRL whenever a new revocation happens. > > > > > > > > > > Think of this CRL as a snapshot of the CA's revocation database > > > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > > > server that the snapshot has changed. > > > > > > > > > > Really, an OCSP server can be set up to be as current as any other > > > > > software to provide revocation information, either with or without > > > > > CRLs. > > > > > > > > > > It is completely unclear to me why the CAM solution is any > > > > > more real time than OCSP. I believe the real reason for the > > > > > CAM solution was just that OCSP didn't exist as a standard till > > > > > late in the ACES project as indicated by the mails from both > > > > > Judith and Tim. I have a suspicion that it still might be faster > > > > > and cheaper for ACES to go with OCSP, rather than try to stick to > > > > > a non-standard protocol. > > > > > > > > > > Regards, > > > > > Ambarish > > > > > > > > > > > --------------------------------------------------------------------- > > > > > Ambarish Malpani > > > > > Architect > 650.567.5457 > > > > > ValiCert, Inc. > ambarish@valicert.com > > > > > 339 N. Bernardo Ave. > http://www.valicert.com > > > > > Mountain View, CA 94043 > > > > > > > > > > > -----Original Message----- > > > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > > > dosent seem to want to > > > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > > > programs)??". > > > > > > You have to remember that ACES does have built in OCSP. The > > > > > > product that they > > > > > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > > > > > > > > > Please review the following URLs to see how and why Xcert was > chosen: > > > > > > > > > > > > ACES announcement: > > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > > > > > Reference to digital signature law: > > > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > > > > > Sentry CA functionality: > > > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > > > > > this is very interexting, can somebody please comment on > > > > > > why the US govt > > > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a > validation > > > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > > > they call it sems > > > > > > > to be an alternative mechanism....a duplication of much of > > > > > > the work OCSP has > > > > > > > already worked through... > > > > > > > > > > > > > > -j > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > > > To: ietf-pkix@imc.org > > > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > > > > > Terri suggests that the real significance of the > > > > > > certificate and smart card > > > > > > > used by President Clinton is that they were obtained > > > > > > through the Access > > > > > > > Certificates for Electronic Services (ACES) contract at > > > > > > GSA. Through the > > > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > > > effectively a parser > > > > > > > and validation tool (offered to public domain by GSA), > > > > > > multiple CA's are > > > > > > > made available to the government applications. > > > > > > > > > > > > > > More info at > > > > > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > > > > > To me, though, the most significant thing is that the > > > > > > E-Sign bill was > > > > > > > signed, regardless of the technology utilized. > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > --------------1682A732A9CBD0CA1EED02F1 Content-Type: text/x-vcard; charset=us-ascii; name="tstrickland.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tom Strickland Content-Disposition: attachment; filename="tstrickland.vcf" begin:vcard n:Strickland;Tom tel;cell:678 296-4866 x-mozilla-html:TRUE org:
Xcert International Inc. adr:;;;;;; version:2.1 email;internet:tstrickland@xcert.com fn:Tom Strickland end:vcard --------------1682A732A9CBD0CA1EED02F1-- Received: from serv1.is1.u-net.net (serv1.is1.u-net.net [195.102.240.129]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03542 for ; Wed, 23 Aug 2000 09:36:12 -0700 (PDT) Received: from [195.232.106.167] (helo=dwc-acer) by serv1.is1.u-net.net with esmtp (Exim 3.12 #1) id 13RdVs-0002o4-00; Wed, 23 Aug 2000 17:36:29 +0100 From: "David Chadwick" Organization: University of Salford To: ietf-pkix@imc.org Date: Wed, 23 Aug 2000 17:35:40 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Undefined combinations of extensions Reply-to: d.w.chadwick@salford.ac.uk CC: "Kurt D. Zeilenga" , osidirectory@az05.bull.com Message-ID: <39A40B6C.20716.17FCDF7@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12c) On the LDAPExt list we have been discussing the effects of combinations of extensions (controls in LDAP jargon) on the LDAP server performing an LDAP operation, when the effects of the combination of one or more extensions is not understood by the server. The server may understand each separate extension, but not the semantics of them in combination. It seems to me that PKIX/X.509 will have (or already may have encountered) this same problem for COMBINATIONS of certificate extensions (some of which may be private, some de-facto, some critical, some not) that are thought to be understood by the issuing CA, but are not fully understood by the relying party / validation engine. What text does anyone have for this situation? I believe the recently issued X.509 defect report 244, raised by Sharon, only discusses the case of a single extension in isolation, and does not discuss the effects of combinations of extensions. The most interesting cases are when the RP finds combinations of extensions, where each extension on its own is understood, but where the combined semantics are not fully understood (possibly due to incomplete or ambiguous specification of extension interactions when the extensions are written by different groups). In this case, LDAP is suggesting that a receiver may ignore non- critical extensions (even those it recognizes) to establish the semantics of the operation. This is in direct contrast to the wording of defect report 244, which states that an understood non-critical extension must be obeyed. The LDAP work would suggest an addition to DR244 along the lines of " A validation engine that does not understand the interaction of a non-critical extension with another extension (critical or non-critical), may ignore the non-critical extension (even if it understands the semantics of the extension in isolation to the others), and accept the certificate (unless factors other than this extension cause it to be rejected). A validation engine that does not understand the interaction of two critical extensions, must reject the certificate (even if it understands the semantics of both extensions in isolation to each other)." David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** Received: from crack.x509.com (root@crack.x509.com [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02098 for ; Wed, 23 Aug 2000 09:18:36 -0700 (PDT) Received: from xcert.com (home.x509.com [199.175.150.4]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e7NGItS15454; Wed, 23 Aug 2000 09:18:55 -0700 (PDT) Message-ID: <39A3FA4C.8AD321EE@xcert.com> Date: Wed, 23 Aug 2000 12:22:36 -0400 From: Tom Strickland X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Liaquat Khan CC: ietf-pkix@imc.org Subject: Re: President Clinton digital signing References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> <001c01c00cde$64c6d840$68bc01d5@vaio> <39A3C410.72912219@xcert.com> <39A3C6A0.6C3452C0@mitre.org> <39A3CFA2.8A6C9EFD@xcert.com> <005001c00d14$81ca4e00$ed3863c3@vaio> Content-Type: multipart/mixed; boundary="------------9EAA4070E2095006216FFD92" This is a multi-part message in MIME format. --------------9EAA4070E2095006216FFD92 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Liaquat, Yes it is a good idea to save CRL data for historical purposes. My two cents, for high availability cert checking, I would want to rely on an OCSP SSL-LDAP instead of a CRL. In a "best case" high availability OCSP environment, it would be even better to have a mirror image server backing up the SSL-LDAP in real time. While this is not needed (due to cost) by everyone, once again this depends on a company's risk assessment. Liaquat Khan wrote: > Tom, > > Isn't it a good idea to generate CRLs anyway, even if you are using OCSP? > The main reason I have in mind is so that the CRL acts as a historical > record of when the certificate was revoked. > On the other hand, an OCSP response would only be sent subsequent to > receiving an appropriate OCSP request message. > > Regards, > Liaquat Khan > Technical Manager > Global Trust Authority (GTA) > > ----- Original Message ----- > From: Tom Strickland > To: Sam Schaen > Cc: Liaquat Khan ; > Sent: Wednesday, August 23, 2000 2:20 PM > Subject: Re: President Clinton digital signing > > > If you are using a mixture or hybrid OCSP environment to perform checking > with an import > > of CRL data, yes the result could be the same. > > > > However, if you are using a true OCSP LDAP environment (i.e. no CRLs), > part of your > > system may slow down due to the DoS but the validity would always be > accurate. > > > > In the Sentry product, each Registration Authority (RA) has a built in > real time OCSP > > LDAP. This allows a complete OCSP enterprise without the need for any CRLs > (unless you > > want to cross certify a CRL from other non OCSP PKI vendors). This means > that your risk > > of DoS attacks may only slow down one leg (RA) or department of your PKI > environment, > > not the whole enterprise ensuring accurate real time information. > > > > Sam Schaen wrote: > > > > > If the DoS prevents the OCSP responder from receiving a CRL from which > it determines > > > validity status, the result is the same. > > > > > > Tom Strickland wrote: > > > > > > > Liaquat, > > > > > > > > You bring up a very good point, DoS attacks are a risk in each > environment. > > > > However if your environment has critical need for current data (such > as a bank > > > > or government), then a CRL has a higher risk. > > > > > > > > Example: If a company does not have a requirement for current > information, a CRL > > > > is sufficient. If a company requires real time data (i.e. a bank or > government) > > > > due to high value transactions or security, then I would highly > recommend OCSP. > > > > The risk is if you use CRLs for the latter, the company may get a > false sense of > > > > security believing their "high value" transactions are guarded by real > time > > > > data. If the batch CRL is latent, you may continue processing > utilizing old > > > > data. The risk is a cert believed to be revoked may still be > considered good in > > > > the system exposing the company to potential fraud or negligence. > > > > > > > > In an OCSP environment, if you must trust real time data and someone > executes a > > > > DoS attack, the responder may slow down or worst case, stop working. > This is an > > > > added value because I would rather slow down or stop processing than > to rely on > > > > old data. The risk here is slower response time but guaranteed > accurate > > > > information. > > > > > > > > This is a question that each company must answer by performing a risk > assessment > > > > to determine their acceptable level of "pain", risk and exposure. > > > > > > > > I am not trying to be confrontational in my recent "typings". I am > just trying > > > > to bring added value to everyone here. As an auditor that has > performed audits > > > > on several PKI environments, I am just trying to help elevate certain > risks that > > > > sometimes get overlooked. > > > > > > > > Best regards, > > > > > > > > Tom > > > > > > > > Liaquat Khan wrote: > > > > > > > > > You have to assume that access to the server which issues CRLs is > protected > > > > > from denial of service attacks. For example, generally only trusted > > > > > operators can authorise the generation of CRLs, after having their > > > > > identities authenticated by the server. Also access to the CRL > issuer has > > > > > to be protected through firewalls, etc. > > > > > > > > > > If an attacker can perform a DoS attack on a CRL issuer, what is > there to > > > > > stop him/her launching a similar attack on an OCSP server (e.g. by > issuing > > > > > an extremely large amount of OCSP requests)? > > > > > > > > > > Regards, > > > > > Liaquat Khan > > > > > Technical Manager > > > > > Global Trust Authority (GTA) > > > > > > > > > > ----- Original Message ----- > > > > > From: Tom Strickland > > > > > To: Ambarish Malpani > > > > > Cc: ; > > > > > Sent: Wednesday, August 23, 2000 5:11 AM > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > Hello Ambarish, > > > > > > > > > > > > Thanks for your reply. I agree that OCSP services are by far > better than > > > > > > CRLs. In general, as everyone knows, a CRL is a batch job that > updates a > > > > > > database over certain intervals. From an audit standpoint, one of > the many > > > > > > issues with CRLs is that they can be beat. For example, it is very > easy to > > > > > > perform any series of denial of service attacks against the > server. This > > > > > > could cause longer than expected delays in the execution of the > batch job > > > > > > or worse, prevent the batch job from running causing latent (or > corrupted) > > > > > > CRL publishing. Also, if someone is savvy enough, they could also > issue > > > > > > hundreds of back to back CRL job requests resulting in multiple > jobs > > > > > > waiting on shared services again causing problematic CRLs. I know > this may > > > > > > sound farfetched but they are risks to be considered. > > > > > > > > > > > > As you may guess I am not a proponent of CRLs for obvious reasons. > I have > > > > > > heard claims by some that their products are OCSP compliant. In > reality it > > > > > > is just a batch job publishing to a database but still they have > inherent > > > > > > CRL batch job latency. > > > > > > > > > > > > As for the CAM, I am not familiar enough with that to argue for or > against > > > > > > its use. I do know however that the Xcert product has a non > proprietary > > > > > > real time OCSP LDAP out of the box resulting in a more robust > product. > > > > > Note > > > > > > that the Sentry CA product can publish CRLs to non OCSP products > to offer > > > > > > backwards compatibility when needed. Also, the Sentry product can > import > > > > > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > > > > > > > > > Also one of the several reasons that Sentry CA was chosen was due > to its > > > > > > ability to cross certify against other CAs (cross certification). > It is > > > > > > very easy to setup trust to another company's CA allowing multiple > CAs or > > > > > > PKI vendors within a central Sentry OCSP environment. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Tom > > > > > > > > > > > > > > > > > > Ambarish Malpani wrote: > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > > > > > create a new CRL whenever a new revocation happens. > > > > > > > > > > > > > > Think of this CRL as a snapshot of the CA's revocation database > > > > > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > > > > > server that the snapshot has changed. > > > > > > > > > > > > > > Really, an OCSP server can be set up to be as current as any > other > > > > > > > software to provide revocation information, either with or > without > > > > > > > CRLs. > > > > > > > > > > > > > > It is completely unclear to me why the CAM solution is any > > > > > > > more real time than OCSP. I believe the real reason for the > > > > > > > CAM solution was just that OCSP didn't exist as a standard till > > > > > > > late in the ACES project as indicated by the mails from both > > > > > > > Judith and Tim. I have a suspicion that it still might be faster > > > > > > > and cheaper for ACES to go with OCSP, rather than try to stick > to > > > > > > > a non-standard protocol. > > > > > > > > > > > > > > Regards, > > > > > > > Ambarish > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > Ambarish Malpani > > > > > > > Architect > 650.567.5457 > > > > > > > ValiCert, Inc. > ambarish@valicert.com > > > > > > > 339 N. Bernardo Ave. > http://www.valicert.com > > > > > > > Mountain View, CA 94043 > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > > > > > dosent seem to want to > > > > > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > > > > > programs)??". > > > > > > > > You have to remember that ACES does have built in OCSP. The > > > > > > > > product that they > > > > > > > > chose includes an OCSP "real time" responder, not antiquated > CRLs. > > > > > > > > > > > > > > > > Please review the following URLs to see how and why Xcert was > chosen: > > > > > > > > > > > > > > > > ACES announcement: > > > > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > > > > > > > > > Reference to digital signature law: > > > > > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > > > > > > > > > Sentry CA functionality: > > > > > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > > > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > > > > > > > > > this is very interexting, can somebody please comment on > > > > > > > > why the US govt > > > > > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a > validation > > > > > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > > > > > they call it sems > > > > > > > > > to be an alternative mechanism....a duplication of much of > > > > > > > > the work OCSP has > > > > > > > > > already worked through... > > > > > > > > > > > > > > > > > > -j > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > > > > > To: ietf-pkix@imc.org > > > > > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > > > > > > > > > Terri suggests that the real significance of the > > > > > > > > certificate and smart card > > > > > > > > > used by President Clinton is that they were obtained > > > > > > > > through the Access > > > > > > > > > Certificates for Electronic Services (ACES) contract at > > > > > > > > GSA. Through the > > > > > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > > > > > effectively a parser > > > > > > > > > and validation tool (offered to public domain by GSA), > > > > > > > > multiple CA's are > > > > > > > > > made available to the government applications. > > > > > > > > > > > > > > > > > > More info at > > > > > > > > > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > > > > > > > > > To me, though, the most significant thing is that the > > > > > > > > E-Sign bill was > > > > > > > > > signed, regardless of the technology utilized. > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > --------------9EAA4070E2095006216FFD92 Content-Type: text/x-vcard; charset=us-ascii; name="tstrickland.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tom Strickland Content-Disposition: attachment; filename="tstrickland.vcf" begin:vcard n:Strickland;Tom tel;cell:678 296-4866 x-mozilla-html:TRUE org:
Xcert International Inc. adr:;;;;;; version:2.1 email;internet:tstrickland@xcert.com fn:Tom Strickland end:vcard --------------9EAA4070E2095006216FFD92-- Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29591 for ; Wed, 23 Aug 2000 08:50:39 -0700 (PDT) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0FZR009015D0KT@ext-mail.valicert.com> for ietf-pkix@imc.org; Wed, 23 Aug 2000 08:51:00 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0FZR008J65D0QP@ext-mail.valicert.com>; Wed, 23 Aug 2000 08:51:00 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 08:40:53 -0700 Content-return: allowed Date: Wed, 23 Aug 2000 08:40:49 -0700 From: Ambarish Malpani Subject: RE: President Clinton digital signing To: "'Liaquat Khan'" , ietf-pkix@imc.org, "'tstrickland@xcert.com'" Message-id: <27FF4FAEA8CDD211B97E00902745CBE201B83116@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Hi Liaquat, CRLs *don't* have to only be issued periodically. It is perfectly reasonable to issue new CRLs on demand (i.e. whenever a new revocation even happens) in addition to issuing the regular periodic CRLs. Regards, Ambarish Hi Tom, I am not sure I buy the DoS attack. There are a few ways around it: a. Make sure the OCSP server and CA are both behind a firewall with a fat pipe between them. b. You can have the OCSP server ping the CRL database periodically and stop responding if it can't reach it within say a 5 second interval. This still allows you to ensure that you have the latest data (within 5 seconds), but still allows you to process pretty large numbers of OCSP requests. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Liaquat Khan [mailto:liaquat.khan@gta.multicert.org] > Sent: Wednesday, August 23, 2000 7:00 AM > To: ietf-pkix@imc.org > Subject: Re: President Clinton digital signing > > > Tom, > > I generally agree with you, but I think the issue of > launching a DoS attack > on CRLs has been mixed in with the periodic nature of CRLs. > There are two > separate risks: > > 1) a CRL has expired and a new one has not been generated in > time (e.g. due > to a DoS attack). In this case the relying party should not > really depend > on the CRL as it should be obvious from reading the available > CRL that it is > out of date. Therefore, certificates may have been revoked > in the meantime > but there is no fresh CRL to check, so you abort the > transaction. This is > DoS. > > 2) a certificate is revoked but the next CRL is not due to be > issued until > later. Therefore, this scenario is not related to a DoS attack. To > overcome this you need to ensure that CRLs are issued with a > frequency which > is acceptable. By using OCSP, it doesn't necessarily mean > this issue goes > away...you will still need to work out how long it will take > from the time a > decision is made to revoke a certificate to the time that the > OCSP server > becomes aware of this (e.g. note that the OCSP server may be fed using > periodic CRLs). > > Regards, > Liaquat Khan > Technical Manager > Global Trust Authority (GTA) > > > > A relying > ----- Original Message ----- > From: Tom Strickland > To: Liaquat Khan > Cc: > Sent: Wednesday, August 23, 2000 1:31 PM > Subject: Re: President Clinton digital signing > > > > Liaquat, > > > > You bring up a very good point, DoS attacks are a risk in each > environment. > > However if your environment has critical need for current > data (such as a > bank > > or government), then a CRL has a higher risk. > > > > Example: If a company does not have a requirement for > current information, > a CRL > > is sufficient. If a company requires real time data (i.e. a bank or > government) > > due to high value transactions or security, then I would > highly recommend > OCSP. > > The risk is if you use CRLs for the latter, the company may > get a false > sense of > > security believing their "high value" transactions are > guarded by real > time > > data. If the batch CRL is latent, you may continue > processing utilizing > old > > data. The risk is a cert believed to be revoked may still > be considered > good in > > the system exposing the company to potential fraud or negligence. > > > > In an OCSP environment, if you must trust real time data and someone > executes a > > DoS attack, the responder may slow down or worst case, stop > working. This > is an > > added value because I would rather slow down or stop > processing than to > rely on > > old data. The risk here is slower response time but > guaranteed accurate > > information. > > > > This is a question that each company must answer by > performing a risk > assessment > > to determine their acceptable level of "pain", risk and exposure. > > > > I am not trying to be confrontational in my recent > "typings". I am just > trying > > to bring added value to everyone here. As an auditor that > has performed > audits > > on several PKI environments, I am just trying to help > elevate certain > risks that > > sometimes get overlooked. > > > > Best regards, > > > > Tom > > > > Liaquat Khan wrote: > > > > > You have to assume that access to the server which issues CRLs is > protected > > > from denial of service attacks. For example, generally > only trusted > > > operators can authorise the generation of CRLs, after having their > > > identities authenticated by the server. Also access to > the CRL issuer > has > > > to be protected through firewalls, etc. > > > > > > If an attacker can perform a DoS attack on a CRL issuer, > what is there > to > > > stop him/her launching a similar attack on an OCSP server (e.g. by > issuing > > > an extremely large amount of OCSP requests)? > > > > > > Regards, > > > Liaquat Khan > > > Technical Manager > > > Global Trust Authority (GTA) > > > > > > ----- Original Message ----- > > > From: Tom Strickland > > > To: Ambarish Malpani > > > Cc: ; > > > Sent: Wednesday, August 23, 2000 5:11 AM > > > Subject: Re: President Clinton digital signing > > > > > > > Hello Ambarish, > > > > > > > > Thanks for your reply. I agree that OCSP services are > by far better > than > > > > CRLs. In general, as everyone knows, a CRL is a batch > job that updates > a > > > > database over certain intervals. From an audit > standpoint, one of the > many > > > > issues with CRLs is that they can be beat. For example, > it is very > easy to > > > > perform any series of denial of service attacks against > the server. > This > > > > could cause longer than expected delays in the > execution of the batch > job > > > > or worse, prevent the batch job from running causing latent (or > corrupted) > > > > CRL publishing. Also, if someone is savvy enough, they > could also > issue > > > > hundreds of back to back CRL job requests resulting in > multiple jobs > > > > waiting on shared services again causing problematic > CRLs. I know this > may > > > > sound farfetched but they are risks to be considered. > > > > > > > > As you may guess I am not a proponent of CRLs for > obvious reasons. I > have > > > > heard claims by some that their products are OCSP compliant. In > reality it > > > > is just a batch job publishing to a database but still they have > inherent > > > > CRL batch job latency. > > > > > > > > As for the CAM, I am not familiar enough with that to > argue for or > against > > > > its use. I do know however that the Xcert product has a non > proprietary > > > > real time OCSP LDAP out of the box resulting in a more > robust product. > > > Note > > > > that the Sentry CA product can publish CRLs to non OCSP > products to > offer > > > > backwards compatibility when needed. Also, the Sentry > product can > import > > > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > > > > > Also one of the several reasons that Sentry CA was > chosen was due to > its > > > > ability to cross certify against other CAs (cross > certification). It > is > > > > very easy to setup trust to another company's CA > allowing multiple CAs > or > > > > PKI vendors within a central Sentry OCSP environment. > > > > > > > > Best regards, > > > > > > > > Tom > > > > > > > > > > > > Ambarish Malpani wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > > > create a new CRL whenever a new revocation happens. > > > > > > > > > > Think of this CRL as a snapshot of the CA's > revocation database > > > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > > > server that the snapshot has changed. > > > > > > > > > > Really, an OCSP server can be set up to be as current > as any other > > > > > software to provide revocation information, either > with or without > > > > > CRLs. > > > > > > > > > > It is completely unclear to me why the CAM solution is any > > > > > more real time than OCSP. I believe the real reason for the > > > > > CAM solution was just that OCSP didn't exist as a > standard till > > > > > late in the ACES project as indicated by the mails from both > > > > > Judith and Tim. I have a suspicion that it still > might be faster > > > > > and cheaper for ACES to go with OCSP, rather than try > to stick to > > > > > a non-standard protocol. > > > > > > > > > > Regards, > > > > > Ambarish > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > Ambarish Malpani > > > > > Architect > 650.567.5457 > > > > > ValiCert, Inc. > ambarish@valicert.com > > > > > 339 N. Bernardo Ave. > http://www.valicert.com > > > > > Mountain View, CA 94043 > > > > > > > > > > > -----Original Message----- > > > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > > > dosent seem to want to > > > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > > > programs)??". > > > > > > You have to remember that ACES does have built in OCSP. The > > > > > > product that they > > > > > > chose includes an OCSP "real time" responder, not > antiquated CRLs. > > > > > > > > > > > > Please review the following URLs to see how and why > Xcert was > chosen: > > > > > > > > > > > > ACES announcement: > > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > > > Reference to digital signature law: > > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > > > Sentry CA functionality: > > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > > > this is very interexting, can somebody please comment on > > > > > why the US govt > > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > > they call it sems > > > > > > to be an alternative mechanism....a duplication of much of > > > > > the work OCSP has > > > > > > already worked through... > > > > > > > > > > > > -j > > > > > > > > > > > > -----Original Message----- > > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > > To: ietf-pkix@imc.org > > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > > > Terri suggests that the real significance of the > > > > > certificate and smart card > > > > > > used by President Clinton is that they were obtained > > > > > through the Access > > > > > > Certificates for Electronic Services (ACES) contract at > > > > > GSA. Through the > > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > > effectively a parser > > > > > > and validation tool (offered to public domain by GSA), > > > > > multiple CA's are > > > > > > made available to the government applications. > > > > > > > > > > > > More info at > > > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > > > To me, though, the most significant thing is that the > > > > > E-Sign bill was > > > > > > signed, regardless of the technology utilized. > > > > > > > > > > > > Cheers, > > > > > > > > > Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22659 for ; Wed, 23 Aug 2000 08:09:00 -0700 (PDT) Received: from [62.6.95.151] (helo=vaio) by tungsten.btinternet.com with smtp (Exim 3.03 #83) id 13Rc9Y-0006IB-00 for ietf-pkix@imc.org; Wed, 23 Aug 2000 16:09:21 +0100 Message-ID: <005001c00d14$81ca4e00$ed3863c3@vaio> Reply-To: "Liaquat Khan" From: "Liaquat Khan" To: References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> <001c01c00cde$64c6d840$68bc01d5@vaio> <39A3C410.72912219@xcert.com> <39A3C6A0.6C3452C0@mitre.org> <39A3CFA2.8A6C9EFD@xcert.com> Subject: Re: President Clinton digital signing Date: Wed, 23 Aug 2000 16:01:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Tom, Isn't it a good idea to generate CRLs anyway, even if you are using OCSP? The main reason I have in mind is so that the CRL acts as a historical record of when the certificate was revoked. On the other hand, an OCSP response would only be sent subsequent to receiving an appropriate OCSP request message. Regards, Liaquat Khan Technical Manager Global Trust Authority (GTA) ----- Original Message ----- From: Tom Strickland To: Sam Schaen Cc: Liaquat Khan ; Sent: Wednesday, August 23, 2000 2:20 PM Subject: Re: President Clinton digital signing > If you are using a mixture or hybrid OCSP environment to perform checking with an import > of CRL data, yes the result could be the same. > > However, if you are using a true OCSP LDAP environment (i.e. no CRLs), part of your > system may slow down due to the DoS but the validity would always be accurate. > > In the Sentry product, each Registration Authority (RA) has a built in real time OCSP > LDAP. This allows a complete OCSP enterprise without the need for any CRLs (unless you > want to cross certify a CRL from other non OCSP PKI vendors). This means that your risk > of DoS attacks may only slow down one leg (RA) or department of your PKI environment, > not the whole enterprise ensuring accurate real time information. > > Sam Schaen wrote: > > > If the DoS prevents the OCSP responder from receiving a CRL from which it determines > > validity status, the result is the same. > > > > Tom Strickland wrote: > > > > > Liaquat, > > > > > > You bring up a very good point, DoS attacks are a risk in each environment. > > > However if your environment has critical need for current data (such as a bank > > > or government), then a CRL has a higher risk. > > > > > > Example: If a company does not have a requirement for current information, a CRL > > > is sufficient. If a company requires real time data (i.e. a bank or government) > > > due to high value transactions or security, then I would highly recommend OCSP. > > > The risk is if you use CRLs for the latter, the company may get a false sense of > > > security believing their "high value" transactions are guarded by real time > > > data. If the batch CRL is latent, you may continue processing utilizing old > > > data. The risk is a cert believed to be revoked may still be considered good in > > > the system exposing the company to potential fraud or negligence. > > > > > > In an OCSP environment, if you must trust real time data and someone executes a > > > DoS attack, the responder may slow down or worst case, stop working. This is an > > > added value because I would rather slow down or stop processing than to rely on > > > old data. The risk here is slower response time but guaranteed accurate > > > information. > > > > > > This is a question that each company must answer by performing a risk assessment > > > to determine their acceptable level of "pain", risk and exposure. > > > > > > I am not trying to be confrontational in my recent "typings". I am just trying > > > to bring added value to everyone here. As an auditor that has performed audits > > > on several PKI environments, I am just trying to help elevate certain risks that > > > sometimes get overlooked. > > > > > > Best regards, > > > > > > Tom > > > > > > Liaquat Khan wrote: > > > > > > > You have to assume that access to the server which issues CRLs is protected > > > > from denial of service attacks. For example, generally only trusted > > > > operators can authorise the generation of CRLs, after having their > > > > identities authenticated by the server. Also access to the CRL issuer has > > > > to be protected through firewalls, etc. > > > > > > > > If an attacker can perform a DoS attack on a CRL issuer, what is there to > > > > stop him/her launching a similar attack on an OCSP server (e.g. by issuing > > > > an extremely large amount of OCSP requests)? > > > > > > > > Regards, > > > > Liaquat Khan > > > > Technical Manager > > > > Global Trust Authority (GTA) > > > > > > > > ----- Original Message ----- > > > > From: Tom Strickland > > > > To: Ambarish Malpani > > > > Cc: ; > > > > Sent: Wednesday, August 23, 2000 5:11 AM > > > > Subject: Re: President Clinton digital signing > > > > > > > > > Hello Ambarish, > > > > > > > > > > Thanks for your reply. I agree that OCSP services are by far better than > > > > > CRLs. In general, as everyone knows, a CRL is a batch job that updates a > > > > > database over certain intervals. From an audit standpoint, one of the many > > > > > issues with CRLs is that they can be beat. For example, it is very easy to > > > > > perform any series of denial of service attacks against the server. This > > > > > could cause longer than expected delays in the execution of the batch job > > > > > or worse, prevent the batch job from running causing latent (or corrupted) > > > > > CRL publishing. Also, if someone is savvy enough, they could also issue > > > > > hundreds of back to back CRL job requests resulting in multiple jobs > > > > > waiting on shared services again causing problematic CRLs. I know this may > > > > > sound farfetched but they are risks to be considered. > > > > > > > > > > As you may guess I am not a proponent of CRLs for obvious reasons. I have > > > > > heard claims by some that their products are OCSP compliant. In reality it > > > > > is just a batch job publishing to a database but still they have inherent > > > > > CRL batch job latency. > > > > > > > > > > As for the CAM, I am not familiar enough with that to argue for or against > > > > > its use. I do know however that the Xcert product has a non proprietary > > > > > real time OCSP LDAP out of the box resulting in a more robust product. > > > > Note > > > > > that the Sentry CA product can publish CRLs to non OCSP products to offer > > > > > backwards compatibility when needed. Also, the Sentry product can import > > > > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > > > > > > > Also one of the several reasons that Sentry CA was chosen was due to its > > > > > ability to cross certify against other CAs (cross certification). It is > > > > > very easy to setup trust to another company's CA allowing multiple CAs or > > > > > PKI vendors within a central Sentry OCSP environment. > > > > > > > > > > Best regards, > > > > > > > > > > Tom > > > > > > > > > > > > > > > Ambarish Malpani wrote: > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > > > > create a new CRL whenever a new revocation happens. > > > > > > > > > > > > Think of this CRL as a snapshot of the CA's revocation database > > > > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > > > > server that the snapshot has changed. > > > > > > > > > > > > Really, an OCSP server can be set up to be as current as any other > > > > > > software to provide revocation information, either with or without > > > > > > CRLs. > > > > > > > > > > > > It is completely unclear to me why the CAM solution is any > > > > > > more real time than OCSP. I believe the real reason for the > > > > > > CAM solution was just that OCSP didn't exist as a standard till > > > > > > late in the ACES project as indicated by the mails from both > > > > > > Judith and Tim. I have a suspicion that it still might be faster > > > > > > and cheaper for ACES to go with OCSP, rather than try to stick to > > > > > > a non-standard protocol. > > > > > > > > > > > > Regards, > > > > > > Ambarish > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > Ambarish Malpani > > > > > > Architect 650.567.5457 > > > > > > ValiCert, Inc. ambarish@valicert.com > > > > > > 339 N. Bernardo Ave. http://www.valicert.com > > > > > > Mountain View, CA 94043 > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > > > > dosent seem to want to > > > > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > > > > programs)??". > > > > > > > You have to remember that ACES does have built in OCSP. The > > > > > > > product that they > > > > > > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > > > > > > > > > > > Please review the following URLs to see how and why Xcert was chosen: > > > > > > > > > > > > > > ACES announcement: > > > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > > > > > > > Reference to digital signature law: > > > > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > > > > > > > Sentry CA functionality: > > > > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > > > > > > > this is very interexting, can somebody please comment on > > > > > > > why the US govt > > > > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > > > > they call it sems > > > > > > > > to be an alternative mechanism....a duplication of much of > > > > > > > the work OCSP has > > > > > > > > already worked through... > > > > > > > > > > > > > > > > -j > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > > > > To: ietf-pkix@imc.org > > > > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > > > > > > > Terri suggests that the real significance of the > > > > > > > certificate and smart card > > > > > > > > used by President Clinton is that they were obtained > > > > > > > through the Access > > > > > > > > Certificates for Electronic Services (ACES) contract at > > > > > > > GSA. Through the > > > > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > > > > effectively a parser > > > > > > > > and validation tool (offered to public domain by GSA), > > > > > > > multiple CA's are > > > > > > > > made available to the government applications. > > > > > > > > > > > > > > > > More info at > > > > > > > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > > > > > > > To me, though, the most significant thing is that the > > > > > > > E-Sign bill was > > > > > > > > signed, regardless of the technology utilized. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > Received: from unimur.um.es (unimur.um.es [155.54.1.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19562 for ; Wed, 23 Aug 2000 07:31:21 -0700 (PDT) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by unimur.um.es (8.9.1b+Sun/8.9.1) with ESMTP id QAA10841 for ; Wed, 23 Aug 2000 16:31:44 +0200 (MET DST) Received: from dif.um.es (pirania.dif.um.es [155.54.210.33]) by aries.dif.um.es (Postfix) with ESMTP id A39B2EC1A for ; Wed, 23 Aug 2000 16:30:39 +0200 (MET DST) Message-ID: <39A3E05D.72283049@dif.um.es> Date: Wed, 23 Aug 2000 16:31:57 +0200 From: Gabriel Lopez Millan X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Policy Representation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all. I'm working in a PKI and I have a little question. I want to create Policies (RSA Key Length Size, Key Algorithm Type, etc). Similar to X509Extension, each extension has a OID (unique identifier) and have a ASN1 representation. There is OIDs for Policies? There is a document where I can find documentation? Should I define my own OID and my own ASN1 representation? Thanks, Gabi. Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18594 for ; Wed, 23 Aug 2000 07:18:41 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA07228; Wed, 23 Aug 2000 10:19:05 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <39A3CFA2.8A6C9EFD@xcert.com> References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> <001c01c00cde$64c6d840$68bc01d5@vaio> <39A3C410.72912219@xcert.com> <39A3C6A0.6C3452C0@mitre.org> <39A3CFA2.8A6C9EFD@xcert.com> Date: Wed, 23 Aug 2000 10:13:05 -0400 To: Tom Strickland From: Stephen Kent Subject: Re: President Clinton digital signing Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Tom, >If you are using a mixture or hybrid OCSP environment to perform >checking with an import >of CRL data, yes the result could be the same. OCSP does not say how an OCSp server acquires the revocation information it relies on. Unless the server is tightly tied to a CA, CRLs would probably be the basis for the data. Also, CRLs are the only standard means of acquiring such data from multiple CAs. > >However, if you are using a true OCSP LDAP environment (i.e. no >CRLs), part of your >system may slow down due to the DoS but the validity would always be accurate. > >In the Sentry product, each Registration Authority (RA) has a built >in real time OCSP >LDAP. This allows a complete OCSP enterprise without the need for >any CRLs (unless you >want to cross certify a CRL from other non OCSP PKI vendors). This >means that your risk >of DoS attacks may only slow down one leg (RA) or department of your >PKI environment, >not the whole enterprise ensuring accurate real time information. In the model you describe, there would also seem to be a robustness issue, i.e., unless each RA replicates the OCSP server function, a portion of the cert space cannot be checked if the cognizant RA is offline. This also seems a bit odd, as the usual model for a PKI assigns the task of revocation to the CA, not the RA. Steve Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17859 for ; Wed, 23 Aug 2000 07:08:29 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA05281; Wed, 23 Aug 2000 10:08:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <39A34EFD.2DE9A602@xcert.com> References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> Date: Wed, 23 Aug 2000 10:03:07 -0400 To: Tom Strickland From: Stephen Kent Subject: Re: President Clinton digital signing Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Tom, >Hello Ambarish, > >Thanks for your reply. I agree that OCSP services are by far better than >CRLs. I think this is an over generalization, i.e., OCSP is bettr in some cases, but not in all cases. >In general, as everyone knows, a CRL is a batch job that updates a >database over certain intervals. From an audit standpoint, one of the many >issues with CRLs is that they can be beat. For example, it is very easy to >perform any series of denial of service attacks against the server. Which server? A directory? A CRL has the advantage that it can be replicated at any numnber of servers, without imbuing these serves with trust (re integrity and authenticity). While it is certainly true that one can engage in a DoS attack against directories, the same is also true for OCSP servers. I don't think we have enough experience with both types of servers to determine if one is more susceptible than the other, as a class, or if it's just an issue of implementation and local management quality. >This >could cause longer than expected delays in the execution of the batch job >or worse, prevent the batch job from running causing latent (or corrupted) >CRL publishing. Batch job? Now it sounds like your talking about a CA preparing a CRL. A CA component generating a CRL need not be online and thus need not be very susceptible to DoS attacks, so I'm puzzled by this line of reasoning. >Also, if someone is savvy enough, they could also issue >hundreds of back to back CRL job requests resulting in multiple jobs >waiting on shared services again causing problematic CRLs. I know this may >sound farfetched but they are risks to be considered. CRL job requests? I've been involved with the design of several CAs over time and none offered an external interface which could be manipulated inthe fashion you suggest. >As you may guess I am not a proponent of CRLs for obvious reasons. I have >heard claims by some that their products are OCSP compliant. In reality it >is just a batch job publishing to a database but still they have inherent >CRL batch job latency. The latency issue re CRLs is a red herring, in almost all cases. The time required to generate a CRL is fairly small for almost any PKI of a reasonable size. The external, non-technical factors associated with deciding that a compromise has occurred or that an attribute has changed and thus a cert should be revoked almost always swamp the CRL production activity. >As for the CAM, I am not familiar enough with that to argue for or against >its use. I do know however that the Xcert product has a non proprietary >real time OCSP LDAP out of the box resulting in a more robust product. Note >that the Sentry CA product can publish CRLs to non OCSP products to offer >backwards compatibility when needed. Also, the Sentry product can import >other vendors CRLs and place them in the real time OCSP LDAP. Oh, OCSp and LDAP? That combination suggests an DoS opportunity that might be the sum of the two server interfaces :-). >Also one of the several reasons that Sentry CA was chosen was due to its >ability to cross certify against other CAs (cross certification). It is >very easy to setup trust to another company's CA allowing multiple CAs or >PKI vendors within a central Sentry OCSP environment. No more product endorsements, OK? Steve Received: from c014.sfo.cp.net (c014-h022.c014.sfo.cp.net [209.228.12.86]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA17386 for ; Wed, 23 Aug 2000 07:03:59 -0700 (PDT) Received: (cpmta 27108 invoked from network); 23 Aug 2000 07:03:54 -0700 Received: from 3ff8359b.dsl.flashcom.net (HELO concord) (63.248.53.155) by smtp.flashcom.net with SMTP; 23 Aug 2000 07:03:54 -0700 X-Sent: 23 Aug 2000 14:03:54 GMT Reply-To: From: "Jeff Spinney" To: "'Tom Strickland'" , "'Sam Schaen'" Cc: "'Liaquat Khan'" , Subject: RE: President Clinton digital signing Date: Wed, 23 Aug 2000 10:00:09 -0400 Message-ID: <003d01c00d0a$736f9360$6501010a@jeffshouse.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <39A3CFA2.8A6C9EFD@xcert.com> I am uncertain that I would refer to an OCSP responder which imports CRL data in order to give out real time cert status a 'hybrid'....CRLs wont be going away completely anytime soon (nor do i think they were they intended to), rather the 'audience' for them has changed ...from each individual user to the OCSP responder. The OCSP responder is intended to be the public interface, speaking for the status of certificates that have been issued on behalf of the CA. It should be closely related to the CA, that is there should be a secure channel for publication of CRLs...however, it shouldn't necessarily be the CA itself. Having an interface that only the CA can talk to minimizes a potential DoS attack on that interface. In addition, it is beneficial to have some sort of 'secure' LDAP storage for issued certificates and crls, whether it is an integral part of the OCSP responder (such as CertCo's CertValidator) or a separate directory. Having some sort of central storage that can be accessed by end users in the PKI (or their applications) is critical in having encrypted email.... Picture the environment where you wish to be able to take the CA offline for either security or policy reasons. The OCSP responder should be able to speak for certificate status until the next update from the CA comes along, it has the ability to keep the PKI operational while the CA is offline. In a high value PKI, where it potentially takes some amount of time to bring together those individuals who possess the distributed private information needed to operate the CA, the OCSP responder should have the ability to place the operational status of a certificate within its PKI on 'hold' as defined in the rfc2560. This hold status is nearly instantaneous, for all OCSP queries afterwards the status will be 'revoked' with a reason code of 'on hold'. Once the proper resources are brought together and the CA is brought online, the certificate may be officially revoked by the entity which originally issued it. When the CRL is issued, the status of this certificate is moved to a permanently revoked state. -j -----Original Message----- From: Tom Strickland [mailto:tstrickland@xcert.com] Sent: Wednesday, August 23, 2000 9:21 AM To: Sam Schaen Cc: Liaquat Khan; ietf-pkix@imc.org Subject: Re: President Clinton digital signing If you are using a mixture or hybrid OCSP environment to perform checking with an import of CRL data, yes the result could be the same. However, if you are using a true OCSP LDAP environment (i.e. no CRLs), part of your system may slow down due to the DoS but the validity would always be accurate. In the Sentry product, each Registration Authority (RA) has a built in real time OCSP LDAP. This allows a complete OCSP enterprise without the need for any CRLs (unless you want to cross certify a CRL from other non OCSP PKI vendors). This means that your risk of DoS attacks may only slow down one leg (RA) or department of your PKI environment, not the whole enterprise ensuring accurate real time information. Sam Schaen wrote: > If the DoS prevents the OCSP responder from receiving a CRL from which it determines > validity status, the result is the same. > > Tom Strickland wrote: > > > Liaquat, > > > > You bring up a very good point, DoS attacks are a risk in each environment. > > However if your environment has critical need for current data (such as a bank > > or government), then a CRL has a higher risk. > > > > Example: If a company does not have a requirement for current information, a CRL > > is sufficient. If a company requires real time data (i.e. a bank or government) > > due to high value transactions or security, then I would highly recommend OCSP. > > The risk is if you use CRLs for the latter, the company may get a false sense of > > security believing their "high value" transactions are guarded by real time > > data. If the batch CRL is latent, you may continue processing utilizing old > > data. The risk is a cert believed to be revoked may still be considered good in > > the system exposing the company to potential fraud or negligence. > > > > In an OCSP environment, if you must trust real time data and someone executes a > > DoS attack, the responder may slow down or worst case, stop working. This is an > > added value because I would rather slow down or stop processing than to rely on > > old data. The risk here is slower response time but guaranteed accurate > > information. > > > > This is a question that each company must answer by performing a risk assessment > > to determine their acceptable level of "pain", risk and exposure. > > > > I am not trying to be confrontational in my recent "typings". I am just trying > > to bring added value to everyone here. As an auditor that has performed audits > > on several PKI environments, I am just trying to help elevate certain risks that > > sometimes get overlooked. > > > > Best regards, > > > > Tom > > > > Liaquat Khan wrote: > > > > > You have to assume that access to the server which issues CRLs is protected > > > from denial of service attacks. For example, generally only trusted > > > operators can authorise the generation of CRLs, after having their > > > identities authenticated by the server. Also access to the CRL issuer has > > > to be protected through firewalls, etc. > > > > > > If an attacker can perform a DoS attack on a CRL issuer, what is there to > > > stop him/her launching a similar attack on an OCSP server (e.g. by issuing > > > an extremely large amount of OCSP requests)? > > > > > > Regards, > > > Liaquat Khan > > > Technical Manager > > > Global Trust Authority (GTA) > > > > > > ----- Original Message ----- > > > From: Tom Strickland > > > To: Ambarish Malpani > > > Cc: ; > > > Sent: Wednesday, August 23, 2000 5:11 AM > > > Subject: Re: President Clinton digital signing > > > > > > > Hello Ambarish, > > > > > > > > Thanks for your reply. I agree that OCSP services are by far better than > > > > CRLs. In general, as everyone knows, a CRL is a batch job that updates a > > > > database over certain intervals. From an audit standpoint, one of the many > > > > issues with CRLs is that they can be beat. For example, it is very easy to > > > > perform any series of denial of service attacks against the server. This > > > > could cause longer than expected delays in the execution of the batch job > > > > or worse, prevent the batch job from running causing latent (or corrupted) > > > > CRL publishing. Also, if someone is savvy enough, they could also issue > > > > hundreds of back to back CRL job requests resulting in multiple jobs > > > > waiting on shared services again causing problematic CRLs. I know this may > > > > sound farfetched but they are risks to be considered. > > > > > > > > As you may guess I am not a proponent of CRLs for obvious reasons. I have > > > > heard claims by some that their products are OCSP compliant. In reality it > > > > is just a batch job publishing to a database but still they have inherent > > > > CRL batch job latency. > > > > > > > > As for the CAM, I am not familiar enough with that to argue for or against > > > > its use. I do know however that the Xcert product has a non proprietary > > > > real time OCSP LDAP out of the box resulting in a more robust product. > > > Note > > > > that the Sentry CA product can publish CRLs to non OCSP products to offer > > > > backwards compatibility when needed. Also, the Sentry product can import > > > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > > > > > Also one of the several reasons that Sentry CA was chosen was due to its > > > > ability to cross certify against other CAs (cross certification). It is > > > > very easy to setup trust to another company's CA allowing multiple CAs or > > > > PKI vendors within a central Sentry OCSP environment. > > > > > > > > Best regards, > > > > > > > > Tom > > > > > > > > > > > > Ambarish Malpani wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > > > create a new CRL whenever a new revocation happens. > > > > > > > > > > Think of this CRL as a snapshot of the CA's revocation database > > > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > > > server that the snapshot has changed. > > > > > > > > > > Really, an OCSP server can be set up to be as current as any other > > > > > software to provide revocation information, either with or without > > > > > CRLs. > > > > > > > > > > It is completely unclear to me why the CAM solution is any > > > > > more real time than OCSP. I believe the real reason for the > > > > > CAM solution was just that OCSP didn't exist as a standard till > > > > > late in the ACES project as indicated by the mails from both > > > > > Judith and Tim. I have a suspicion that it still might be faster > > > > > and cheaper for ACES to go with OCSP, rather than try to stick to > > > > > a non-standard protocol. > > > > > > > > > > Regards, > > > > > Ambarish > > > > > > > > > > --------------------------------------------------------------------- > > > > > Ambarish Malpani > > > > > Architect 650.567.5457 > > > > > ValiCert, Inc. ambarish@valicert.com > > > > > 339 N. Bernardo Ave. http://www.valicert.com > > > > > Mountain View, CA 94043 > > > > > > > > > > > -----Original Message----- > > > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > > > dosent seem to want to > > > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > > > programs)??". > > > > > > You have to remember that ACES does have built in OCSP. The > > > > > > product that they > > > > > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > > > > > > > > > Please review the following URLs to see how and why Xcert was chosen: > > > > > > > > > > > > ACES announcement: > > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > > > > > Reference to digital signature law: > > > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > > > > > Sentry CA functionality: > > > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > > > > > this is very interexting, can somebody please comment on > > > > > > why the US govt > > > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > > > they call it sems > > > > > > > to be an alternative mechanism....a duplication of much of > > > > > > the work OCSP has > > > > > > > already worked through... > > > > > > > > > > > > > > -j > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > > > To: ietf-pkix@imc.org > > > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > > > > > Terri suggests that the real significance of the > > > > > > certificate and smart card > > > > > > > used by President Clinton is that they were obtained > > > > > > through the Access > > > > > > > Certificates for Electronic Services (ACES) contract at > > > > > > GSA. Through the > > > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > > > effectively a parser > > > > > > > and validation tool (offered to public domain by GSA), > > > > > > multiple CA's are > > > > > > > made available to the government applications. > > > > > > > > > > > > > > More info at > > > > > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > > > > > To me, though, the most significant thing is that the > > > > > > E-Sign bill was > > > > > > > signed, regardless of the technology utilized. > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Received: from neodymium.btinternet.com (neodymium.btinternet.com [194.73.73.83]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16899 for ; Wed, 23 Aug 2000 06:57:18 -0700 (PDT) Received: from [213.1.130.101] (helo=vaio) by neodymium.btinternet.com with smtp (Exim 3.03 #83) id 13Rb2D-000149-00 for ietf-pkix@imc.org; Wed, 23 Aug 2000 14:57:41 +0100 Message-ID: <002b01c00d0a$7ef392e0$ed3863c3@vaio> Reply-To: "Liaquat Khan" From: "Liaquat Khan" To: References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> <001c01c00cde$64c6d840$68bc01d5@vaio> <39A3C410.72912219@xcert.com> Subject: Re: President Clinton digital signing Date: Wed, 23 Aug 2000 15:00:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Tom, I generally agree with you, but I think the issue of launching a DoS attack on CRLs has been mixed in with the periodic nature of CRLs. There are two separate risks: 1) a CRL has expired and a new one has not been generated in time (e.g. due to a DoS attack). In this case the relying party should not really depend on the CRL as it should be obvious from reading the available CRL that it is out of date. Therefore, certificates may have been revoked in the meantime but there is no fresh CRL to check, so you abort the transaction. This is DoS. 2) a certificate is revoked but the next CRL is not due to be issued until later. Therefore, this scenario is not related to a DoS attack. To overcome this you need to ensure that CRLs are issued with a frequency which is acceptable. By using OCSP, it doesn't necessarily mean this issue goes away...you will still need to work out how long it will take from the time a decision is made to revoke a certificate to the time that the OCSP server becomes aware of this (e.g. note that the OCSP server may be fed using periodic CRLs). Regards, Liaquat Khan Technical Manager Global Trust Authority (GTA) A relying ----- Original Message ----- From: Tom Strickland To: Liaquat Khan Cc: Sent: Wednesday, August 23, 2000 1:31 PM Subject: Re: President Clinton digital signing > Liaquat, > > You bring up a very good point, DoS attacks are a risk in each environment. > However if your environment has critical need for current data (such as a bank > or government), then a CRL has a higher risk. > > Example: If a company does not have a requirement for current information, a CRL > is sufficient. If a company requires real time data (i.e. a bank or government) > due to high value transactions or security, then I would highly recommend OCSP. > The risk is if you use CRLs for the latter, the company may get a false sense of > security believing their "high value" transactions are guarded by real time > data. If the batch CRL is latent, you may continue processing utilizing old > data. The risk is a cert believed to be revoked may still be considered good in > the system exposing the company to potential fraud or negligence. > > In an OCSP environment, if you must trust real time data and someone executes a > DoS attack, the responder may slow down or worst case, stop working. This is an > added value because I would rather slow down or stop processing than to rely on > old data. The risk here is slower response time but guaranteed accurate > information. > > This is a question that each company must answer by performing a risk assessment > to determine their acceptable level of "pain", risk and exposure. > > I am not trying to be confrontational in my recent "typings". I am just trying > to bring added value to everyone here. As an auditor that has performed audits > on several PKI environments, I am just trying to help elevate certain risks that > sometimes get overlooked. > > Best regards, > > Tom > > Liaquat Khan wrote: > > > You have to assume that access to the server which issues CRLs is protected > > from denial of service attacks. For example, generally only trusted > > operators can authorise the generation of CRLs, after having their > > identities authenticated by the server. Also access to the CRL issuer has > > to be protected through firewalls, etc. > > > > If an attacker can perform a DoS attack on a CRL issuer, what is there to > > stop him/her launching a similar attack on an OCSP server (e.g. by issuing > > an extremely large amount of OCSP requests)? > > > > Regards, > > Liaquat Khan > > Technical Manager > > Global Trust Authority (GTA) > > > > ----- Original Message ----- > > From: Tom Strickland > > To: Ambarish Malpani > > Cc: ; > > Sent: Wednesday, August 23, 2000 5:11 AM > > Subject: Re: President Clinton digital signing > > > > > Hello Ambarish, > > > > > > Thanks for your reply. I agree that OCSP services are by far better than > > > CRLs. In general, as everyone knows, a CRL is a batch job that updates a > > > database over certain intervals. From an audit standpoint, one of the many > > > issues with CRLs is that they can be beat. For example, it is very easy to > > > perform any series of denial of service attacks against the server. This > > > could cause longer than expected delays in the execution of the batch job > > > or worse, prevent the batch job from running causing latent (or corrupted) > > > CRL publishing. Also, if someone is savvy enough, they could also issue > > > hundreds of back to back CRL job requests resulting in multiple jobs > > > waiting on shared services again causing problematic CRLs. I know this may > > > sound farfetched but they are risks to be considered. > > > > > > As you may guess I am not a proponent of CRLs for obvious reasons. I have > > > heard claims by some that their products are OCSP compliant. In reality it > > > is just a batch job publishing to a database but still they have inherent > > > CRL batch job latency. > > > > > > As for the CAM, I am not familiar enough with that to argue for or against > > > its use. I do know however that the Xcert product has a non proprietary > > > real time OCSP LDAP out of the box resulting in a more robust product. > > Note > > > that the Sentry CA product can publish CRLs to non OCSP products to offer > > > backwards compatibility when needed. Also, the Sentry product can import > > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > > > Also one of the several reasons that Sentry CA was chosen was due to its > > > ability to cross certify against other CAs (cross certification). It is > > > very easy to setup trust to another company's CA allowing multiple CAs or > > > PKI vendors within a central Sentry OCSP environment. > > > > > > Best regards, > > > > > > Tom > > > > > > > > > Ambarish Malpani wrote: > > > > > > > Hi Tom, > > > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > > create a new CRL whenever a new revocation happens. > > > > > > > > Think of this CRL as a snapshot of the CA's revocation database > > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > > server that the snapshot has changed. > > > > > > > > Really, an OCSP server can be set up to be as current as any other > > > > software to provide revocation information, either with or without > > > > CRLs. > > > > > > > > It is completely unclear to me why the CAM solution is any > > > > more real time than OCSP. I believe the real reason for the > > > > CAM solution was just that OCSP didn't exist as a standard till > > > > late in the ACES project as indicated by the mails from both > > > > Judith and Tim. I have a suspicion that it still might be faster > > > > and cheaper for ACES to go with OCSP, rather than try to stick to > > > > a non-standard protocol. > > > > > > > > Regards, > > > > Ambarish > > > > > > > > --------------------------------------------------------------------- > > > > Ambarish Malpani > > > > Architect 650.567.5457 > > > > ValiCert, Inc. ambarish@valicert.com > > > > 339 N. Bernardo Ave. http://www.valicert.com > > > > Mountain View, CA 94043 > > > > > > > > > -----Original Message----- > > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > > dosent seem to want to > > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > > programs)??". > > > > > You have to remember that ACES does have built in OCSP. The > > > > > product that they > > > > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > > > > > > > Please review the following URLs to see how and why Xcert was chosen: > > > > > > > > > > ACES announcement: > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > > > Reference to digital signature law: > > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > > > Sentry CA functionality: > > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > > > this is very interexting, can somebody please comment on > > > > > why the US govt > > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > > they call it sems > > > > > > to be an alternative mechanism....a duplication of much of > > > > > the work OCSP has > > > > > > already worked through... > > > > > > > > > > > > -j > > > > > > > > > > > > -----Original Message----- > > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > > To: ietf-pkix@imc.org > > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > > > Terri suggests that the real significance of the > > > > > certificate and smart card > > > > > > used by President Clinton is that they were obtained > > > > > through the Access > > > > > > Certificates for Electronic Services (ACES) contract at > > > > > GSA. Through the > > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > > effectively a parser > > > > > > and validation tool (offered to public domain by GSA), > > > > > multiple CA's are > > > > > > made available to the government applications. > > > > > > > > > > > > More info at > > > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > > > To me, though, the most significant thing is that the > > > > > E-Sign bill was > > > > > > signed, regardless of the technology utilized. > > > > > > > > > > > > Cheers, > > > > > > > > > Received: from osd.mil (firewall-user@gateway1.osd.mil [140.185.28.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15672 for ; Wed, 23 Aug 2000 06:34:19 -0700 (PDT) From: William.Flanigan@bmdo.osd.mil Received: by osd.mil; id JAA25207; Wed, 23 Aug 2000 09:47:45 GMT Received: from hqbmdofs03.bmdo.osd.mil(134.152.2.194) by gateway1.osd.mil via smap (V4.2) id xma025112; Wed, 23 Aug 00 09:47:39 GMT Received: from hqbmdofs03.bmdo.osd.mil (root@localhost) by hqbmdofs03.bmdo.osd.mil with ESMTP id JAA27892; Wed, 23 Aug 2000 09:29:41 -0400 (EDT) Received: from hqbmdomsg01.bmdo.osd.mil (hqbmdomsg01.bmdo.osd.mil [172.20.100.3]) by hqbmdofs03.bmdo.osd.mil with ESMTP id JAA27882; Wed, 23 Aug 2000 09:29:40 -0400 (EDT) Received: by hqbmdomsg01.bmdo.osd.mil with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 09:37:08 -0400 Message-ID: <516542F35571D31187C000A0C9DCD3300304729C@hqbmdomsg01.bmdo.osd.mil> To: pbaker@verisign.com Cc: terri.hobson@gsa.gov, judith.spencer@gsa.gov, marion.royal@gsa.gov, ietf-pkix@imc.org Subject: RE: President Clinton digital signing Date: Wed, 23 Aug 2000 09:37:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_0006_01C00CE5.BBB10AC0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C00CE5.BBB10AC0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C00CE5.BBA4D5C0" ------=_NextPart_000_0002_01C00CE5.BBA4D5C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Right on Philip (as usual)! But it seems unlikely that the bill was not "signed" twice, one being a wet signature (with no photo op). Does anyone know for sure? Bill Flanigan -----Original Message----- From: Philip Hallam-Baker [mailto:pbaker@verisign.com] Sent: Tuesday, August 22, 2000 9:08 PM To: 'marion.royal@gsa.gov'; ietf-pkix@imc.org Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov Subject: RE: President Clinton digital signing [snip] And it was totally illogical to use a digital signature for the purpose. The act is now effectively a self-signed cert! The validity of the authentication on the act is established through a circular reference to the act itself. Phill ------=_NextPart_000_0002_01C00CE5.BBA4D5C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Right on Philip (as usual)!  But it seems = unlikely that the bill was not "signed" twice, one being a wet = signature (with no photo op).  Does anyone know for = sure?

Bill Flanigan

-----Original Message-----
From: Philip Hallam-Baker [mailto:pbaker@verisign.com]
Sent: Tuesday, August 22, 2000 9:08 PM
To: 'marion.royal@gsa.gov'; ietf-pkix@imc.org
Cc: terri.hobson@gsa.gov; = judith.spencer@gsa.gov
Subject: RE: President Clinton digital signing

[snip]

And it was totally illogical to use a digital = signature for the purpose.

The act is now effectively a self-signed cert! The = validity of the
authentication on the act is established through a = circular reference
to the act itself.


        =       Phill

------=_NextPart_000_0002_01C00CE5.BBA4D5C0-- ------=_NextPart_000_0006_01C00CE5.BBB10AC0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHmTCCA6Iw ggMLoAMCAQICAiIxMA0GCSqGSIb3DQEBBQUAMFwxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRcwFQYDVQQDEw5NZWQgRW1h aWwgQ0EtMTAeFw0wMDAyMTAxNzExNTZaFw0wMjAyMTAxNzExNTZaMIGmMQswCQYDVQQGEwJVUzEY MBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTENMAsG A1UECxMEQk1ETzEkMCIGA1UEAxMbRmxhbmlnYW4uV2lsbGlhbS4wNTAyMDAwNTE0MSwwKgYJKoZI hvcNAQkBFh13aWxsaWFtLmZsYW5pZ2FuQGJtZG8ub3NkLm1pbDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA6nmxw86ZU1rXoE2Nqt0ybpt3s9A6mhp/vKzu6+Bfh91utH7KdcRxPBtMSefKFU/r a7atSrupNtXKQ0RAVJTrRPOvbNBTc0eMHDGs0/Rgsw3PrsgLKfFU/HVq8RaBVP9+/rDF1T6b63kY +aO/11/c31ri6yr2KOheAq2be/Lxln8CAwEAAaOCASYwggEiMBYGA1UdIAQPMA0wCwYJYIZIAWUC AQsDMB8GA1UdIwQYMBaAFPIju1ImGhS6CXJ9cNJe5ng8aBX8MB0GA1UdDgQWBBQt/YJY6m1bfbS3 9Imr42XFj1ZNDTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADCBqQYDVR0fBIGhMIGeMIGb oIGYoIGVhoGSbGRhcDovL2RzLTEuY2hhbWIuZGlzYS5taWw6MzkwL2NuJTNkTWVkJTIwRW1haWwl MjBDQSUyZDElMmNvdSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJj YyUzZFVTP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3QlM2JiaW5hcnkwDQYJKoZIhvcNAQEFBQAD gYEAFHiTOZWDZek4j7hscyL4mMo5koXySAnZcLVU6kuotwuuj4LOc8l/trrPTEVawcGw4Qx+evVR lSUPVrbGWvyho7NZ6W+l+6AArPYoO//GcfFJ2g9gx9k3m4W1fZ+hTRxAC4qJqYOi9tdJYSxocZld cketJQKa4IqSRmTMqAqktfYwggPvMIIDWKADAgECAgEjMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNV BAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMD UEtJMRwwGgYDVQQDExNEb0QgUEtJIE1lZCBSb290IENBMB4XDTk4MDgwNjE5NTQ1NFoXDTAzMDgw NjE5NTQ1NFowXDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UE CxMDRG9EMQwwCgYDVQQLEwNQS0kxFzAVBgNVBAMTDk1lZCBFbWFpbCBDQS0xMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQCqTd9bbYLOvC2mMX/fpiD+4MKcPiO7bCNi+6w6jGXsyVzEysRDUkOh OR77XJyU6PD/gRV1BgQC+tqLyVKku0u13m8hxAGLP4EXk5S2Egl6AzueBlVPQcFIpSAoeK3Q69py E/9WFGCf2VDWM/57IFcHmaBzUM7aWyybNw+VHo+1JwIDAQABo4IBujCCAbYwFgYDVR0gBA8wDTAL BglghkgBZQIBCwMwHwYDVR0jBBgwFoAUxVnSzvGYlVBmqG3eMkvWYTXiRrMwDAYDVR0kBAUwA4AB ADAdBgNVHQ4EFgQU8iO7UiYaFLoJcn1w0l7meDxoFfwwDgYDVR0PAQH/BAQDAgGGMH4GA1UdEgR3 MHWGc2xkYXA6Ly9kcy0xLmNoYW1iLmRpc2EubWlsL2NuJTNkRG9EJTIwUEtJJTIwTWVkJTIwUm9v dCUyMENBJTJjb3UlM2RQS0klMiBjb3UlM2REb0QlMmNvJTNkVS5TLiUyMEdvdmVybm1lbnQlMmNj JTNkVVMwDwYDVR0TAQH/BAUwAwEB/zCBrAYDVR0fBIGkMIGhMIGeoIGboIGYhoGVbGRhcDovL2Rz LTEuY2hhbWIuZGlzYS5taWwvY24lM2REb0QlMjBQS0klMjBNZWQlMjBSb290JTIwQ0ElMmNvdSUz ZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2NlcnRpZmlj YXRlUmV2b2NhdGlvbkxpc3QlM2JiaW5hcnkwDQYJKoZIhvcNAQEFBQADgYEAlQOnyvY3wBzBFqvQ maAJqUUpucy55ErAncWtLBJcNP3Q56vAk4/O4gf/0KUe+x8DovQAe5KIn3JMQUoxc98SxV2xj+/t PvUgxPV9d59Nl2lJEGq7eufOnhwE7NNFEDJNub6V2EIpH3VMmDsPqvFJzmqTTzxzrZISXr3vJR7S dFcxggI2MIICMgIBATBiMFwxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQx DDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRcwFQYDVQQDEw5NZWQgRW1haWwgQ0EtMQICIjEw CQYFKw4DAhoFAKCCASowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MDAwODIzMTMzNzIwWjAjBgkqhkiG9w0BCQQxFgQUAqB8IDKqmT45L4Yzxe+2j+cCzFAwWAYJKoZI hvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwcQYJKwYBBAGCNxAEMWQwYjBcMQswCQYDVQQGEwJV UzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEX MBUGA1UEAxMOTWVkIEVtYWlsIENBLTECAiIxMA0GCSqGSIb3DQEBAQUABIGALsF5XSF0uNyG2Vzd m3in9q3k0LMFCskAanLqShnqqyyo8pcAGqwxG3T36j/bflyNZEKCRUgI+NIgKaVVHJOQ2q6Yl+6R bSBxjXd6WoaB4D+9xtdeDwpwpzF2ykTt5tuCNUjVl0jTmbSvXHgiL2wh9Sb0maOLwV8lH7GehJn9 A7UAAAAAAAA= ------=_NextPart_000_0006_01C00CE5.BBB10AC0-- Received: from crack.x509.com (root@crack.x509.com [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15033 for ; Wed, 23 Aug 2000 06:16:44 -0700 (PDT) Received: from xcert.com (home.x509.com [199.175.150.4]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e7NDGrS07724; Wed, 23 Aug 2000 06:16:54 -0700 (PDT) Message-ID: <39A3CFA2.8A6C9EFD@xcert.com> Date: Wed, 23 Aug 2000 09:20:34 -0400 From: Tom Strickland X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Schaen CC: Liaquat Khan , ietf-pkix@imc.org Subject: Re: President Clinton digital signing References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> <001c01c00cde$64c6d840$68bc01d5@vaio> <39A3C410.72912219@xcert.com> <39A3C6A0.6C3452C0@mitre.org> Content-Type: multipart/mixed; boundary="------------362C951FB7D16F1D7594D833" This is a multi-part message in MIME format. --------------362C951FB7D16F1D7594D833 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If you are using a mixture or hybrid OCSP environment to perform checking with an import of CRL data, yes the result could be the same. However, if you are using a true OCSP LDAP environment (i.e. no CRLs), part of your system may slow down due to the DoS but the validity would always be accurate. In the Sentry product, each Registration Authority (RA) has a built in real time OCSP LDAP. This allows a complete OCSP enterprise without the need for any CRLs (unless you want to cross certify a CRL from other non OCSP PKI vendors). This means that your risk of DoS attacks may only slow down one leg (RA) or department of your PKI environment, not the whole enterprise ensuring accurate real time information. Sam Schaen wrote: > If the DoS prevents the OCSP responder from receiving a CRL from which it determines > validity status, the result is the same. > > Tom Strickland wrote: > > > Liaquat, > > > > You bring up a very good point, DoS attacks are a risk in each environment. > > However if your environment has critical need for current data (such as a bank > > or government), then a CRL has a higher risk. > > > > Example: If a company does not have a requirement for current information, a CRL > > is sufficient. If a company requires real time data (i.e. a bank or government) > > due to high value transactions or security, then I would highly recommend OCSP. > > The risk is if you use CRLs for the latter, the company may get a false sense of > > security believing their "high value" transactions are guarded by real time > > data. If the batch CRL is latent, you may continue processing utilizing old > > data. The risk is a cert believed to be revoked may still be considered good in > > the system exposing the company to potential fraud or negligence. > > > > In an OCSP environment, if you must trust real time data and someone executes a > > DoS attack, the responder may slow down or worst case, stop working. This is an > > added value because I would rather slow down or stop processing than to rely on > > old data. The risk here is slower response time but guaranteed accurate > > information. > > > > This is a question that each company must answer by performing a risk assessment > > to determine their acceptable level of "pain", risk and exposure. > > > > I am not trying to be confrontational in my recent "typings". I am just trying > > to bring added value to everyone here. As an auditor that has performed audits > > on several PKI environments, I am just trying to help elevate certain risks that > > sometimes get overlooked. > > > > Best regards, > > > > Tom > > > > Liaquat Khan wrote: > > > > > You have to assume that access to the server which issues CRLs is protected > > > from denial of service attacks. For example, generally only trusted > > > operators can authorise the generation of CRLs, after having their > > > identities authenticated by the server. Also access to the CRL issuer has > > > to be protected through firewalls, etc. > > > > > > If an attacker can perform a DoS attack on a CRL issuer, what is there to > > > stop him/her launching a similar attack on an OCSP server (e.g. by issuing > > > an extremely large amount of OCSP requests)? > > > > > > Regards, > > > Liaquat Khan > > > Technical Manager > > > Global Trust Authority (GTA) > > > > > > ----- Original Message ----- > > > From: Tom Strickland > > > To: Ambarish Malpani > > > Cc: ; > > > Sent: Wednesday, August 23, 2000 5:11 AM > > > Subject: Re: President Clinton digital signing > > > > > > > Hello Ambarish, > > > > > > > > Thanks for your reply. I agree that OCSP services are by far better than > > > > CRLs. In general, as everyone knows, a CRL is a batch job that updates a > > > > database over certain intervals. From an audit standpoint, one of the many > > > > issues with CRLs is that they can be beat. For example, it is very easy to > > > > perform any series of denial of service attacks against the server. This > > > > could cause longer than expected delays in the execution of the batch job > > > > or worse, prevent the batch job from running causing latent (or corrupted) > > > > CRL publishing. Also, if someone is savvy enough, they could also issue > > > > hundreds of back to back CRL job requests resulting in multiple jobs > > > > waiting on shared services again causing problematic CRLs. I know this may > > > > sound farfetched but they are risks to be considered. > > > > > > > > As you may guess I am not a proponent of CRLs for obvious reasons. I have > > > > heard claims by some that their products are OCSP compliant. In reality it > > > > is just a batch job publishing to a database but still they have inherent > > > > CRL batch job latency. > > > > > > > > As for the CAM, I am not familiar enough with that to argue for or against > > > > its use. I do know however that the Xcert product has a non proprietary > > > > real time OCSP LDAP out of the box resulting in a more robust product. > > > Note > > > > that the Sentry CA product can publish CRLs to non OCSP products to offer > > > > backwards compatibility when needed. Also, the Sentry product can import > > > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > > > > > Also one of the several reasons that Sentry CA was chosen was due to its > > > > ability to cross certify against other CAs (cross certification). It is > > > > very easy to setup trust to another company's CA allowing multiple CAs or > > > > PKI vendors within a central Sentry OCSP environment. > > > > > > > > Best regards, > > > > > > > > Tom > > > > > > > > > > > > Ambarish Malpani wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > > > create a new CRL whenever a new revocation happens. > > > > > > > > > > Think of this CRL as a snapshot of the CA's revocation database > > > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > > > server that the snapshot has changed. > > > > > > > > > > Really, an OCSP server can be set up to be as current as any other > > > > > software to provide revocation information, either with or without > > > > > CRLs. > > > > > > > > > > It is completely unclear to me why the CAM solution is any > > > > > more real time than OCSP. I believe the real reason for the > > > > > CAM solution was just that OCSP didn't exist as a standard till > > > > > late in the ACES project as indicated by the mails from both > > > > > Judith and Tim. I have a suspicion that it still might be faster > > > > > and cheaper for ACES to go with OCSP, rather than try to stick to > > > > > a non-standard protocol. > > > > > > > > > > Regards, > > > > > Ambarish > > > > > > > > > > --------------------------------------------------------------------- > > > > > Ambarish Malpani > > > > > Architect 650.567.5457 > > > > > ValiCert, Inc. ambarish@valicert.com > > > > > 339 N. Bernardo Ave. http://www.valicert.com > > > > > Mountain View, CA 94043 > > > > > > > > > > > -----Original Message----- > > > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > > > dosent seem to want to > > > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > > > programs)??". > > > > > > You have to remember that ACES does have built in OCSP. The > > > > > > product that they > > > > > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > > > > > > > > > Please review the following URLs to see how and why Xcert was chosen: > > > > > > > > > > > > ACES announcement: > > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > > > > > Reference to digital signature law: > > > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > > > > > Sentry CA functionality: > > > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > > > > > this is very interexting, can somebody please comment on > > > > > > why the US govt > > > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > > > they call it sems > > > > > > > to be an alternative mechanism....a duplication of much of > > > > > > the work OCSP has > > > > > > > already worked through... > > > > > > > > > > > > > > -j > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > > > To: ietf-pkix@imc.org > > > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > > > > > Terri suggests that the real significance of the > > > > > > certificate and smart card > > > > > > > used by President Clinton is that they were obtained > > > > > > through the Access > > > > > > > Certificates for Electronic Services (ACES) contract at > > > > > > GSA. Through the > > > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > > > effectively a parser > > > > > > > and validation tool (offered to public domain by GSA), > > > > > > multiple CA's are > > > > > > > made available to the government applications. > > > > > > > > > > > > > > More info at > > > > > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > > > > > To me, though, the most significant thing is that the > > > > > > E-Sign bill was > > > > > > > signed, regardless of the technology utilized. > > > > > > > > > > > > > > Cheers, > > > > > > > > > > --------------362C951FB7D16F1D7594D833 Content-Type: text/x-vcard; charset=us-ascii; name="tstrickland.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tom Strickland Content-Disposition: attachment; filename="tstrickland.vcf" begin:vcard n:Strickland;Tom tel;cell:678 296-4866 x-mozilla-html:TRUE org:
Xcert International Inc. adr:;;;;;; version:2.1 email;internet:tstrickland@xcert.com fn:Tom Strickland end:vcard --------------362C951FB7D16F1D7594D833-- Received: from sngrel4.hp.com (sngrel4.hp.com [192.6.86.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14887 for ; Wed, 23 Aug 2000 06:09:14 -0700 (PDT) From: esmond_tong@hp.com Received: from hkmail.hkg.hp.com (hkmail.hkg.hp.com [15.106.56.21]) by sngrel4.hp.com (Postfix) with ESMTP id 6EB9A5A7 for ; Wed, 23 Aug 2000 21:09:39 +0800 (SGP) Received: from localhost (root@localhost) by hkmail.hkg.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id VAA23562 for ietf-pkix@imc.org; Wed, 23 Aug 2000 21:09:38 +0800 (HKG) X-OpenMail-Hops: 1 Date: Wed, 23 Aug 2000 21:09:19 +0800 Message-Id: Subject: unsubscribe MIME-Version: 1.0 Cc: ietf-pkix@imc.org Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT" Content-Disposition: inline; filename="BDY.TXT" Content-Transfer-Encoding: 7bit unsubscribe Received: from smtpproxy1.mitre.org ([129.83.20.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA14004 for ; Wed, 23 Aug 2000 05:42:38 -0700 (PDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id IAA13781; Wed, 23 Aug 2000 08:42:07 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id IAA04668; Wed, 23 Aug 2000 08:39:36 -0400 (EDT) Received: from schaen-pc.mitre.org (128.29.162.49) by mailhub2.mitre.org with SMTP id 4269905; Wed, 23 Aug 2000 08:42:05 EST Message-ID: <39A3C6A0.6C3452C0@mitre.org> Date: Wed, 23 Aug 2000 08:42:08 -0400 From: Sam Schaen X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Strickland CC: Liaquat Khan , ietf-pkix@imc.org Subject: Re: President Clinton digital signing References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> <001c01c00cde$64c6d840$68bc01d5@vaio> <39A3C410.72912219@xcert.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If the DoS prevents the OCSP responder from receiving a CRL from which it determines validity status, the result is the same. Tom Strickland wrote: > Liaquat, > > You bring up a very good point, DoS attacks are a risk in each environment. > However if your environment has critical need for current data (such as a bank > or government), then a CRL has a higher risk. > > Example: If a company does not have a requirement for current information, a CRL > is sufficient. If a company requires real time data (i.e. a bank or government) > due to high value transactions or security, then I would highly recommend OCSP. > The risk is if you use CRLs for the latter, the company may get a false sense of > security believing their "high value" transactions are guarded by real time > data. If the batch CRL is latent, you may continue processing utilizing old > data. The risk is a cert believed to be revoked may still be considered good in > the system exposing the company to potential fraud or negligence. > > In an OCSP environment, if you must trust real time data and someone executes a > DoS attack, the responder may slow down or worst case, stop working. This is an > added value because I would rather slow down or stop processing than to rely on > old data. The risk here is slower response time but guaranteed accurate > information. > > This is a question that each company must answer by performing a risk assessment > to determine their acceptable level of "pain", risk and exposure. > > I am not trying to be confrontational in my recent "typings". I am just trying > to bring added value to everyone here. As an auditor that has performed audits > on several PKI environments, I am just trying to help elevate certain risks that > sometimes get overlooked. > > Best regards, > > Tom > > Liaquat Khan wrote: > > > You have to assume that access to the server which issues CRLs is protected > > from denial of service attacks. For example, generally only trusted > > operators can authorise the generation of CRLs, after having their > > identities authenticated by the server. Also access to the CRL issuer has > > to be protected through firewalls, etc. > > > > If an attacker can perform a DoS attack on a CRL issuer, what is there to > > stop him/her launching a similar attack on an OCSP server (e.g. by issuing > > an extremely large amount of OCSP requests)? > > > > Regards, > > Liaquat Khan > > Technical Manager > > Global Trust Authority (GTA) > > > > ----- Original Message ----- > > From: Tom Strickland > > To: Ambarish Malpani > > Cc: ; > > Sent: Wednesday, August 23, 2000 5:11 AM > > Subject: Re: President Clinton digital signing > > > > > Hello Ambarish, > > > > > > Thanks for your reply. I agree that OCSP services are by far better than > > > CRLs. In general, as everyone knows, a CRL is a batch job that updates a > > > database over certain intervals. From an audit standpoint, one of the many > > > issues with CRLs is that they can be beat. For example, it is very easy to > > > perform any series of denial of service attacks against the server. This > > > could cause longer than expected delays in the execution of the batch job > > > or worse, prevent the batch job from running causing latent (or corrupted) > > > CRL publishing. Also, if someone is savvy enough, they could also issue > > > hundreds of back to back CRL job requests resulting in multiple jobs > > > waiting on shared services again causing problematic CRLs. I know this may > > > sound farfetched but they are risks to be considered. > > > > > > As you may guess I am not a proponent of CRLs for obvious reasons. I have > > > heard claims by some that their products are OCSP compliant. In reality it > > > is just a batch job publishing to a database but still they have inherent > > > CRL batch job latency. > > > > > > As for the CAM, I am not familiar enough with that to argue for or against > > > its use. I do know however that the Xcert product has a non proprietary > > > real time OCSP LDAP out of the box resulting in a more robust product. > > Note > > > that the Sentry CA product can publish CRLs to non OCSP products to offer > > > backwards compatibility when needed. Also, the Sentry product can import > > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > > > Also one of the several reasons that Sentry CA was chosen was due to its > > > ability to cross certify against other CAs (cross certification). It is > > > very easy to setup trust to another company's CA allowing multiple CAs or > > > PKI vendors within a central Sentry OCSP environment. > > > > > > Best regards, > > > > > > Tom > > > > > > > > > Ambarish Malpani wrote: > > > > > > > Hi Tom, > > > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > > create a new CRL whenever a new revocation happens. > > > > > > > > Think of this CRL as a snapshot of the CA's revocation database > > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > > server that the snapshot has changed. > > > > > > > > Really, an OCSP server can be set up to be as current as any other > > > > software to provide revocation information, either with or without > > > > CRLs. > > > > > > > > It is completely unclear to me why the CAM solution is any > > > > more real time than OCSP. I believe the real reason for the > > > > CAM solution was just that OCSP didn't exist as a standard till > > > > late in the ACES project as indicated by the mails from both > > > > Judith and Tim. I have a suspicion that it still might be faster > > > > and cheaper for ACES to go with OCSP, rather than try to stick to > > > > a non-standard protocol. > > > > > > > > Regards, > > > > Ambarish > > > > > > > > --------------------------------------------------------------------- > > > > Ambarish Malpani > > > > Architect 650.567.5457 > > > > ValiCert, Inc. ambarish@valicert.com > > > > 339 N. Bernardo Ave. http://www.valicert.com > > > > Mountain View, CA 94043 > > > > > > > > > -----Original Message----- > > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > > dosent seem to want to > > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > > programs)??". > > > > > You have to remember that ACES does have built in OCSP. The > > > > > product that they > > > > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > > > > > > > Please review the following URLs to see how and why Xcert was chosen: > > > > > > > > > > ACES announcement: > > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > > > Reference to digital signature law: > > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > > > Sentry CA functionality: > > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > > > this is very interexting, can somebody please comment on > > > > > why the US govt > > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > > they call it sems > > > > > > to be an alternative mechanism....a duplication of much of > > > > > the work OCSP has > > > > > > already worked through... > > > > > > > > > > > > -j > > > > > > > > > > > > -----Original Message----- > > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > > To: ietf-pkix@imc.org > > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > > > Terri suggests that the real significance of the > > > > > certificate and smart card > > > > > > used by President Clinton is that they were obtained > > > > > through the Access > > > > > > Certificates for Electronic Services (ACES) contract at > > > > > GSA. Through the > > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > > effectively a parser > > > > > > and validation tool (offered to public domain by GSA), > > > > > multiple CA's are > > > > > > made available to the government applications. > > > > > > > > > > > > More info at > > > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > > > To me, though, the most significant thing is that the > > > > > E-Sign bill was > > > > > > signed, regardless of the technology utilized. > > > > > > > > > > > > Cheers, > > > > > > > > Received: from crack.x509.com (root@crack.x509.com [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA12953 for ; Wed, 23 Aug 2000 05:27:36 -0700 (PDT) Received: from xcert.com (home.x509.com [199.175.150.4]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e7NCRWS06294; Wed, 23 Aug 2000 05:27:32 -0700 (PDT) Message-ID: <39A3C410.72912219@xcert.com> Date: Wed, 23 Aug 2000 08:31:12 -0400 From: Tom Strickland X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Liaquat Khan CC: ietf-pkix@imc.org Subject: Re: President Clinton digital signing References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> <001c01c00cde$64c6d840$68bc01d5@vaio> Content-Type: multipart/mixed; boundary="------------EF40674896C109D7FA4935E6" This is a multi-part message in MIME format. --------------EF40674896C109D7FA4935E6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Liaquat, You bring up a very good point, DoS attacks are a risk in each environment. However if your environment has critical need for current data (such as a bank or government), then a CRL has a higher risk. Example: If a company does not have a requirement for current information, a CRL is sufficient. If a company requires real time data (i.e. a bank or government) due to high value transactions or security, then I would highly recommend OCSP. The risk is if you use CRLs for the latter, the company may get a false sense of security believing their "high value" transactions are guarded by real time data. If the batch CRL is latent, you may continue processing utilizing old data. The risk is a cert believed to be revoked may still be considered good in the system exposing the company to potential fraud or negligence. In an OCSP environment, if you must trust real time data and someone executes a DoS attack, the responder may slow down or worst case, stop working. This is an added value because I would rather slow down or stop processing than to rely on old data. The risk here is slower response time but guaranteed accurate information. This is a question that each company must answer by performing a risk assessment to determine their acceptable level of "pain", risk and exposure. I am not trying to be confrontational in my recent "typings". I am just trying to bring added value to everyone here. As an auditor that has performed audits on several PKI environments, I am just trying to help elevate certain risks that sometimes get overlooked. Best regards, Tom Liaquat Khan wrote: > You have to assume that access to the server which issues CRLs is protected > from denial of service attacks. For example, generally only trusted > operators can authorise the generation of CRLs, after having their > identities authenticated by the server. Also access to the CRL issuer has > to be protected through firewalls, etc. > > If an attacker can perform a DoS attack on a CRL issuer, what is there to > stop him/her launching a similar attack on an OCSP server (e.g. by issuing > an extremely large amount of OCSP requests)? > > Regards, > Liaquat Khan > Technical Manager > Global Trust Authority (GTA) > > ----- Original Message ----- > From: Tom Strickland > To: Ambarish Malpani > Cc: ; > Sent: Wednesday, August 23, 2000 5:11 AM > Subject: Re: President Clinton digital signing > > > Hello Ambarish, > > > > Thanks for your reply. I agree that OCSP services are by far better than > > CRLs. In general, as everyone knows, a CRL is a batch job that updates a > > database over certain intervals. From an audit standpoint, one of the many > > issues with CRLs is that they can be beat. For example, it is very easy to > > perform any series of denial of service attacks against the server. This > > could cause longer than expected delays in the execution of the batch job > > or worse, prevent the batch job from running causing latent (or corrupted) > > CRL publishing. Also, if someone is savvy enough, they could also issue > > hundreds of back to back CRL job requests resulting in multiple jobs > > waiting on shared services again causing problematic CRLs. I know this may > > sound farfetched but they are risks to be considered. > > > > As you may guess I am not a proponent of CRLs for obvious reasons. I have > > heard claims by some that their products are OCSP compliant. In reality it > > is just a batch job publishing to a database but still they have inherent > > CRL batch job latency. > > > > As for the CAM, I am not familiar enough with that to argue for or against > > its use. I do know however that the Xcert product has a non proprietary > > real time OCSP LDAP out of the box resulting in a more robust product. > Note > > that the Sentry CA product can publish CRLs to non OCSP products to offer > > backwards compatibility when needed. Also, the Sentry product can import > > other vendors CRLs and place them in the real time OCSP LDAP. > > > > Also one of the several reasons that Sentry CA was chosen was due to its > > ability to cross certify against other CAs (cross certification). It is > > very easy to setup trust to another company's CA allowing multiple CAs or > > PKI vendors within a central Sentry OCSP environment. > > > > Best regards, > > > > Tom > > > > > > Ambarish Malpani wrote: > > > > > Hi Tom, > > > > > > It really isn't that hard to set up quite a few of the CAs to > > > create a new CRL whenever a new revocation happens. > > > > > > Think of this CRL as a snapshot of the CA's revocation database > > > and the publishing of a new CRL as a trigger to tell the OCSP > > > server that the snapshot has changed. > > > > > > Really, an OCSP server can be set up to be as current as any other > > > software to provide revocation information, either with or without > > > CRLs. > > > > > > It is completely unclear to me why the CAM solution is any > > > more real time than OCSP. I believe the real reason for the > > > CAM solution was just that OCSP didn't exist as a standard till > > > late in the ACES project as indicated by the mails from both > > > Judith and Tim. I have a suspicion that it still might be faster > > > and cheaper for ACES to go with OCSP, rather than try to stick to > > > a non-standard protocol. > > > > > > Regards, > > > Ambarish > > > > > > --------------------------------------------------------------------- > > > Ambarish Malpani > > > Architect 650.567.5457 > > > ValiCert, Inc. ambarish@valicert.com > > > 339 N. Bernardo Ave. http://www.valicert.com > > > Mountain View, CA 94043 > > > > > > > -----Original Message----- > > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > > Subject: Re: President Clinton digital signing > > > > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > > dosent seem to want to > > > > embrace OCSP as a validation mechanism for ACES (and other > > > > programs)??". > > > > You have to remember that ACES does have built in OCSP. The > > > > product that they > > > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > > > > > Please review the following URLs to see how and why Xcert was chosen: > > > > > > > > ACES announcement: > > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > > > Reference to digital signature law: > > > > http://www.xcert.com/resources/esign/index.html > > > > > > > > Sentry CA functionality: > > > > http://www.xcert.com/software/sentryca.html > > > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > > > this is very interexting, can somebody please comment on > > > > why the US govt > > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > > they call it sems > > > > > to be an alternative mechanism....a duplication of much of > > > > the work OCSP has > > > > > already worked through... > > > > > > > > > > -j > > > > > > > > > > -----Original Message----- > > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > > To: ietf-pkix@imc.org > > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > > Subject: RE: President Clinton digital signing > > > > > > > > > > Terri suggests that the real significance of the > > > > certificate and smart card > > > > > used by President Clinton is that they were obtained > > > > through the Access > > > > > Certificates for Electronic Services (ACES) contract at > > > > GSA. Through the > > > > > use of a Certificate Arbitrator Module (CAM), which is > > > > effectively a parser > > > > > and validation tool (offered to public domain by GSA), > > > > multiple CA's are > > > > > made available to the government applications. > > > > > > > > > > More info at > > > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > > > To me, though, the most significant thing is that the > > > > E-Sign bill was > > > > > signed, regardless of the technology utilized. > > > > > > > > > > Cheers, > > > > > > --------------EF40674896C109D7FA4935E6 Content-Type: text/x-vcard; charset=us-ascii; name="tstrickland.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tom Strickland Content-Disposition: attachment; filename="tstrickland.vcf" begin:vcard n:Strickland;Tom tel;cell:678 296-4866 x-mozilla-html:TRUE org:
Xcert International Inc. adr:;;;;;; version:2.1 email;internet:tstrickland@xcert.com fn:Tom Strickland end:vcard --------------EF40674896C109D7FA4935E6-- Received: from scog-ws3.gsa.gov (host.159-142-144-58.gsa.gov [159.142.144.58]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA07907 for ; Wed, 23 Aug 2000 03:59:17 -0700 (PDT) From: judith.spencer@gsa.gov Received: from 159.142.144.55 by scog-ws3.gsa.gov with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Wed, 23 Aug 2000 06:59:57 -0400 X-Server-Uuid: cb2f616c-ae65-11d3-874c-00508b6362bc Subject: Re: President Clinton digital signing To: awa1@home.com cc: tstrickland@xcert.com, spinneyj@flashcom.net, ietf-pkix@imc.org, judith.spencer@gsa.gov, yuriy.dzambasow@digsigtrust.com, kcummins@digsigtrust.com Sender: judith.spencer@gsa.gov Date: Wed, 23 Aug 2000 06:59:47 -0400 Message-ID: X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on SCOG-NOTESSMTP1/GSAEXTERNAL(Release 5.0.1b|September 30, 1999) at 08/23/2000 06:59:57 AM MIME-Version: 1.0 X-WSS-ID: 15BD712738537-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit At the time of the Presidential signing, only Digital Signature Trust had completed the exhaustive certification and accreditation process required by GSA in order to receive authorization to issue ACES certificates (AT&T has now been certified, ORC is still in the process). The DST ACES solution that was certified uses the XCERT product (this was a decision made by DST, not mandated by the government). Therefore, on June 29, under the ACES contract, only DST was authorized to issue certificates, and the system certified to issue those certificates utilized the XCERT CA. Judy Spencer GSA "Al Arsenault" on 08/22/2000 03:00:23 PM To: "Tom Strickland" cc: spinneyj@flashcom.net, "ietf-pkix@imc.org" , judith.spencer@gsa.gov, yuriy.dzambasow@digsigtrust.com Subject: Re: President Clinton digital signing Tom Strickland wrote: > > Please review the following URLs to see how and why Xcert was chosen: > > That's all fine and dandy, but I thought that the question was: "Why was a DST/XCert certificate selected for use, vice something from one of the other ACES contractors?" Since IIRC DST had the first ACES contract, I can certainly see giving them this task. But was there any special reason DST chose XCert, since DST provides certificates using most if not all of the major CA providers' equipments? Al Arsenault Chief Security Architect Diversinet Corp. Received: from tantalum (tantalum.btinternet.com [194.73.73.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA27482 for ; Wed, 23 Aug 2000 01:41:37 -0700 (PDT) Received: from [62.6.79.185] (helo=vaio) by tantalum with smtp (Exim 3.03 #83) id 13RW6i-0005qr-00 for ietf-pkix@imc.org; Wed, 23 Aug 2000 09:42:00 +0100 Message-ID: <001c01c00cde$64c6d840$68bc01d5@vaio> Reply-To: "Liaquat Khan" From: "Liaquat Khan" To: References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> <39A34EFD.2DE9A602@xcert.com> Subject: Re: President Clinton digital signing Date: Wed, 23 Aug 2000 09:44:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 You have to assume that access to the server which issues CRLs is protected from denial of service attacks. For example, generally only trusted operators can authorise the generation of CRLs, after having their identities authenticated by the server. Also access to the CRL issuer has to be protected through firewalls, etc. If an attacker can perform a DoS attack on a CRL issuer, what is there to stop him/her launching a similar attack on an OCSP server (e.g. by issuing an extremely large amount of OCSP requests)? Regards, Liaquat Khan Technical Manager Global Trust Authority (GTA) ----- Original Message ----- From: Tom Strickland To: Ambarish Malpani Cc: ; Sent: Wednesday, August 23, 2000 5:11 AM Subject: Re: President Clinton digital signing > Hello Ambarish, > > Thanks for your reply. I agree that OCSP services are by far better than > CRLs. In general, as everyone knows, a CRL is a batch job that updates a > database over certain intervals. From an audit standpoint, one of the many > issues with CRLs is that they can be beat. For example, it is very easy to > perform any series of denial of service attacks against the server. This > could cause longer than expected delays in the execution of the batch job > or worse, prevent the batch job from running causing latent (or corrupted) > CRL publishing. Also, if someone is savvy enough, they could also issue > hundreds of back to back CRL job requests resulting in multiple jobs > waiting on shared services again causing problematic CRLs. I know this may > sound farfetched but they are risks to be considered. > > As you may guess I am not a proponent of CRLs for obvious reasons. I have > heard claims by some that their products are OCSP compliant. In reality it > is just a batch job publishing to a database but still they have inherent > CRL batch job latency. > > As for the CAM, I am not familiar enough with that to argue for or against > its use. I do know however that the Xcert product has a non proprietary > real time OCSP LDAP out of the box resulting in a more robust product. Note > that the Sentry CA product can publish CRLs to non OCSP products to offer > backwards compatibility when needed. Also, the Sentry product can import > other vendors CRLs and place them in the real time OCSP LDAP. > > Also one of the several reasons that Sentry CA was chosen was due to its > ability to cross certify against other CAs (cross certification). It is > very easy to setup trust to another company's CA allowing multiple CAs or > PKI vendors within a central Sentry OCSP environment. > > Best regards, > > Tom > > > Ambarish Malpani wrote: > > > Hi Tom, > > > > It really isn't that hard to set up quite a few of the CAs to > > create a new CRL whenever a new revocation happens. > > > > Think of this CRL as a snapshot of the CA's revocation database > > and the publishing of a new CRL as a trigger to tell the OCSP > > server that the snapshot has changed. > > > > Really, an OCSP server can be set up to be as current as any other > > software to provide revocation information, either with or without > > CRLs. > > > > It is completely unclear to me why the CAM solution is any > > more real time than OCSP. I believe the real reason for the > > CAM solution was just that OCSP didn't exist as a standard till > > late in the ACES project as indicated by the mails from both > > Judith and Tim. I have a suspicion that it still might be faster > > and cheaper for ACES to go with OCSP, rather than try to stick to > > a non-standard protocol. > > > > Regards, > > Ambarish > > > > --------------------------------------------------------------------- > > Ambarish Malpani > > Architect 650.567.5457 > > ValiCert, Inc. ambarish@valicert.com > > 339 N. Bernardo Ave. http://www.valicert.com > > Mountain View, CA 94043 > > > > > -----Original Message----- > > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > > Sent: Tuesday, August 22, 2000 9:18 AM > > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > > Subject: Re: President Clinton digital signing > > > > > > > > > You are correct to ask "why the US govt (GSA, at least) > > > dosent seem to want to > > > embrace OCSP as a validation mechanism for ACES (and other > > > programs)??". > > > You have to remember that ACES does have built in OCSP. The > > > product that they > > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > > > Please review the following URLs to see how and why Xcert was chosen: > > > > > > ACES announcement: > > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > > > Reference to digital signature law: > > > http://www.xcert.com/resources/esign/index.html > > > > > > Sentry CA functionality: > > > http://www.xcert.com/software/sentryca.html > > > > > > Scalability to manage over 8 million certs on one CA and box: > > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > > > > > jspinney@securify.com wrote: > > > > > > > this is very interexting, can somebody please comment on > > > why the US govt > > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > > mechanism for ACES (and other programs)?? the 'CAM' as > > > they call it sems > > > > to be an alternative mechanism....a duplication of much of > > > the work OCSP has > > > > already worked through... > > > > > > > > -j > > > > > > > > -----Original Message----- > > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > > To: ietf-pkix@imc.org > > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > > Subject: RE: President Clinton digital signing > > > > > > > > Terri suggests that the real significance of the > > > certificate and smart card > > > > used by President Clinton is that they were obtained > > > through the Access > > > > Certificates for Electronic Services (ACES) contract at > > > GSA. Through the > > > > use of a Certificate Arbitrator Module (CAM), which is > > > effectively a parser > > > > and validation tool (offered to public domain by GSA), > > > multiple CA's are > > > > made available to the government applications. > > > > > > > > More info at > > > > > > > > http://www.gsa.gov/aces/ > > > > > > > > To me, though, the most significant thing is that the > > > E-Sign bill was > > > > signed, regardless of the technology utilized. > > > > > > > > Cheers, > > > > Received: from crack.x509.com (root@crack.x509.com [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA07656 for ; Tue, 22 Aug 2000 21:07:59 -0700 (PDT) Received: from xcert.com (home.x509.com [199.175.150.4]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e7N48KS24473; Tue, 22 Aug 2000 21:08:21 -0700 (PDT) Message-ID: <39A34EFD.2DE9A602@xcert.com> Date: Wed, 23 Aug 2000 00:11:41 -0400 From: Tom Strickland X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ambarish Malpani CC: spinneyj@flashcom.net, ietf-pkix@imc.org Subject: Re: President Clinton digital signing References: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> Content-Type: multipart/mixed; boundary="------------0F6F7A326065ABAF0A48764C" This is a multi-part message in MIME format. --------------0F6F7A326065ABAF0A48764C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Ambarish, Thanks for your reply. I agree that OCSP services are by far better than CRLs. In general, as everyone knows, a CRL is a batch job that updates a database over certain intervals. From an audit standpoint, one of the many issues with CRLs is that they can be beat. For example, it is very easy to perform any series of denial of service attacks against the server. This could cause longer than expected delays in the execution of the batch job or worse, prevent the batch job from running causing latent (or corrupted) CRL publishing. Also, if someone is savvy enough, they could also issue hundreds of back to back CRL job requests resulting in multiple jobs waiting on shared services again causing problematic CRLs. I know this may sound farfetched but they are risks to be considered. As you may guess I am not a proponent of CRLs for obvious reasons. I have heard claims by some that their products are OCSP compliant. In reality it is just a batch job publishing to a database but still they have inherent CRL batch job latency. As for the CAM, I am not familiar enough with that to argue for or against its use. I do know however that the Xcert product has a non proprietary real time OCSP LDAP out of the box resulting in a more robust product. Note that the Sentry CA product can publish CRLs to non OCSP products to offer backwards compatibility when needed. Also, the Sentry product can import other vendors CRLs and place them in the real time OCSP LDAP. Also one of the several reasons that Sentry CA was chosen was due to its ability to cross certify against other CAs (cross certification). It is very easy to setup trust to another company's CA allowing multiple CAs or PKI vendors within a central Sentry OCSP environment. Best regards, Tom Ambarish Malpani wrote: > Hi Tom, > > It really isn't that hard to set up quite a few of the CAs to > create a new CRL whenever a new revocation happens. > > Think of this CRL as a snapshot of the CA's revocation database > and the publishing of a new CRL as a trigger to tell the OCSP > server that the snapshot has changed. > > Really, an OCSP server can be set up to be as current as any other > software to provide revocation information, either with or without > CRLs. > > It is completely unclear to me why the CAM solution is any > more real time than OCSP. I believe the real reason for the > CAM solution was just that OCSP didn't exist as a standard till > late in the ACES project as indicated by the mails from both > Judith and Tim. I have a suspicion that it still might be faster > and cheaper for ACES to go with OCSP, rather than try to stick to > a non-standard protocol. > > Regards, > Ambarish > > --------------------------------------------------------------------- > Ambarish Malpani > Architect 650.567.5457 > ValiCert, Inc. ambarish@valicert.com > 339 N. Bernardo Ave. http://www.valicert.com > Mountain View, CA 94043 > > > -----Original Message----- > > From: Tom Strickland [mailto:tstrickland@xcert.com] > > Sent: Tuesday, August 22, 2000 9:18 AM > > To: spinneyj@flashcom.net; ietf-pkix@imc.org > > Subject: Re: President Clinton digital signing > > > > > > You are correct to ask "why the US govt (GSA, at least) > > dosent seem to want to > > embrace OCSP as a validation mechanism for ACES (and other > > programs)??". > > You have to remember that ACES does have built in OCSP. The > > product that they > > chose includes an OCSP "real time" responder, not antiquated CRLs. > > > > Please review the following URLs to see how and why Xcert was chosen: > > > > ACES announcement: > > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > > > Reference to digital signature law: > > http://www.xcert.com/resources/esign/index.html > > > > Sentry CA functionality: > > http://www.xcert.com/software/sentryca.html > > > > Scalability to manage over 8 million certs on one CA and box: > > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > > > > > jspinney@securify.com wrote: > > > > > this is very interexting, can somebody please comment on > > why the US govt > > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > > mechanism for ACES (and other programs)?? the 'CAM' as > > they call it sems > > > to be an alternative mechanism....a duplication of much of > > the work OCSP has > > > already worked through... > > > > > > -j > > > > > > -----Original Message----- > > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > > Sent: Tuesday, August 22, 2000 8:52 AM > > > To: ietf-pkix@imc.org > > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > > Subject: RE: President Clinton digital signing > > > > > > Terri suggests that the real significance of the > > certificate and smart card > > > used by President Clinton is that they were obtained > > through the Access > > > Certificates for Electronic Services (ACES) contract at > > GSA. Through the > > > use of a Certificate Arbitrator Module (CAM), which is > > effectively a parser > > > and validation tool (offered to public domain by GSA), > > multiple CA's are > > > made available to the government applications. > > > > > > More info at > > > > > > http://www.gsa.gov/aces/ > > > > > > To me, though, the most significant thing is that the > > E-Sign bill was > > > signed, regardless of the technology utilized. > > > > > > Cheers, > > --------------0F6F7A326065ABAF0A48764C Content-Type: text/x-vcard; charset=us-ascii; name="tstrickland.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tom Strickland Content-Disposition: attachment; filename="tstrickland.vcf" begin:vcard n:Strickland;Tom tel;cell:678 296-4866 x-mozilla-html:TRUE org:
Xcert International Inc. adr:;;;;;; version:2.1 email;internet:tstrickland@xcert.com fn:Tom Strickland end:vcard --------------0F6F7A326065ABAF0A48764C-- Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA22488 for ; Tue, 22 Aug 2000 18:36:18 -0700 (PDT) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0FZQ007011T0DU@ext-mail.valicert.com> for ietf-pkix@imc.org; Tue, 22 Aug 2000 18:36:36 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0FZQ007BJ1T00X@ext-mail.valicert.com>; Tue, 22 Aug 2000 18:36:36 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Tue, 22 Aug 2000 18:26:31 -0700 Content-return: allowed Date: Tue, 22 Aug 2000 18:26:26 -0700 From: Ambarish Malpani Subject: RE: President Clinton digital signing To: "'Tom Strickland'" , spinneyj@flashcom.net, ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE201B8310D@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Hi Tom, It really isn't that hard to set up quite a few of the CAs to create a new CRL whenever a new revocation happens. Think of this CRL as a snapshot of the CA's revocation database and the publishing of a new CRL as a trigger to tell the OCSP server that the snapshot has changed. Really, an OCSP server can be set up to be as current as any other software to provide revocation information, either with or without CRLs. It is completely unclear to me why the CAM solution is any more real time than OCSP. I believe the real reason for the CAM solution was just that OCSP didn't exist as a standard till late in the ACES project as indicated by the mails from both Judith and Tim. I have a suspicion that it still might be faster and cheaper for ACES to go with OCSP, rather than try to stick to a non-standard protocol. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Tom Strickland [mailto:tstrickland@xcert.com] > Sent: Tuesday, August 22, 2000 9:18 AM > To: spinneyj@flashcom.net; ietf-pkix@imc.org > Subject: Re: President Clinton digital signing > > > You are correct to ask "why the US govt (GSA, at least) > dosent seem to want to > embrace OCSP as a validation mechanism for ACES (and other > programs)??". > You have to remember that ACES does have built in OCSP. The > product that they > chose includes an OCSP "real time" responder, not antiquated CRLs. > > Please review the following URLs to see how and why Xcert was chosen: > > ACES announcement: > http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html > > Reference to digital signature law: > http://www.xcert.com/resources/esign/index.html > > Sentry CA functionality: > http://www.xcert.com/software/sentryca.html > > Scalability to manage over 8 million certs on one CA and box: > http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html > > > > jspinney@securify.com wrote: > > > this is very interexting, can somebody please comment on > why the US govt > > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > > mechanism for ACES (and other programs)?? the 'CAM' as > they call it sems > > to be an alternative mechanism....a duplication of much of > the work OCSP has > > already worked through... > > > > -j > > > > -----Original Message----- > > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > > Sent: Tuesday, August 22, 2000 8:52 AM > > To: ietf-pkix@imc.org > > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > > Subject: RE: President Clinton digital signing > > > > Terri suggests that the real significance of the > certificate and smart card > > used by President Clinton is that they were obtained > through the Access > > Certificates for Electronic Services (ACES) contract at > GSA. Through the > > use of a Certificate Arbitrator Module (CAM), which is > effectively a parser > > and validation tool (offered to public domain by GSA), > multiple CA's are > > made available to the government applications. > > > > More info at > > > > http://www.gsa.gov/aces/ > > > > To me, though, the most significant thing is that the > E-Sign bill was > > signed, regardless of the technology utilized. > > > > Cheers, > Received: from sina.com ([202.106.187.168]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA22263 for ; Tue, 22 Aug 2000 18:34:57 -0700 (PDT) Received: (qmail 10898 invoked by uid 99); 23 Aug 2000 01:36:46 -0000 Message-ID: <20000823013646.10897.qmail@sina.com> From: wangbingyan168 To: ietf-pkix@imc.org Subject: Date: Wed Aug 23 01:36:46 2000 X-Mailer: SinaMail 3.0Beta (FireToad) X-Priority: 3 Who can tell me how can I join in the PKI(?PKIX) workgrop? Thanks a lot! ______________________________________ =================================================================== ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn ¾´Çë¹Ø×¢ 8ÔÂ27ÈÕ19µã45·Ö ºþÄÏÎÀÊÓ<õ¹åÖ®Ô¼> ÐÂÀË°ÂÔËÇéÂÂÌØʹ¾öÈü http://ad2.sina.com.cn/ads/olympics/ Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19052 for ; Tue, 22 Aug 2000 18:08:14 -0700 (PDT) Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id SAA03085; Tue, 22 Aug 2000 18:05:23 -0700 (PDT) Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id ; Tue, 22 Aug 2000 18:07:36 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EBE7@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'marion.royal@gsa.gov'" , ietf-pkix@imc.org Cc: terri.hobson@gsa.gov, judith.spencer@gsa.gov Subject: RE: President Clinton digital signing Date: Tue, 22 Aug 2000 18:07:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_0009_01C00C7D.2D1EC350"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C00C7D.2D1EC350 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > To me, though, the most significant thing is that the E-Sign bill was > signed, regardless of the technology utilized. And it was totally illogical to use a digital signature for the purpose. The act is now effectively a self-signed cert! The validity of the authentication on the act is established through a circular reference to the act itself. Phill ------=_NextPart_000_0009_01C00C7D.2D1EC350 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINaDCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEFDCCA32gAwIBAgIQ AxTuqrYcesW8jpUyudZ0/DANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNOTkxMjIwMDAwMDAwWhcNMDAx MjE5MjM1OTU5WjBsMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNTAzBgNVBAMTLHBiYWtlciAoUGhpbGlwIEhhbGxhbS1CYWtlciwgVmVyaVNpZ24s IEluYy4pMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3f0kRIy2AU5cHhfnUwuHecFNq6dnf /wsvxS//4Nt8rFgr2KdvQETKaQ6wGl6mVijB6udZW9dUKVoE1lnu2MMcIhtAL3+Q2dsrxlrTInfq PKAdxu/Fvb4n3Y0RItW9zh1MzFWZ8Q9z6eF2HuBwG6ANfRzfJgironyftbbitRyaxQIDAQABo4IB dDCCAXAwCQYDVR0TBAIwADBVBgNVHR8ETjBMMEqgSKBGhkRodHRwOi8vb25zaXRlY3JsLnZlcmlz aWduLmNvbS9WZXJpU2lnbkluY0V4Y2hhbmdlRW1wbG95ZWVzL0xhdGVzdENSTDALBgNVHQ8EBAMC BaAwHgYDVR0RBBcwFYETcGJha2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgB hvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4g YnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeA MB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQAaUApBXCjc mPE5dFPHlQVl4n9WoOU7AE487xxC7vcR1MDhF8p/0GMu6zOyZe9CFVaOndaYCRgv69qKTVoANmsM F/eFsQn/HaoXEz+jHPNgWcPyBu3dujO9s2PLQbuBXE3rIaDiVyTftVgoNvO0fcknSlNOWxqHvbaH 9RYvhMghkjGCAvgwggL0AgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVy bXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVy aVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAJBgUrDgMCGgUAoIIB jDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDA4MjMwMTA4NTNa MCMGCSqGSIb3DQEJBDEWBBSOANK+0G2grL5vtgDvkXg3YlGlvzBYBgkqhkiG9w0BCQ8xSzBJMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjAKBggqhkiG9w0CBTCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEl MCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAN BgkqhkiG9w0BAQEFAASBgHbayQ5M3INMkvbrRjh2O3x1FPPI3AGCP8boETGBtHXLT42aqKJq0kjp /YFt+rHbxIlz89eQh8sQ2TxjAqNB6ip4o7Wg0R8VvPPqef4R5CEcHaLtW+HXWp8HqErwk6kBhTy8 X1WQyp61qnuaWvUS51oKFsU9c8bm5CdTeW+HfHXcAAAAAAAA ------=_NextPart_000_0009_01C00C7D.2D1EC350-- Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11632 for ; Tue, 22 Aug 2000 12:00:42 -0700 (PDT) Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000822190103.EQDO4590.mail.rdc1.md.home.com@home.com>; Tue, 22 Aug 2000 12:01:03 -0700 Message-ID: <39A2CDC7.4800F20@home.com> Date: Tue, 22 Aug 2000 15:00:23 -0400 From: Al Arsenault Organization: @Home Network X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Strickland CC: spinneyj@flashcom.net, "ietf-pkix@imc.org" , judith.spencer@gsa.gov, yuriy.dzambasow@digsigtrust.com Subject: Re: President Clinton digital signing References: <008501c00c4c$53f42190$6501010a@jeffshouse.net> <39A2A7B0.BA4A8EF0@xcert.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tom Strickland wrote: > > Please review the following URLs to see how and why Xcert was chosen: > > That's all fine and dandy, but I thought that the question was: "Why was a DST/XCert certificate selected for use, vice something from one of the other ACES contractors?" Since IIRC DST had the first ACES contract, I can certainly see giving them this task. But was there any special reason DST chose XCert, since DST provides certificates using most if not all of the major CA providers' equipments? Al Arsenault Chief Security Architect Diversinet Corp. Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08968 for ; Tue, 22 Aug 2000 10:50:40 -0700 (PDT) Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id KAA10349; Tue, 22 Aug 2000 10:47:03 -0700 (PDT) Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id ; Tue, 22 Aug 2000 10:49:17 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4F93A91@vhqpostal.verisign.com> From: Michael Myers To: Sam Schaen , "'ietf-pkix@imc.org'" Subject: OCSP edits Date: Tue, 22 Aug 2000 10:49:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sam, all: I'm currently accumulating edits to RFC 2560's syntax and semantics for the WG's consideration and hope to have a draft revision out by 15 Sept. I agree with Sam Schaen that it's important to reinforce that an OCSP responder have the most current revocation information. While assumed, this in not as apparent in the Proposed Standard as it should be. I'll fold into the delta Sam's recommended text as we move 2560 forward. This delta will include, among other edits, the module specification I received from Russ in Adelaide. Mike Received: from cnbskpt2.cnbs.navy.mil (cnbskpt2.cnbs.navy.mil [164.221.184.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07007 for ; Tue, 22 Aug 2000 10:25:25 -0700 (PDT) Received: by cnbskpt2.cnbs.navy.mil with Internet Mail Service (5.5.2650.21) id ; Tue, 22 Aug 2000 10:21:22 -0700 Message-ID: <07278C38CF83D21181B200105AA34A859DD4FF@cnbskpt2.cnbs.navy.mil> From: "Morrill, Dan" To: "'Tom Strickland'" , spinneyj@flashcom.net, ietf-pkix@imc.org Subject: RE: President Clinton digital signing Date: Tue, 22 Aug 2000 10:21:16 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) For specific information about the CAM and its status, please check out http://cam.fts.gsa.gov/ Cheers, r/ Dan -----Original Message----- From: Tom Strickland [mailto:tstrickland@xcert.com] Sent: Tuesday, August 22, 2000 09:18 AM To: spinneyj@flashcom.net; ietf-pkix@imc.org Subject: Re: President Clinton digital signing You are correct to ask "why the US govt (GSA, at least) dosent seem to want to embrace OCSP as a validation mechanism for ACES (and other programs)??". You have to remember that ACES does have built in OCSP. The product that they chose includes an OCSP "real time" responder, not antiquated CRLs. Please review the following URLs to see how and why Xcert was chosen: ACES announcement: http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html Reference to digital signature law: http://www.xcert.com/resources/esign/index.html Sentry CA functionality: http://www.xcert.com/software/sentryca.html Scalability to manage over 8 million certs on one CA and box: http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html jspinney@securify.com wrote: > this is very interexting, can somebody please comment on why the US govt > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > mechanism for ACES (and other programs)?? the 'CAM' as they call it sems > to be an alternative mechanism....a duplication of much of the work OCSP has > already worked through... > > -j > > -----Original Message----- > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > Sent: Tuesday, August 22, 2000 8:52 AM > To: ietf-pkix@imc.org > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > Subject: RE: President Clinton digital signing > > Terri suggests that the real significance of the certificate and smart card > used by President Clinton is that they were obtained through the Access > Certificates for Electronic Services (ACES) contract at GSA. Through the > use of a Certificate Arbitrator Module (CAM), which is effectively a parser > and validation tool (offered to public domain by GSA), multiple CA's are > made available to the government applications. > > More info at > > http://www.gsa.gov/aces/ > > To me, though, the most significant thing is that the E-Sign bill was > signed, regardless of the technology utilized. > > Cheers, Received: from crack.x509.com (root@crack.x509.com [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03606 for ; Tue, 22 Aug 2000 09:13:57 -0700 (PDT) Received: from xcert.com (home.x509.com [199.175.150.4]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e7MGEGS10919; Tue, 22 Aug 2000 09:14:16 -0700 (PDT) Message-ID: <39A2A7B0.BA4A8EF0@xcert.com> Date: Tue, 22 Aug 2000 12:17:52 -0400 From: Tom Strickland X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: spinneyj@flashcom.net, "ietf-pkix@imc.org" Subject: Re: President Clinton digital signing References: <008501c00c4c$53f42190$6501010a@jeffshouse.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDB0DAD23CD019D3A969F9422" This is a cryptographically signed message in MIME format. --------------msDB0DAD23CD019D3A969F9422 Content-Type: multipart/mixed; boundary="------------C0DBA348AF658542728DE7AB" This is a multi-part message in MIME format. --------------C0DBA348AF658542728DE7AB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit You are correct to ask "why the US govt (GSA, at least) dosent seem to want to embrace OCSP as a validation mechanism for ACES (and other programs)??". You have to remember that ACES does have built in OCSP. The product that they chose includes an OCSP "real time" responder, not antiquated CRLs. Please review the following URLs to see how and why Xcert was chosen: ACES announcement: http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html Reference to digital signature law: http://www.xcert.com/resources/esign/index.html Sentry CA functionality: http://www.xcert.com/software/sentryca.html Scalability to manage over 8 million certs on one CA and box: http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html jspinney@securify.com wrote: > this is very interexting, can somebody please comment on why the US govt > (GSA, at least) doesnt seem to want to embrace OCSP as a validation > mechanism for ACES (and other programs)?? the 'CAM' as they call it sems > to be an alternative mechanism....a duplication of much of the work OCSP has > already worked through... > > -j > > -----Original Message----- > From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] > Sent: Tuesday, August 22, 2000 8:52 AM > To: ietf-pkix@imc.org > Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov > Subject: RE: President Clinton digital signing > > Terri suggests that the real significance of the certificate and smart card > used by President Clinton is that they were obtained through the Access > Certificates for Electronic Services (ACES) contract at GSA. Through the > use of a Certificate Arbitrator Module (CAM), which is effectively a parser > and validation tool (offered to public domain by GSA), multiple CA's are > made available to the government applications. > > More info at > > http://www.gsa.gov/aces/ > > To me, though, the most significant thing is that the E-Sign bill was > signed, regardless of the technology utilized. > > Cheers, --------------C0DBA348AF658542728DE7AB Content-Type: text/x-vcard; charset=us-ascii; name="tstrickland.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tom Strickland Content-Disposition: attachment; filename="tstrickland.vcf" begin:vcard n:Strickland;Tom tel;cell:678 296-4866 x-mozilla-html:TRUE org:
Xcert International Inc. adr:;;;;;; version:2.1 email;internet:tstrickland@xcert.com fn:Tom Strickland end:vcard --------------C0DBA348AF658542728DE7AB-- --------------msDB0DAD23CD019D3A969F9422 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIEtQYJKoZIhvcNAQcCoIIEpjCCBKICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Aq0wggKpMIICEgIRAMevlgMAAAJ8AAAARgAAABswDQYJKoZIhvcNAQEEBQAwYTEcMBoGA1UE ChMTWGNlcnQgU29mdHdhcmUgSW5jLjEfMB0GA1UECxMWSW50ZXJuYWwgUmVwb3NpdG9yeSBD QTEgMB4GCSqGSIb3DQEJARYRc3VwcG9ydEB4Y2VydC5jb20wHhcNMDAwMjAzMTgyMTM1WhcN MzcxMjE2MTgyMTM1WjCByDELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0dlb3JnaWExEzARBgNV BAcTCkFscGhhcmV0dGExITAfBgNVBAoTGFhjZXJ0IEludGVybmF0aW9uYWwgSW5jLjETMBEG A1UECxMKd2FzaGluZ3RvbjEXMBUGA1UEAxMOVG9tIFN0cmlja2xhbmQxJDAiBgkqhkiG9w0B CQEWFXRzdHJpY2tsYW5kQHhjZXJ0LmNvbTEbMBkGCgmSJomT8ixkAQETC3RzdHJpY2tsYW5k MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDIpwUFKnmwbvpjbD8fYi9jrLDQdaZoHG2 qBXH3P+pBThxsfwx/FoFalPxo3LeM1lHaSu1sC+jhu9AT5U+3qJ0WCWF1uVabV1aTH6XKKgv rX3fGOruVzRm3YXVE1yEF0uQfUSzb+hPBXy2RCj2gX4swrjhl1NkaPVXUS+r/CbFiQIDAQAB MA0GCSqGSIb3DQEBBAUAA4GBAIxBn4Hwr5I8BJeub2feuRCyfXKQeKAXqKD9sboeFnlGTTEA xoEpmUI1rYwG6CzVQnmut+/1FUpWixRx/g/gQYnu5EQa1/0yKEvo9SPbhq48ksadKzEVYdTP 0ICWEaj68mgJDVfCBETAjZlUC4r/gLz94xW5R6JsluP56aJV5a1hMYIB0DCCAcwCAQEwdjBh MRwwGgYDVQQKExNYY2VydCBTb2Z0d2FyZSBJbmMuMR8wHQYDVQQLExZJbnRlcm5hbCBSZXBv c2l0b3J5IENBMSAwHgYJKoZIhvcNAQkBFhFzdXBwb3J0QHhjZXJ0LmNvbQIRAMevlgMAAAJ8 AAAARgAAABswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMDA4MjIxNjE3NTJaMCMGCSqGSIb3DQEJBDEWBBQXudqUXJ9HgWTgYslD X7RPl2fL5DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gAEWT2EEYrIc6n0VT3x5PFSeIWuhsY2iEoJIdgQpigwqSznqlK61bJdh7ikuxyOMyzzc1foY LYSeWO17btcNjYhstgrGVUUz8C04HfHuCmhlg8BCjLXrMAFZN7IqP7V8xNtRIC8xbrXiuvPI 0xPkoKIdLIxFXigN4PhDpqDP+rtS --------------msDB0DAD23CD019D3A969F9422-- Received: from scog-ws3.gsa.gov (host.159-142-144-58.gsa.gov [159.142.144.58]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA02193 for ; Tue, 22 Aug 2000 08:57:42 -0700 (PDT) From: judith.spencer@gsa.gov Received: from 159.142.144.55 by scog-ws3.gsa.gov with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Tue, 22 Aug 2000 11:58:18 -0400 X-Server-Uuid: cb2f616c-ae65-11d3-874c-00508b6362bc Subject: RE: President Clinton digital signing To: spinneyj@flashcom.net cc: marion.royal@gsa.gov, ietf-pkix@imc.org, terri.hobson@gsa.gov, judith.spencer@gsa.gov, rsalz@caveosystems.com, stanley.choffrey@gsa.gov Sender: judith.spencer@gsa.gov Date: Tue, 22 Aug 2000 11:58:07 -0400 Message-ID: X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on SCOG-NOTESSMTP1/GSAEXTERNAL(Release 5.0.1b|September 30, 1999) at 08/22/2000 11:58:18 AM MIME-Version: 1.0 X-WSS-ID: 15BC7C90141665-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit GSA has no reluctance to embracing OCSP, and is moving in that direction. However, when CAM development was begun OCSP was not yet a standard. We held several industry forums and asked the attendees whether we should ascribe to OCSP or develop something generic. The unanimous response was to do something generic, since they did not want to be tied to a specific solution. We listened. Since then OCSP became a standard, and now, of course, there has been an about-face on everyone's opinion. The CAM will embrace OCSP in its future development. Thanks Judy Spencer jspinney@securify.com@flashcom.net> on 08/22/2000 11:19:12 AM Please respond to spinneyj@flashcom.net Sent by: "Jeff Spinney" To: marion.royal@gsa.gov, ietf-pkix@imc.org cc: terri.hobson@gsa.gov, judith.spencer@gsa.gov, rsalz@caveosystems.com Subject: RE: President Clinton digital signing this is very interexting, can somebody please comment on why the US govt (GSA, at least) doesnt seem to want to embrace OCSP as a validation mechanism for ACES (and other programs)?? the 'CAM' as they call it sems to be an alternative mechanism....a duplication of much of the work OCSP has already worked through... -j -----Original Message----- From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] Sent: Tuesday, August 22, 2000 8:52 AM To: ietf-pkix@imc.org Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov Subject: RE: President Clinton digital signing Terri suggests that the real significance of the certificate and smart card used by President Clinton is that they were obtained through the Access Certificates for Electronic Services (ACES) contract at GSA. Through the use of a Certificate Arbitrator Module (CAM), which is effectively a parser and validation tool (offered to public domain by GSA), multiple CA's are made available to the government applications. More info at http://www.gsa.gov/aces/ To me, though, the most significant thing is that the E-Sign bill was signed, regardless of the technology utilized. Cheers, Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA00512 for ; Tue, 22 Aug 2000 08:44:47 -0700 (PDT) Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id LAA18372; Tue, 22 Aug 2000 11:45:04 -0400 (EDT) Message-Id: <4.2.0.58.20000822113227.00cfeb60@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 22 Aug 2000 11:44:01 -0400 To: , , From: Tim Polk Subject: RE: President Clinton digital signing Cc: , , In-Reply-To: <008501c00c4c$53f42190$6501010a@jeffshouse.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed If the ACES project was starting today, they might very well have used OCSP. However, the ACES project was years in the making. No standard solution was available, and GSA could not afford to wait. Remember, OCSP didn't make it out of the editing queue until June 1999. GSA was well into the contracting process before OCSP was stable enough to consider. Considering the legal and contracting issues, GSA has done an amazing job bringing ACES on line. Hopefully, ACES will evolve to take advantage of the IETF protocols in the future. Tim At 11:19 AM 8/22/00 -0400, jspinney@securify.com wrote: >this is very interexting, can somebody please comment on why the US govt >(GSA, at least) doesnt seem to want to embrace OCSP as a validation >mechanism for ACES (and other programs)?? the 'CAM' as they call it sems >to be an alternative mechanism....a duplication of much of the work OCSP has >already worked through... > >-j > >-----Original Message----- >From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] >Sent: Tuesday, August 22, 2000 8:52 AM >To: ietf-pkix@imc.org >Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov >Subject: RE: President Clinton digital signing > > >Terri suggests that the real significance of the certificate and smart card >used by President Clinton is that they were obtained through the Access >Certificates for Electronic Services (ACES) contract at GSA. Through the >use of a Certificate Arbitrator Module (CAM), which is effectively a parser >and validation tool (offered to public domain by GSA), multiple CA's are >made available to the government applications. > >More info at > >http://www.gsa.gov/aces/ > >To me, though, the most significant thing is that the E-Sign bill was >signed, regardless of the technology utilized. > >Cheers, Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28530 for ; Tue, 22 Aug 2000 08:24:52 -0700 (PDT) Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id LAA29273; Tue, 22 Aug 2000 11:25:12 -0400 (EDT) Message-Id: <4.2.0.58.20000822105705.00cf7c00@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 22 Aug 2000 11:24:05 -0400 To: ietf-pkix@imc.org From: Tim Polk Subject: Re: excluding all names of given type Cc: Sharon Boeyen In-Reply-To: <39A179EC.24015.5CF9C00@localhost> References: <4.2.0.58.20000817130750.00c43200@email.nist.gov> <14748.311.613517.443300@east.sun.com> Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Folks,

I believe we have achieved consensus, and that Anne's original proposal should be incorporated into son-of-2459.  We have heard from Anne Anderson, John Wray, and David Chadwick on the list.  I also spoke to Sharon Boeyen on the phone.  Everyone agrees with David=20 that
"The null name *is* the name of the root of the DIT"
so we should use the null name in excludedSubtrees to exclude all names of type distinguished name (i.e, in the subject or directoryName in subjectAltName.)

John pointed out that
"An empty subject DN in a certificate doesn't  mean that the certificate applies to a principal whose DN is the root of  the DIT, rather that the principal in question has no DN. This is a special case, called out explicitly in the PKIX profile. A certificate=20
with an empty DN should be permitted regardless of any DN name constraints.So I don't think this requires that you set the minimum value to 1 - 0 should do just fine."

This means we do not have to change the specification with respect to minimum and maximum.

Anyway, I will draft some proposed text and forward it to the list in the next day or so...

Thanks!

Tim


At 06:50 PM 8/21/00 +0100, David Chadwick wrote:
Date sent:              Thu, 17 Aug 2000 13:55:59 -0400
To:                     Anne Anderson <Anne.Anderson@east.sun.com>, ietf-pkix@imc.org
From:                   Tim Polk <wpolk@nist.gov>
Subject:                Re: excluding all names of given type
Copies to:              Sharon Boeyen <sharon.boeyen@entrust.com>

Anne, I think I would state this in reverse. CASE: NameConstraints *includedSubtrees* contains a directoryName where the RDNSequence is NULL

has the

SEMANTICS: The Subject field and the directoryName field of the SubjectAlternativeName (if it appears at all) may only contain names in the subtree NULL for all successive certificates in the path.


The only name in the subtree NULL would be the exact match - the NULL value. That would work, since we require a NULL RDNSequence if the Subject is omitted. As Steve has pointed out, this should only occur in an end entity certificate.



Tim

I do not agree with your semantics. The null name is the name of the root of the DIT, and therefore implies ALL subordinate names. Since a DIT subtree can comprise a single entry or any number of entries up to the whole DIT, then a null name implies a subtree of the whole DIT. Thus include NULL implies include any directory name at all - not a particularly usefull extension to include in a certificate.

David

This is not particularly straightforward, I know. We are using the include feature to exclude names! However, it works *if* you consider the only name in the subtree NULL is NULL itself. On the other hand, you could consider NULL the implicit root of all subtrees, the correct answer is excludedSubtrees is NULL with a minimum value of 1. (We would need to set the minimum to 1 so that NULL itself was not excluded.) This would force us to use (and process) the minimum value. RFC 2459 states that the minimum and maximum never are used, so minimum is always zero. I prefer the *includedSubtrees* solution. The truth is, of course, as long as we pick one way and state it clearly we should be fine. I don't think the X.5xx specifications cover this issue, but I've been wrong before on that point! Sharon, do you know if this topic has been addressed anywhere before?? Our first consideration should be conformance to X.509 etc if a clear solution has been established. If this has not been addressed, we should sort it out ASAP. Thanks, Tim At 11:13 AM 8/17/00 -0400, Anne Anderson wrote:

CASE: NameConstraints excludedSubtrees contains a directoryName where the RDNSequence is null SEMANTICS: Does this mean that the subsequent path may contain no names of type directoryName in either Subject or the SubjectAlternativeNames? Is there a better way to achieve these semantics? Anne -- Anne H. Anderson Email: aha@acm.org Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692


***************************************************=20

David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel
+44 161 295 5351  Fax +44 161 745 8169 Mobile +44 790 167 0359 Email
D.W.Chadwick@salford.ac.uk Home Page 
http://www.salford.=
ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/=
its024/X500.htm X.500/LDAP Seminars http://www.salford.ac=
.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J=20

***************************************************=20

</blockquote></x-html>
Received: from c014.sfo.cp.net (c014-h017.c014.sfo.cp.net [209.228.12.81]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA28297 for ; Tue, 22 Aug 2000 08:23:02 -0700 (PDT) Received: (cpmta 23253 invoked from network); 22 Aug 2000 08:22:53 -0700 Received: from 3ff8359b.dsl.flashcom.net (HELO concord) (63.248.53.155) by smtp.flashcom.net with SMTP; 22 Aug 2000 08:22:53 -0700 X-Sent: 22 Aug 2000 15:22:53 GMT Reply-To: From: Sender: "Jeff Spinney" To: , Cc: , , Subject: RE: President Clinton digital signing Date: Tue, 22 Aug 2000 11:19:12 -0400 Message-ID: <008501c00c4c$53f42190$6501010a@jeffshouse.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal this is very interexting, can somebody please comment on why the US govt (GSA, at least) doesnt seem to want to embrace OCSP as a validation mechanism for ACES (and other programs)?? the 'CAM' as they call it sems to be an alternative mechanism....a duplication of much of the work OCSP has already worked through... -j -----Original Message----- From: marion.royal@gsa.gov [mailto:marion.royal@gsa.gov] Sent: Tuesday, August 22, 2000 8:52 AM To: ietf-pkix@imc.org Cc: terri.hobson@gsa.gov; judith.spencer@gsa.gov Subject: RE: President Clinton digital signing Terri suggests that the real significance of the certificate and smart card used by President Clinton is that they were obtained through the Access Certificates for Electronic Services (ACES) contract at GSA. Through the use of a Certificate Arbitrator Module (CAM), which is effectively a parser and validation tool (offered to public domain by GSA), multiple CA's are made available to the government applications. More info at http://www.gsa.gov/aces/ To me, though, the most significant thing is that the E-Sign bill was signed, regardless of the technology utilized. Cheers, Received: from mtk-mail1.mitretek.org (mtk-mail1.mitretek.org [206.241.50.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27997 for ; Tue, 22 Aug 2000 08:16:16 -0700 (PDT) Received: from mail1.mitretek.org (mail1.mitretek.org [206.241.49.31]) by mtk-mail1.mitretek.org (8.9.3/8.9.3) with ESMTP id LAA29728; Tue, 22 Aug 2000 11:15:56 -0400 (EDT) Received: from mitretek.org ([206.241.162.220]) by mail1.mitretek.org (Lotus Domino Release 5.0.4) with ESMTP id 2000082211155650:39892 ; Tue, 22 Aug 2000 11:15:56 -0400 Message-ID: <39A298EA.FF97772@mitretek.org> Date: Tue, 22 Aug 2000 11:14:50 -0400 From: Scott Barman X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Geer CC: ietf-pkix@imc.org Subject: Re: President Clinton digital signing References: <200008200316.XAA17065@world.std.com> X-MIMETrack: Itemize by SMTP Server on Mail1/Mitretek Systems(Release 5.0.4 |June 8, 2000) at 08/22/2000 11:15:57 AM, Serialize by Router on Mail1/Mitretek Systems(Release 5.0.4 |June 8, 2000) at 08/22/2000 11:15:57 AM, Serialize complete at 08/22/2000 11:15:57 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Dan Geer wrote: > > > After reading several articles about President Clinton and the > > digital signature signing, it appears that people have an > > inaccurate impression regarding the PKI technology utilized. > > > > The actual smart card was produced by DataKey but the certs were > > provided by Digital Signature Trust (DST) which is based on the CA > > software designed and built by Xcert International. > > I would be interested to know how this selection was made. > > --dan See http://www.gsa.gov/aces Received: from scog-ws3.gsa.gov (host.159-142-144-58.gsa.gov [159.142.144.58]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA19256 for ; Tue, 22 Aug 2000 05:52:07 -0700 (PDT) From: marion.royal@gsa.gov Received: from 159.142.144.55 by scog-ws3.gsa.gov with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Tue, 22 Aug 2000 08:52:41 -0400 X-Server-Uuid: cb2f616c-ae65-11d3-874c-00508b6362bc Subject: RE: President Clinton digital signing To: ietf-pkix@imc.org cc: terri.hobson@gsa.gov, judith.spencer@gsa.gov Date: Tue, 22 Aug 2000 08:51:53 -0400 Message-ID: X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on SCOG-NOTESSMTP1/GSAEXTERNAL(Release 5.0.1b|September 30, 1999) at 08/22/2000 08:52:41 AM MIME-Version: 1.0 X-WSS-ID: 15BCA81381806-01-01 Content-Type: multipart/mixed; boundary="0__=deIEy6O39naAtLpneVQ57XCireralUSeYXpikJYQoreaRqDaEaoO4T2Q" Content-Disposition: inline --0__=deIEy6O39naAtLpneVQ57XCireralUSeYXpikJYQoreaRqDaEaoO4T2Q Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Terri suggests that the real significance of the certificate and smart card used by President Clinton is that they were obtained through the Access Certificates for Electronic Services (ACES) contract at GSA. Through the use of a Certificate Arbitrator Module (CAM), which is effectively a parser and validation tool (offered to public domain by GSA), multiple CA's are made available to the government applications. More info at http://www.gsa.gov/aces/ To me, though, the most significant thing is that the E-Sign bill was signed, regardless of the technology utilized. Cheers, ---------------------- Forwarded by Marion A. Royal/ME/CO/GSA/GOV on 08/22/2000 08:23 AM --------------------------- (Embedded Terri F. Hobson image moved 08/22/2000 08:08 AM to file: (Embedded image moved to file: pic14454.pcx) pic17883.pcx) To: Marion A. Royal/ME/CO/GSA/GOV@GSA cc: Judith A. Spencer/TI/CO/GSA/GOV@GSA Subject: RE: President Clinton digital signing (Document link: Marion A. Royal) Marion, Looks like they missed the point! Clinton used an ACES certificate. Yes, under the ACES contract there are 3 primes and lots of subcontractors, including Verisign, Entrust, XCert, AOL, and Valicert just to name a few. However, reguardless of who, the standard x509v3 format as described in the ACES Certificate Policy was used. see ya! Marion A. Royal 08/22/2000 07:44 AM To: Terri Hobson, Judy Spencer cc: Subject: RE: President Clinton digital signing I would be happy to forward any comments you might have on this subject. This is the IETF PKIX work group. marion ---------------------- Forwarded by Marion A. Royal/ME/CO/GSA/GOV on 08/22/2000 07:42 AM --------------------------- "Yuriy Dzambasow" on 08/21/2000 01:06:34 PM Please respond to yuriy.dzambasow@digsigtrust.com To: "Alan Gibson" , "Timothy Fisher" , "Tom Strickland" cc: ietf-pkix@imc.org Subject: RE: President Clinton digital signing DST uses a variety of CA technologies in our managed services offerings, and are not solely reliant on any one technology. Yuriy -----Original Message----- From: Alan Gibson [mailto:agibson@adelphia.net] Sent: Monday, August 21, 2000 9:06 AM To: Timothy Fisher; Tom Strickland Cc: ietf-pkix@imc.org Subject: Re: President Clinton digital signing Yes ----- Original Message ----- From: "Timothy Fisher" To: "Tom Strickland" Cc: Sent: Sunday, August 20, 2000 12:41 PM Subject: Re: President Clinton digital signing > Does't DST also use Entrust software? > > Timothy Fisher > > Tom Strickland wrote: > > > Hello All, > > > > After reading several articles about President Clinton and the digital > > signature signing, it appears that people have an inaccurate impression > > regarding the PKI technology utilized. > > > > The actual smart card was produced by DataKey but the certs were > > provided by Digital Signature Trust (DST) which is based on the CA > > software designed and built by Xcert International. --0__=deIEy6O39naAtLpneVQ57XCireralUSeYXpikJYQoreaRqDaEaoO4T2Q Content-Type: application/octet-stream; name=pic17883.pcx Content-Disposition: attachment; filename=pic17883.pcx Content-Transfer-Encoding: base64 Content-Description: Paintbrush CgUBCAAAAAArABoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABLAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADID9MAyQAAxA/CDw/JD9IAyQDFD8IPD8oP0gDHAMUPww8Pyw/RAMYAxg/D Dw/MD9EAxADGD8MPwg/NDdAAwwDHDcMNwg3OD9AAAMcPxA/CD88PzwDID8QPwg/DD80NzQDIDcQN wg8P0Q/LAMkPxA/CDw/SD8kAyQ/FD8IPD8YPzQ3HAMoNwg3ED8IP1A/FAMoPxQ/DDw/VD8MAyw/F D8MPD8kPzQ0Ayw0NxQ/DDw/XD8sPxg/DDw/XD8sPxg/DDw/MD9ENww3HD8MPwg/XD8sPxg/DDw/X D8sPxg/DDw/PD84NyA/ED8IPD9cPyw/GD8MPD9cPyw/GD8MPD9IPyA3KD8UPwg8P1w/LD8YPww8P 1w/LD8YPww8P1Q/CDcsPxg/DDw8MAAAAgAAAAIAAgIAAAACAgACAAICAgICAwMDA/wAAAP8A//8A AAD//wD/AP//////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --0__=deIEy6O39naAtLpneVQ57XCireralUSeYXpikJYQoreaRqDaEaoO4T2Q Content-Type: application/octet-stream; name=pic14454.pcx Content-Disposition: attachment; filename=pic14454.pcx Content-Transfer-Encoding: base64 Content-Description: Paintbrush CgUBCAAAAABSAQkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABUwEBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD/D/8P/w//D+wP1g/LD8YPww8Pwg/DBcgPwwXID8MFyA/DBcgPwwXID8MF yA/DBcgPwwXID8MFyA/DBcgPwwXID8MFyA/DBcgPwwXID8MFyA/DBcgPwwXID8MFyA/DBcgPwwXI D8MFyA/DBcgPwwXID8MFyA/DBcgPwwXID8MFyA/DBcgPwwXID8MFyA/DBcMPDw/FBcYPxQXGD8UF xg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXG D8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcIP Dw/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXG D8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYP xQXGD8UFxg/FBcIPDw/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXG D8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYPxQXGD8UFxg/FBcYP xQXGD8UFxg/FBcYPxQXGD8UFxg/FBcIPD8IPwwXID8MFyA/DBcgPwwXID8MFyA/DBcgPwwXID8MF yA/DBcgPwwXID8MFyA/DBcgPwwXID8MFyA/DBcgPwwXID8MFyA/DBcgPwwXID8MFyA/DBcgPwwXI D8MFyA/DBcgPwwXID8MFyA/DBcgPwwXID8MFyA/DBcgPwwXDDw//D/8P/w//D+wP1g/LD8YPww8P /w//D/8P/w/sD9YPyw/GD8MPD/8P/w//D/8P7A/WD8sPxg/DDw//D/8P/w//D+wP1g/LD8YPww8P DAAAAIAAAACAAICAAAAAgIAAgACAgMDAwICAgP8AAAD/AP//AAAA//8A/wD//////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --0__=deIEy6O39naAtLpneVQ57XCireralUSeYXpikJYQoreaRqDaEaoO4T2Q-- Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA26830 for ; Tue, 22 Aug 2000 00:32:17 -0700 (PDT) Received: from kant [129.27.152.76] by iaik.tu-graz.ac.at (SMTPD32-6.00) id AC6C170F00D8; Tue, 22 Aug 2000 09:31:56 +0200 Message-ID: <005b01c00c0b$0cd36cd0$4c981b81@iaik.tugraz.ac.at> From: "Christian Vogel" To: Subject: Correction time stamping server example Date: Tue, 22 Aug 2000 09:31:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA26832 Sorry, but I made a typing error. I wrote: >common format: >[4 bytes length (network byte order)][1 byte flag][length bytes DER encoded TimeStampReq] Correct is: [4 bytes length (network byte order)][1 byte flag][(length-1) bytes DER encoded TimeStampReq] ^^^^^^ Regards Christian -- Christian Vogel office: [cvogel@iaik.at] [http://jcewww.iaik.tu-graz.ac.at] private: [bird@sbox.tu-graz.ac.at] [http://www.sbox.tu-graz.ac.at/home/b/bird] Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21013 for ; Mon, 21 Aug 2000 11:55:18 -0700 (PDT) Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA10671 for ; Mon, 21 Aug 2000 11:55:34 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id LAA10786 for ; Mon, 21 Aug 2000 11:55:33 -0700 (PDT) Received: from xch-pssbh-03.ca.boeing.com by blv-hub-01.boeing.com with ESMTP for ietf-pkix@imc.org; Mon, 21 Aug 2000 11:55:20 -0700 Received: by xch-pssbh-03.ca.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 21 Aug 2000 11:55:19 -0700 Message-Id: <5C92DF4CFB16D4119F5E00508B95A11EA5D06E@xch-nw-01b.ca.boeing.com> From: "Knoll, Jacqueline D" To: ietf-pkix@imc.org Subject: unsubscribe Date: Mon, 21 Aug 2000 11:55:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00BA1.5948D740" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C00BA1.5948D740 Content-Type: text/plain; charset="iso-8859-1" unsubscribe ------_=_NextPart_001_01C00BA1.5948D740 Content-Type: text/html; charset="iso-8859-1" unsubscribe
unsubscribe
------_=_NextPart_001_01C00BA1.5948D740-- Received: from smtpproxy1.mitre.org ([129.83.20.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20328 for ; Mon, 21 Aug 2000 11:24:28 -0700 (PDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id OAA20227; Mon, 21 Aug 2000 14:24:08 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id OAA08332; Mon, 21 Aug 2000 14:21:40 -0400 (EDT) Received: from schaen-pc.mitre.org (128.29.162.49) by mailhub2.mitre.org with SMTP id 4251801; Mon, 21 Aug 2000 14:24:06 EST Message-ID: <39A173CA.C9EF2071@mitre.org> Date: Mon, 21 Aug 2000 14:24:10 -0400 From: Sam Schaen X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ambarish Malpani CC: "'ietf-pkix@imc.org'" Subject: Re: RFC 2560 - OCSP - Clarification References: <27FF4FAEA8CDD211B97E00902745CBE201B830EF@seine.valicert.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I would like to suggest the words included in all-caps below to highlight the fact that the responder is in a position to know the revocation status of the certificate. 'The "good" state indicates that THE RESPONDER HAS CURRENT REVOCATION INFORMATION FROM THE CA THAT ISSUED THE CERTIFICATE AND the certificate has not been revoked. It does not indicate whether the certificate was ever issued, is still valid or any other assertion. Ambarish Malpani wrote: > Hi Folks, > Simon (Tardell) and I were talking about the need for > clarification in section 2.2 of RFC 2560. We came up with > the following proposal and are looking for comments on the > changes > > -----------------Begin Proposed Changes-------------------- > > Replace the three paragraphs (in section 2.2) that start: > 'The "good" state...the certificate being requested.' > with: > > 'The "good" state indicates that the certificate has not been revoked. It > does not indicate whether the certificate was ever issued, is still valid or > any other assertion. > > The "revoked" state indicates that the certificate has been revoked(either > permanantly or temporarily (on hold)). > > The "unknown" state indicates that the responder does not know, or is > unwilling to tell, whether the certificate is revoked or not. A client may > be able to get a definitive response later, or at another responder. > > Response extensions may be used to carry further status information (e.g. on > issuance). > > -----------------End Proposed Changes-------------------- > > We are looking for comments on what the group thinks about these - they > are just clarifications that I think can go in when we roll over from > Proposed Standard to Draft Standard (at which time we should also add > the OID for the ASN.1 module). > > Comments? > Regards, > Ambarish > > --------------------------------------------------------------------- > Ambarish Malpani > Architect 650.567.5457 > ValiCert, Inc. ambarish@valicert.com > 339 N. Bernardo Ave. http://www.valicert.com > Mountain View, CA 94043 Received: from serv1.is1.u-net.net (serv1.is1.u-net.net [195.102.240.129]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19396 for ; Mon, 21 Aug 2000 10:51:16 -0700 (PDT) Received: from [195.232.106.149] (helo=dwc-acer) by serv1.is1.u-net.net with esmtp (Exim 3.12 #1) id 13QvjH-00019B-00; Mon, 21 Aug 2000 18:51:25 +0100 From: "David Chadwick" Organization: University of Salford To: Anne Anderson , ietf-pkix@imc.org Date: Mon, 21 Aug 2000 18:50:19 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: excluding all names of given type Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <39A179EB.15636.5CF9829@localhost> Priority: normal In-reply-to: <14748.311.613517.443300@east.sun.com> X-mailer: Pegasus Mail for Win32 (v3.12c) From: Anne Anderson Date sent: Thu, 17 Aug 2000 11:13:59 -0400 (EDT) To: ietf-pkix@imc.org Subject: excluding all names of given type > CASE: NameConstraints excludedSubtrees contains a directoryName where > the RDNSequence is null > > SEMANTICS: Does this mean that the subsequent path may contain no > names of type directoryName in either Subject or the > SubjectAlternativeNames? Anne I would agree with your interpretation above, David > > Is there a better way to achieve these semantics? > > Anne > -- > Anne H. Anderson Email: aha@acm.org > Sun Microsystems Laboratories > 1 Network Drive,UBUR02-311 Tel: 781/442-0928 > Burlington, MA 01803-0902 USA Fax: 781/442-1692 > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** Received: from serv1.is1.u-net.net (serv1.is1.u-net.net [195.102.240.129]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19368 for ; Mon, 21 Aug 2000 10:51:14 -0700 (PDT) Received: from [195.232.106.149] (helo=dwc-acer) by serv1.is1.u-net.net with esmtp (Exim 3.12 #1) id 13Qvj1-00019B-00; Mon, 21 Aug 2000 18:51:10 +0100 From: "David Chadwick" Organization: University of Salford To: Ambarish Malpani , "'TAKIGUCHI Naruhito'" , ietf-pkix@imc.org Date: Mon, 21 Aug 2000 18:50:21 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: CRL number in CRL and ARL Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <39A179ED.9934.5CFA05B@localhost> Priority: normal In-reply-to: <27FF4FAEA8CDD211B97E00902745CBE2B41816@seine.valicert.com> X-mailer: Pegasus Mail for Win32 (v3.12c) From: Ambarish Malpani To: "'TAKIGUCHI Naruhito'" , ietf-pkix@imc.org Subject: RE: CRL number in CRL and ARL Date sent: Wed, 9 Aug 2000 22:33:13 -0700 > > If you are using CRLDPs, the numbering for each DP is independent. > > It is okay to number them in the following way: > > Time DP1 DP2 > 1 10 5 > 2 12 17 > 3 15 18 > 4 99 201 > 5 202 202 Ambarish, How does your unique and apparently random numbering scheme allow the CRL user to quote "detect whether CRLs issued prior to the one being processed were also seen and processed." I dont believe it can, and therefore does not fulfil the requirements of X.509. I believe the intention was always to have sequence numbers. Note that RFC2459 has changed the semantics of X.509 by using the phrase quote "allows users to easily determine when a particular CRL supersedes another CRL. " Clearly your randon scheme fulfils the requirement of 2459, but not of X.509. Was this semantic change intentional by the authors of 2459? Warwick, Tim, Dave, Russ? As I see it, for aperiodic issuing of CRLs, the CRL number can be used to detect a missing CRL. For strict periodic issuing the time can be used instead of the CRL number. David > > Or any other interesting scheme you would prefer, as long as > the numbers for DP1 are monotonically increasing and the > numbers for DP2 are monotoncally increasing. > > Note: This example is *not* meant to imply that you even need to > issue both DPs at all the times specified. > > Regards, > Ambarish > > --------------------------------------------------------------------- > Ambarish Malpani Architect > 650.567.5457 ValiCert, Inc. > ambarish@valicert.com 339 N. Bernardo Ave. > http://www.valicert.com Mountain View, CA 94043 > > > > -----Original Message----- > > From: TAKIGUCHI Naruhito [mailto:takiguti@fjh.se.fujitsu.co.jp] > > Sent: Wednesday, August 09, 2000 7:59 PM To: ietf-pkix@imc.org > > Subject: Re: CRL number in CRL and ARL > > > > > > Ambarish, > > > > > If you are creating CRLs and ARLs that are not complete (i.e. > > > don't contain all the entries the other does), it is very > > > important that you use the CRLDP method of doing it. Put in > > > CRLDP extensions in the certificates and IDP (Issuing Distribution > > > Point) extensions in your CRLs/ARLs. > > > > > > If you don't use the CRLDP mechanism, you run the risk of having a > > > bunch of applications misbehave with your CRLs. > > > > Thank you. I agree with your advice. > > But, I'm going to discussion about the CRL number. > > > > I think that the method (a)(the CRL number is a sequece > > number for each > > CRL scope) is better than the method (b) for a relying party. > > RFC2459 and son of RFC2459 describe following : > > > > The CRL number is a non-critical CRL extension which > > conveys a mono- > > tonically increasing sequence number for each CRL issued by a CA. > > > > Does "for each CRL issued by a CA" sentence mean the method (b) ? > > > > Thanks in advance. > > > > > Regards, > > > Ambarish > > > > > > > > -------------------------------------------------------------------- > > - > > > Ambarish Malpani > > > Architect > > 650.567.5457 > > > ValiCert, Inc. > > ambarish@valicert.com > > > 339 N. Bernardo Ave. > > http://www.valicert.com > > > Mountain View, CA 94043 > > > > > > > > > > -----Original Message----- > > > > From: TAKIGUCHI Naruhito [mailto:takiguti@fjh.se.fujitsu.co.jp] > > > > Sent: Tuesday, August 08, 2000 8:13 PM To: ietf-pkix@imc.org > > > > Subject: CRL number in CRL and ARL > > > > > > > > > > > > Hi, all. > > > > > > > > I have a question about the cRLNumber extension. > > > > > > > > For example, a CA issues CRL(end-entity certificate > > revocation list) > > > > and ARL(CA certificate revocation list). > > > > Which is correct (a) or (b) ? > > > > > > > > (a) In first CRL and ARL, the CRL number is 0. > > > > In next CRL and ARL, the CRL number is 1. > > > > > > > > In other words, CRL and ARL have same value of > > the CRL number. > > > > The CRL number is a monotonically increasing > > sequence number > > > > for each CRL scope. > > > > > > > > (b) In first CRL, the CRL Number is 0. > > > > In first ARL, the CRL Number is 1. > > > > In next CRL, the CRL number is 2. > > > > In next ARL, the CRL number is 3. > > > > > > > > In other words, the CRL number is monotonically > > > > increasing sequence number for each CA. > > > > > > > > Could anyone advice me? > > > > > > > > Thanks in advance. > > > > > > > > ----- > > > > Naruhito TAKIGUCHI > > > > FUJITSU HOKURIKU SYSTEMS LTD. > > > > > > > > ----- > > Naruhito TAKIGUCHI > > FUJITSU HOKURIKU SYSTEMS LTD. > > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** Received: from serv1.is1.u-net.net (serv1.is1.u-net.net [195.102.240.129]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19299 for ; Mon, 21 Aug 2000 10:50:49 -0700 (PDT) Received: from [195.232.106.149] (helo=dwc-acer) by serv1.is1.u-net.net with esmtp (Exim 3.12 #1) id 13Qvif-00019B-00; Mon, 21 Aug 2000 18:50:49 +0100 From: "David Chadwick" Organization: University of Salford To: Anne Anderson , ietf-pkix@imc.org, Tim Polk Date: Mon, 21 Aug 2000 18:50:20 +0100 MIME-Version: 1.0 Content-type: text/enriched; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: excluding all names of given type Reply-to: d.w.chadwick@salford.ac.uk CC: Sharon Boeyen Message-ID: <39A179EC.24015.5CF9C00@localhost> Priority: normal In-reply-to: <4.2.0.58.20000817130750.00c43200@email.nist.gov> References: <14748.311.613517.443300@east.sun.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Date sent: Thu, 17 Aug 2000 13:55:59 -0400 To: Anne Anderson <, ietf-pkix@imc.org From: Tim Polk < Subject: Re: excluding all names of given type Copies to: Sharon Boeyen < Times New RomanAnne,  I think I would state this in reverse.  leftCASE: NameConstraints *includedSubtrees* contains a directoryName where the RDNSequence is NULL  has the leftSEMANTICS: The Subject field and the directoryName field of the SubjectAlternativeName (if it appears at all) may only contain names in the subtree NULL for all successive certificates in the path. The only name in the subtree NULL would be the exact match - the NULL value. That would work, since we require a NULL RDNSequence if the Subject is omitted. As Steve has pointed out, this should only occur in an end entity certificate. leftTim I do not agree with your semantics. The null name is the name of the root of the DIT, and therefore implies ALL subordinate names. Since a DIT subtree can comprise a single entry or any number of entries up to the whole DIT, then a null name implies a subtree of the whole DIT. Thus include NULL implies include any directory name at all - not a particularly usefull extension to include in a certificate. David This is not particularly straightforward, I know. We are using the include feature to exclude names! However, it works *if* you consider the only name in the subtree NULL is NULL itself.  On the other hand, you could consider NULL the implicit root of all subtrees, the correct answer is excludedSubtrees is NULL with a minimum value of 1. (We would need to set the minimum to 1 so that NULL itself was not excluded.)  This would force us to use (and process) the minimum value. RFC 2459 states that the minimum and maximum never are used, so minimum is always zero.  I prefer the *includedSubtrees* solution. The truth is, of course, as long as we pick one way and state it clearly we should be fine. I don't think the X.5xx specifications cover this issue, but I've been wrong before on that point!  Sharon, do you know if this topic has been addressed anywhere before?? Our first consideration should be conformance to X.509 etc if a clear solution has been established. If this has not been addressed, we should sort it out ASAP.  Thanks,  Tim  At 11:13 AM 8/17/00 -0400, Anne Anderson wrote: leftCASE: NameConstraints excludedSubtrees contains a directoryName where the RDNSequence is null  SEMANTICS: Does this mean that the subsequent path may contain no names of type directoryName in either Subject or the SubjectAlternativeNames?  Is there a better way to achieve these semantics?  Anne --  Anne H. Anderson Email: aha@acm.org Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692 *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** Received: from monet.digsigtrust.com (mail.digsigtrust.com [208.30.69.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18444 for ; Mon, 21 Aug 2000 10:11:14 -0700 (PDT) Received: from CC474623A (cc474623-a.abdn1.md.home.com [24.18.83.123]) by monet.digsigtrust.com (8.10.2/8.10.2) with SMTP id e7LHBDK13519; Mon, 21 Aug 2000 11:11:13 -0600 (MDT) Reply-To: From: "Yuriy Dzambasow" To: "Alan Gibson" , "Timothy Fisher" , "Tom Strickland" Cc: Subject: RE: President Clinton digital signing Date: Mon, 21 Aug 2000 13:06:34 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <018a01c00b70$82719b60$576211ac@cdp.adelphia.net> DST uses a variety of CA technologies in our managed services offerings, and are not solely reliant on any one technology. Yuriy -----Original Message----- From: Alan Gibson [mailto:agibson@adelphia.net] Sent: Monday, August 21, 2000 9:06 AM To: Timothy Fisher; Tom Strickland Cc: ietf-pkix@imc.org Subject: Re: President Clinton digital signing Yes ----- Original Message ----- From: "Timothy Fisher" To: "Tom Strickland" Cc: Sent: Sunday, August 20, 2000 12:41 PM Subject: Re: President Clinton digital signing > Does't DST also use Entrust software? > > Timothy Fisher > > Tom Strickland wrote: > > > Hello All, > > > > After reading several articles about President Clinton and the digital > > signature signing, it appears that people have an inaccurate impression > > regarding the PKI technology utilized. > > > > The actual smart card was produced by DataKey but the certs were > > provided by Digital Signature Trust (DST) which is based on the CA > > software designed and built by Xcert International. Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13962; Mon, 21 Aug 2000 08:28:55 -0700 (PDT) Received: from alpha.hut.fi (haifengl@alpha.hut.fi [130.233.224.50]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id SAA04921; Mon, 21 Aug 2000 18:29:10 +0300 (EET DST) Date: Mon, 21 Aug 2000 18:29:10 +0300 (EET DST) From: Haifeng Lin ~!~ To: ietf-pkix-request@imc.org cc: ietf-pkix@imc.org Subject: about CA,X509,RA for security, certification validation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe Hello, I am Haifeng in Finland.I read your topic in internet. It is http://www.ietf.org/html.charters/pkix-charter.html It is very good. But it is knowledge and theory.How can I use it? I have some question about PKI, CA,CV security... I knew little bit PKI,CA, x509, RA... But I want to have a nice beginning to do. So, Would you mind give me some example and C or C++ or Java code for how to do "certificate validation"? I read one PKI book,(integrity, lifetime,signture...) It is " The integrity of the certificate is sound; that is, the digital signature on the certificate corresponds to the independently-calculated hash value of the certificate itself and the signer's public key". Another one: "the certificate is within its established validity period(as indicated by the Not Valid Before and Not valid after parameters in the certificate). how can I do "Integrity" and "validity period" for "CA"? And how did you think about "Revocation"? which is X509 structure, just for signture, lifetime,integrity,revocation? I would like to do "certification validation" by myself. 1. Presume one certification of structure that had in computer. struct x509{ int int int... } 2. I will use Vj++ or Vc++to do "validation". It includes: digitally signed, integrity,validity period, revocation. 3.Or If "Presume" I got CA from some software, how can I make "certificate Validation" in C or C++, or Java? Could you please tell me some idea and source code??Just simple... Thank you very much and have a nice week. B.R Haifeng:) Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11770 for ; Mon, 21 Aug 2000 08:18:28 -0700 (PDT) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0FZN00K01EJ3Z3@ext-mail.valicert.com> for ietf-pkix@imc.org; Mon, 21 Aug 2000 08:18:39 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0FZN00KDLEJ3IG@ext-mail.valicert.com> for ietf-pkix@imc.org; Mon, 21 Aug 2000 08:18:39 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Mon, 21 Aug 2000 08:08:39 -0700 Content-return: allowed Date: Mon, 21 Aug 2000 08:08:37 -0700 From: Ambarish Malpani Subject: RFC 2560 - OCSP - Clarification To: "'ietf-pkix@imc.org'" Message-id: <27FF4FAEA8CDD211B97E00902745CBE201B830EF@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Hi Folks, Simon (Tardell) and I were talking about the need for clarification in section 2.2 of RFC 2560. We came up with the following proposal and are looking for comments on the changes -----------------Begin Proposed Changes-------------------- Replace the three paragraphs (in section 2.2) that start: 'The "good" state...the certificate being requested.' with: 'The "good" state indicates that the certificate has not been revoked. It does not indicate whether the certificate was ever issued, is still valid or any other assertion. The "revoked" state indicates that the certificate has been revoked(either permanantly or temporarily (on hold)). The "unknown" state indicates that the responder does not know, or is unwilling to tell, whether the certificate is revoked or not. A client may be able to get a definitive response later, or at another responder. Response extensions may be used to carry further status information (e.g. on issuance). -----------------End Proposed Changes-------------------- We are looking for comments on what the group thinks about these - they are just clarifications that I think can go in when we roll over from Proposed Standard to Draft Standard (at which time we should also add the OID for the ASN.1 module). Comments? Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10230 for ; Mon, 21 Aug 2000 08:02:32 -0700 (PDT) Received: (from godslord@localhost) by venus.initech.com (8.9.3/8.9.3) id XAA11039 for ietf-pkix@imc.org; Mon, 21 Aug 2000 23:59:49 +0900 (KST) Date: Mon, 21 Aug 2000 23:59:49 +0900 From: "Kwon, YongChul" To: ietf-pkix@imc.org Subject: ASN.1 Encoding of no valued extension Message-ID: <20000821235949.B10970@venus.initech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Organization: Initech, Inc I wonder about how no valued extension will be encoded in DER form. for example, NameConstraints ::= SEQUENCE { permittedSubtrees [0] GeneralSubtrees OPTIONAL, excludedSubtrees [1] GeneralSubtrees OPTIONAL } permittedSubtrees and excludedSubtrees are both omittable. and then it's an empty sequence when both are omitted. I'd omit this extension rather than encode as empty sequence. What's the PKIX's recomendation about this situation? both(omit or empty sequence)? or omit such extension? or encode as empty sequence? or depends on situation? :-( (I guess that just omitting Extension like that basic constraints should not appear in EE's certificates is the best way). Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09111 for ; Mon, 21 Aug 2000 07:16:44 -0700 (PDT) Received: from kant [129.27.152.76] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A9DAB500BA; Mon, 21 Aug 2000 16:16:58 +0200 Message-ID: <021801c00b7a$780282c0$4c981b81@iaik.tugraz.ac.at> From: "Christian Vogel" To: Subject: time stamping server example Date: Mon, 21 Aug 2000 16:16:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA09112 I checked the log files of the time stamping server. There were a lot of problems with the correct format. Therefore I will post an example: The time stamping server is a socket based server as described in . Its IP adress is: 129.27.142.227:318 common format: [4 bytes length (network byte order)][1 byte flag][length bytes DER encoded TimeStampReq] TimeStampReq: Version: 1 MessageImprint: HashAlgorithm: SHA HashedMessage: 45:81:E2:50:F2:F0:9E:0D:EC:00:14:C7:20:A7:87:6B:BE:05:06:6B Nonce: 15757292069520509269 CertReq: true DER encoded TimeStampReq: 30:34:02:01:01:30:21:30:09:06:05:2B:0E:03:02:1A:05:00:04:14:45:81:E2:50:F2:F0:9E: 0D:EC:00:14:C7:20:A7:87:6B:BE:05:06:6B:02:09:00:DA:AD:25:A6:C9:D9:89:55:01:01:FF direct TCP-based TSA message: 00:00:00:37:00:30:34:02:01:01:30:21:30:09:06:05:2B:0E:03:02:1A:05:00:04:14:45:81:E2:50:F2:F0:9E: 0D:EC:00:14:C7:20:A7:87:6B:BE:05:06:6B:02:09:00:DA:AD:25:A6:C9:D9:89:55:01:01:FF Regards Christian -- Christian Vogel office: [cvogel@iaik.at] [http://jcewww.iaik.tu-graz.ac.at] private: [bird@sbox.tu-graz.ac.at] [http://www.sbox.tu-graz.ac.at/home/b/bird Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08669 for ; Mon, 21 Aug 2000 07:02:06 -0700 (PDT) From: John_Wray@iris.com Subject: Re: excluding all names of given type To: Tim Polk Cc: Anne Anderson , ietf-pkix@imc.org, Sharon Boeyen X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Mon, 21 Aug 2000 10:02:32 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/21/2000 10:02:24 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA08671 Tim Polk wrote: >On the other hand, you could consider NULL the implicit root of all subtrees, >the correct answer is excludedSubtrees is NULL with a minimum value of 1. >(We would need to set the minimum to 1 so that NULL itself was not excluded.) I don't think that's right. An empty subject DN in a certificate doesn't mean that the certificate applies to a principal whose DN is the root of the DIT, rather that the principal in question has no DN. This is a special case, called out explicitly in the PKIX profile. A certificate with an empty DN should be permitted regardless of any DN name constraints. So I don't think this requires that you set the minimum value to 1 - 0 should do just fine. >CASE: NameConstraints *includedSubtrees* contains a directoryName >where the RDNSequence is NULL > >has the > >SEMANTICS:  The Subject field and the directoryName field of the >SubjectAlternativeName (if it appears at all) may only contain names >in the subtree NULL for all successive certificates in the path. > >The only name in the subtree NULL would be the exact match - the >NULL value.  That would work, since we require a NULL RDNSequence >if the Subject is omitted.  As Steve has pointed out, this should only >occur in an end entity certificate. > >This is not particularly straightforward, I know.  We are using the include >feature to exclude names!  However, it works *if* you consider the only >name in the subtree NULL is NULL itself. Normally when a name is given as the root of a subtree, it means that members of that subtree are formed by appending RDNs to the root name (subject to any minimum and maximum path lengths in the subtree constraint, which don't apply to the PKIX profile). Thus the subtree rooted at the empty DN includes all names in the DIT. So by putting this name in the permittedSubtrees field you are saying all names are permitted, which doesn't say anything useful, as it's the default state. To use either of these mechanisms, some special-casing has to be done by relying parties, so we need to decide which mechanism we should recommend and put language into the profile to explicitly support it. I definitely favor the use of excludedSubtrees to exclude the entire X.500 DIT, both because it just seems illogical to use a permitted Subtrees extension to exclude things, but also because the reason that special-casing is necessary at all is that we have decided that an empty DN in the subject field of a certificate has special semantics, so we should strive to restrict any special casing necesssary to our interpretation of that field, rather than having to change the semantics of other fields to suit. John Received: from alpha.cdp.adelphia.net (alpha.cdp.adelphia.net [24.48.64.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07570 for ; Mon, 21 Aug 2000 06:09:59 -0700 (PDT) Received: from agibson (dynamic87.cdp.adelphia.net [24.48.60.87] (may be forged)) by alpha.cdp.adelphia.net (8.9.2/8.9.2) with SMTP id JAA02114; Mon, 21 Aug 2000 09:19:29 -0400 (EDT) Message-ID: <018a01c00b70$82719b60$576211ac@cdp.adelphia.net> From: "Alan Gibson" To: "Timothy Fisher" , "Tom Strickland" Cc: References: <399F4859.A91DD008@xcert.com> <39A00A2F.87DB18A5@cyclonecommerce.com> Subject: Re: President Clinton digital signing Date: Mon, 21 Aug 2000 09:05:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Yes ----- Original Message ----- From: "Timothy Fisher" To: "Tom Strickland" Cc: Sent: Sunday, August 20, 2000 12:41 PM Subject: Re: President Clinton digital signing > Does't DST also use Entrust software? > > Timothy Fisher > > Tom Strickland wrote: > > > Hello All, > > > > After reading several articles about President Clinton and the digital > > signature signing, it appears that people have an inaccurate impression > > regarding the PKI technology utilized. > > > > The actual smart card was produced by DataKey but the certs were > > provided by Digital Signature Trust (DST) which is based on the CA > > software designed and built by Xcert International. Received: from dns1.provide.net (root@dns1.provide.net [216.86.64.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28290 for ; Sun, 20 Aug 2000 09:41:32 -0700 (PDT) Received: from cyclonecommerce.com (usr07-104.provide.net [216.86.68.104]) by dns1.provide.net (8.9.0/8.9.3) with ESMTP id MAA07576; Sun, 20 Aug 2000 12:41:10 -0400 (EDT) Message-ID: <39A00A2F.87DB18A5@cyclonecommerce.com> Date: Sun, 20 Aug 2000 12:41:19 -0400 From: Timothy Fisher X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Strickland CC: ietf-pkix@imc.org Subject: Re: President Clinton digital signing References: <399F4859.A91DD008@xcert.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Does't DST also use Entrust software? Timothy Fisher Tom Strickland wrote: > Hello All, > > After reading several articles about President Clinton and the digital > signature signing, it appears that people have an inaccurate impression > regarding the PKI technology utilized. > > The actual smart card was produced by DataKey but the certs were > provided by Digital Signature Trust (DST) which is based on the CA > software designed and built by Xcert International. Received: from world.std.com (geer@world-f.std.com [199.172.62.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA11073 for ; Sat, 19 Aug 2000 20:16:14 -0700 (PDT) Received: from localhost (geer@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id XAA17065 for ; Sat, 19 Aug 2000 23:16:22 -0400 (EDT) Message-Id: <200008200316.XAA17065@world.std.com> X-Authentication-Warning: world.std.com: geer@localhost didn't use HELO protocol To: ietf-pkix@imc.org Subject: Re: President Clinton digital signing In-reply-to: Your message of "Sat, 19 Aug 2000 19:54:17 EDT." <399F4859.A91DD008@xcert.com> Date: Sat, 19 Aug 2000 23:16:21 -0400 From: Dan Geer > After reading several articles about President Clinton and the > digital signature signing, it appears that people have an > inaccurate impression regarding the PKI technology utilized. > > The actual smart card was produced by DataKey but the certs were > provided by Digital Signature Trust (DST) which is based on the CA > software designed and built by Xcert International. I would be interested to know how this selection was made. --dan Received: from crack.x509.com (root@crack.x509.com [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26401 for ; Sat, 19 Aug 2000 16:41:33 -0700 (PDT) Received: from xcert.com (home.x509.com [199.175.150.4]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e7JNfeS03117 for ; Sat, 19 Aug 2000 16:41:40 -0700 (PDT) Message-ID: <399F4859.A91DD008@xcert.com> Disposition-Notification-To: Tom Strickland Date: Sat, 19 Aug 2000 19:54:17 -0700 From: Tom Strickland X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: President Clinton digital signing Content-Type: multipart/mixed; boundary="------------FC009E784720B3674DD36487" This is a multi-part message in MIME format. --------------FC009E784720B3674DD36487 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello All, After reading several articles about President Clinton and the digital signature signing, it appears that people have an inaccurate impression regarding the PKI technology utilized. The actual smart card was produced by DataKey but the certs were provided by Digital Signature Trust (DST) which is based on the CA software designed and built by Xcert International. --------------FC009E784720B3674DD36487 Content-Type: text/x-vcard; charset=us-ascii; name="tstrickland.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tom Strickland Content-Disposition: attachment; filename="tstrickland.vcf" begin:vcard n:Strickland;Tom tel;cell:678 296-4866 x-mozilla-html:TRUE org:
Xcert International Inc. adr:;;;;;; version:2.1 email;internet:tstrickland@xcert.com title:Senior Sales Engineer fn:Tom Strickland end:vcard --------------FC009E784720B3674DD36487-- Received: from camero.webfilter.org ([63.106.56.213]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07705; Fri, 18 Aug 2000 07:43:12 -0700 (PDT) Received: from drew ([10.1.1.25]) by camero.webfilter.org (Post.Office MTA v3.5.3 release 223 ID# 0-61168U1000L100S0V35) with SMTP id org; Fri, 18 Aug 2000 10:50:11 -0400 Message-ID: <014901c00922$8c351140$1901010a@webfilter> From: education@iwebmedia.net (Ed. Dept.) To: Subject: Free Advertising Date: Fri, 18 Aug 2000 10:42:34 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0146_01C00901.04E04DC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_0146_01C00901.04E04DC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -------------------------------------------------------------------------= ------- Try our free training demo and receive an advertising banner for your = company for 1 month FREE on the popular search engine Go Look For It! (no purchase necessary) -------------------------------------------------------------------------= ------- =20 Want to enhance your computer skills and career?=20 Employees need training but can't afford the time or investment?=20 Interested in becoming a Microsoft Certified Systems Engineer (MCSE)?=20 Want low-cost, high-quality training on Word, Excel and other PC = software?=20 Low-cost training to help you achieve your goals is at your fingertips! Our Courseware is accessible anywhere at any time through the Internet! Subjects such as Microsoft's MCSE, MCSE plus Internet, MCP and MOUS certifications (all Microsoft Approved) , A+ Certification, Java, = HTML, Cisco and more! Currently over 400 courses, with approximately 30 new courses added = quarterly!=20 Click here to TRY A FREE DEMO or see our COURSE CATALOG and FEATURES. Special price only $29.95 per month for unlimited access to all 400+ = courses! Click here to sign up online or call us at 727-536-5517. That's a $576.00 value for only $29.95 to receive of unlimited access to = over 400 courses! No long term contracts...cancel anytime! This special price is available through this e-mail offer only. Offer expires August 18, 2000 at 5:00 pm E.S.T. ONE YEAR FREE!! Register here to win full access to all 400+ courses = absolutely FREE for 1 year. No purchase necessary. Trying a free demo or signing up will = automatically register you. Education is the key to success... __________________________________________________________________ Over 400 courses available anytime, anywhere! Try our free demo at >>>> www.onlinetrainingcollege.com <<<< Your e-mail address was received from an opt-in list for educational = information. If you received this message in error or to be removed from this mailing list, reply to this message and type = the word REMOVE in your e-mail subject line.=20 ------=_NextPart_000_0146_01C00901.04E04DC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 Try our free training demo and receive an advertising banner = for your=20 company
for 1 month FREE on the = popular=20 search engine Go Look=20 For It!
(no purchase = necessary)
 
Want to enhance your computer skills and career?=20

Employees need training but = can't afford=20 the time or investment?

Interested in becoming a = Microsoft=20 Certified Systems Engineer (MCSE)?

Want low-cost, high-quality = training on=20 Word, Excel and other PC software?

Low-cost training to help you achieve = your goals is=20 at your fingertips!
Our Courseware is accessible anywhere at any time = through=20 the Internet!
Subjects such as Microsoft's MCSE, MCSE plus Internet, = MCP=20 and
MOUS certifications (all Microsoft = Approved) ,=20 A+ Certification, Java, HTML, Cisco and more!
Currently over 400 = courses, with approximately 30 new courses added = quarterly! 

Click=20 here to TRY=20 A FREE DEMO or see our COURSE=20 CATALOG and FEATURES.

Special price = only $29.95 per=20 month for unlimited access to all 400+=20 courses!
Click here to sign=20 up online or call us at=20 727-536-5517.
That's a $576.00 value for only=20 $29.95 to receive of unlimited access to over 400 courses!
No = long term=20 contracts...cancel anytime!

This special price is available = through this=20 e-mail offer only.
Offer expires August 18, 2000 at 5:00 pm = E.S.T.

ONE = YEAR FREE!! =20 Register=20 here to win full access to all 400+ courses absolutely = FREE for 1 year.
No purchase = necessary.=20 Trying a free demo or signing up will automatically register=20 you.
 
Education is the key=20 to success...
 
________________________________________________________________= __
Over=20 400 courses available anytime, anywhere!
Try our free demo at=20 >>>> www.onlinetrainingcollege.c= om=20 <<<<
 
Your e-mail address was received from = an opt-in=20 list for educational information. If you received this message in=20 error
or to be = removed from this=20 mailing list, reply to this message and type the word REMOVE in your = e-mail=20 subject line.
------=_NextPart_000_0146_01C00901.04E04DC0-- Received: from c008.sfo.cp.net (c008-h016.c008.sfo.cp.net [209.228.14.205]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA00178 for ; Thu, 17 Aug 2000 12:39:07 -0700 (PDT) Received: (cpmta 6650 invoked from network); 17 Aug 2000 12:38:34 -0700 Date: 17 Aug 2000 12:38:34 -0700 Message-ID: <20000817193834.6649.cpmta@c008.sfo.cp.net> X-Sent: 17 Aug 2000 19:38:34 GMT Received: from [207.8.203.24] by mail.cogence-inc.com with HTTP; 17 Aug 2000 12:38:34 PDT Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: ietf-pkix@imc.org From: "Rosemary A.Walsh" X-Mailer: Web Mail 3.7.0.11 Subject: unsubscribe Unsubscribe Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27909 for ; Thu, 17 Aug 2000 11:06:34 -0700 (PDT) Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id OAA23279; Thu, 17 Aug 2000 14:06:03 -0400 (EDT) Message-Id: <4.2.0.58.20000817130750.00c43200@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 17 Aug 2000 13:55:59 -0400 To: Anne Anderson , ietf-pkix@imc.org From: Tim Polk Subject: Re: excluding all names of given type Cc: Sharon Boeyen In-Reply-To: <14748.311.613517.443300@east.sun.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Anne,

I think I would state this in reverse.
CASE: NameConstraints *includedSubtrees* contains a directoryName where the RDNSequence is NULL

has the
SEMANTICS:  The Subject field and the directoryName field of the SubjectAlternativeName (if it appears at all) may only contain names in the subtree NULL for all successive certificates in the path.

The only name in the subtree NULL would be the exact match - the NULL value.  That would work, since we require a NULL RDNSequence if the Subject is omitted.  As Steve has pointed out, this should only occur in an end entity certificate.

This is not particularly straightforward, I know.  We are using the include feature to exclude names!  However, it works *if* you consider the only name in the subtree NULL is NULL itself.

On the other hand, you could consider NULL the implicit root of all subtrees, the correct answer is excludedSubtrees is NULL with a minimum value of 1.  (We would need to set the minimum to 1 so that NULL itself was not excluded.)

This would force us to use (and process) the minimum value.  RFC 2459 states that the minimum and maximum never are used, so minimum is always zero.

I prefer the *includedSubtrees* solution.  The truth is, of course, as long as we pick one way and state it clearly we should be fine.  I don't think the X.5xx specifications cover this issue, but I've been wrong before on that point!

Sharon, do you know if this topic has been addressed anywhere before??  Our first consideration should be conformance to X.509 etc if a clear solution has been established.  If this has not been addressed, we should sort it out ASAP.

Thanks,

Tim

At 11:13 AM 8/17/00 -0400, Anne Anderson wrote:
CASE: NameConstraints excludedSubtrees contains a directoryName where
the RDNSequence is null

SEMANTICS: Does this mean that the subsequent path may contain no
names of type directoryName in either Subject or the
SubjectAlternativeNames?

Is there a better way to achieve these semantics?

Anne
--
Anne H. Anderson             Email: aha@acm.org
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692
Received: from mail.yourdomain.com (m319-mp1-cvx1a.man.ntl.com [62.252.197.63]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA26173; Thu, 17 Aug 2000 09:58:55 -0700 (PDT) From: announce@leisurewebcams.com Message-Id: <200008171658.JAA26173@ns.secondary.com> Date: Thu, 17 Aug 2000 14:23:35 Subject: LeisureWebcams.com - See the World LeisureWebcams.com is a recently launched website specialising in providing free LIVE access to over 1,500 webcams and 2,000 Tourist Offices world wide. Check it out:- http://www.leisurewebcams.com/ This offers you the chance to check out live and frequently updated images of your chosen location through the webcams and get detailed local knowledge through the Tourist Offices. Along with booking holidays direct through our travel partner, there is the opportunity to sell your unwanted clothes and equipment through our free Swap Shop. There is a lot to see, so if you have enjoyed your trip through our site, do tell your friends and let us know through 'Your Views'. If you have any suggestions for the site, or queries, please feel free to contact me at cy@LeisureWebcams.com. I look forward to hearing from you. Kind regards, Charlie Yates MARKETING DIRECTOR LeisureWebcams.com Received: from smtp.africaonline.co.ke (smtp.africaonline.co.ke [216.252.240.5]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA24149 for ; Thu, 17 Aug 2000 08:41:41 -0700 (PDT) Received: (qmail 22593 invoked from network); 17 Aug 2000 15:43:45 -0000 Received: from users.africaonline.co.ke (199.103.176.4) by smtp.africaonline.co.ke with SMTP; 17 Aug 2000 15:43:45 -0000 Received: (qmail 4704 invoked from network); 17 Aug 2000 15:37:29 -0000 Received: from kcb.co.ke (HELO PROJECTHERCULES.kcb.co.ke) (192.168.201.36) by users.africaonline.co.ke with SMTP; 17 Aug 2000 15:37:29 -0000 Received: by PROJECTHERCULES with Internet Mail Service (5.5.2650.21) id ; Thu, 17 Aug 2000 17:09:24 +0300 Message-ID: <25CEF634270DD41199BA00508B6B80AD10C1AF@GEMINI_EXCH> From: "Okello, Gilbert" To: ietf-pkix@imc.org Subject: unsubscribe Date: Thu, 17 Aug 2000 17:13:06 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00854.BEB3A736" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C00854.BEB3A736 Content-Type: text/plain; charset="iso-8859-1" ------_=_NextPart_001_01C00854.BEB3A736 Content-Type: text/html; charset="iso-8859-1" unsubscribe

------_=_NextPart_001_01C00854.BEB3A736-- Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23313 for ; Thu, 17 Aug 2000 08:36:11 -0700 (PDT) Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA10798; Thu, 17 Aug 2000 11:35:43 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <14748.311.613517.443300@east.sun.com> References: <14748.311.613517.443300@east.sun.com> Date: Thu, 17 Aug 2000 11:29:53 -0400 To: Anne Anderson From: Stephen Kent Subject: Re: excluding all names of given type Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Anne, I think the example you gave is a reasonable way to express the semantics in question. (Slight clarification: since a subject name is always a DN, the example suggests to me that the subject name would have to be NULL to comply, and that a subject alt name must be of a type other than directory name.) Steve Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18467 for ; Thu, 17 Aug 2000 08:14:08 -0700 (PDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10263 for ; Thu, 17 Aug 2000 08:14:03 -0700 (PDT) Received: from saguaro.East.Sun.COM (saguaro.East.Sun.COM [129.148.75.130]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA10978 for ; Thu, 17 Aug 2000 11:14:01 -0400 (EDT) Received: (from aha@localhost) by saguaro.East.Sun.COM (8.9.3+Sun/8.9.1) id LAA03478; Thu, 17 Aug 2000 11:13:59 -0400 (EDT) From: Anne Anderson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14748.311.613517.443300@east.sun.com> Date: Thu, 17 Aug 2000 11:13:59 -0400 (EDT) To: ietf-pkix@imc.org Subject: excluding all names of given type X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid CASE: NameConstraints excludedSubtrees contains a directoryName where the RDNSequence is null SEMANTICS: Does this mean that the subsequent path may contain no names of type directoryName in either Subject or the SubjectAlternativeNames? Is there a better way to achieve these semantics? Anne -- Anne H. Anderson Email: aha@acm.org Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692 Received: from picard.noroff.no ([212.20.204.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08771 for ; Thu, 17 Aug 2000 05:12:32 -0700 (PDT) Received: by picard.noroff.no (Postfix, from userid 815) id DD2E522003; Thu, 17 Aug 2000 14:57:24 +0200 (CEST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by picard.noroff.no (Postfix) with ESMTP id 490C1B3803 for ; Thu, 17 Aug 2000 14:57:22 +0200 (CEST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA28488 for ietf-123-outbound.09@ietf.org; Thu, 17 Aug 2000 07:25:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA28340 for ; Thu, 17 Aug 2000 06:57:45 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23269; Thu, 17 Aug 2000 06:57:45 -0400 (EDT) Message-Id: <200008171057.GAA23269@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-qc-06.txt Date: Thu, 17 Aug 2000 06:57:45 -0400 Sender: nsyracus@cnri.reston.va.us X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Qualified Certificates Profile Author(s) : S. Santesson, T. Polk, P. Barzin, M. Nystrom Filename : draft-ietf-pkix-qc-06.txt Pages : 33 Date : 16-Aug-00 This document forms a certificate profile for Qualified Certificates, based on RFC 2459, for use in the Internet. The term Qualified Certificate is used to describe a certificate with a certain qualified status within applicable governing law. Further, Qualified Certificates are issued exclusively to physical persons. The goal of this document is to define a general syntax independent of local legal requirements. The profile is however designed to allow further profiling in order to meet specific local needs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-qc-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-qc-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000816095203.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-qc-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-qc-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000816095203.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA03218 for ; Thu, 17 Aug 2000 03:57:51 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23269; Thu, 17 Aug 2000 06:57:45 -0400 (EDT) Message-Id: <200008171057.GAA23269@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-qc-06.txt Date: Thu, 17 Aug 2000 06:57:45 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Qualified Certificates Profile Author(s) : S. Santesson, T. Polk, P. Barzin, M. Nystrom Filename : draft-ietf-pkix-qc-06.txt Pages : 33 Date : 16-Aug-00 This document forms a certificate profile for Qualified Certificates, based on RFC 2459, for use in the Internet. The term Qualified Certificate is used to describe a certificate with a certain qualified status within applicable governing law. Further, Qualified Certificates are issued exclusively to physical persons. The goal of this document is to define a general syntax independent of local legal requirements. The profile is however designed to allow further profiling in order to meet specific local needs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-qc-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-qc-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000816095203.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-qc-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-qc-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000816095203.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA21831 for ; Wed, 16 Aug 2000 18:28:57 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id SAA28942; Wed, 16 Aug 2000 18:27:50 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 Aug 2000 18:26:20 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4986826@vhqpostal.verisign.com> From: Warwick Ford To: "'Dennis Glatting'" , Stephen Kent Cc: Lynn.Wheeler@firstdata.com, ietf-pkix@imc.org Subject: RE: Client-side revocation checking capability Date: Wed, 16 Aug 2000 18:26:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Dennis: You are referring to T&C related to a particular type of certificate issued by VeriSign in a particular TTP capacity. Our other PKI service and technology offerings have their own contractual T&C. This is not a particularly unusual situation for vendors that offer many different types of products..... Warwick > -----Original Message----- > From: Dennis Glatting [mailto:dennis.glatting@software-munitions.com] > Sent: Wednesday, August 16, 2000 4:10 PM > To: Stephen Kent > Cc: Warwick Ford; Lynn.Wheeler@firstdata.com; ietf-pkix@imc.org > Subject: Re: Client-side revocation checking capability [snip] > And, if you follow www.verisign.com/repository/RPA/, which is > embedded in my Verisign personal certificate as a pointer to > their CPS, you will find: > > * You are responsible for deciding whether the > information in the certificate is relevant. > > * If you are not a Verisign customer (e.g., > some dummy connecting to a Verisign certified > e-commerce site such as Amazon.COM), and you > want to check for revocation, then you must > agree to their CSP if you want to use their > online services. > > So much for Section 1, Section 2, which covers CRLs, is equally > interesting. However, Section 5 says, as a non-subscriber, that > Verisign doesn't warrant certificate merchantability, fitness, > or the accuracy of information. Then, of course, you won't hold > Verisign liable in any way. > > So I see little value in Verisign certificates, infrastructure, and > technologies; and any effort by Verisign to "secure DNS" of dubious > value and a bit frightening. > > Marketing, yo! > Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16959 for ; Wed, 16 Aug 2000 16:12:04 -0700 (PDT) Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.11.0/8.11.0) with ESMTP id e7GNA8286205; Wed, 16 Aug 2000 16:10:08 -0700 (PDT) Message-ID: <399B1F50.74CE1A74@software-munitions.com> Date: Wed, 16 Aug 2000 16:10:08 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: Warwick Ford , Lynn.Wheeler@firstdata.com, ietf-pkix@imc.org Subject: Re: Client-side revocation checking capability References: <2F3EC696EAEED311BB2D009027C3F4F4F93746@vhqpostal.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen Kent wrote: > > Warwick, > > >Steve: > > > >Seeing our corporate name used in vain here, I feel the need to correct a > >misconception of the VeriSign business model that you are promulgating. > > > >VeriSign provides different types of PKI solutions in different > >environments. One model is the "TTP" model, which we feel has served the > >community well for some purposes, such as public SSL server authentication. > >However, we also operate extensive enterprise and service provider PKI > >businesses, in which we enable other organizations to be their own CAs or > >even to allow their customers to be their own CAs, through selective > >outsourcing of particular PKI functions or through service-provider > >technology platforms. > > > >The concept of a "decentralized PKI" based on DNS is in not fundamentally > >alien to our business strategy. > > > >Warwick > > > We agree that VeriSign supports several different PKI models. > However, VeriSign, through its marketing arm, promotes the TTP model > most aggressively, almost to the point of ignoring other PKI models > that you support. For example, last week the dirtector of operations > for veriSig was invited to address the Defense Science Board > Information Assurance panel, in CA. His briefing began with some > marketing slides (for which he apologized). The PKI portion of those > slides (the rest emphasized the scope of the NSI DNS business) were > almost exclusively devoted to the TTP business, especially the web > server aspect. In fact, I had to raise the fact that VeriSIgn > offered programs such as VeriSign Onsite to bring out the other > aspects of the business. So, while we agree that, from a technical > perspective that VeriSign does offer more than just TTP services, the > public perception, which has been cultivated by VeriSign, focuses > almost exclusively on the TTP model. > And, if you follow www.verisign.com/repository/RPA/, which is embedded in my Verisign personal certificate as a pointer to their CPS, you will find: * You are responsible for deciding whether the information in the certificate is relevant. * If you are not a Verisign customer (e.g., some dummy connecting to a Verisign certified e-commerce site such as Amazon.COM), and you want to check for revocation, then you must agree to their CSP if you want to use their online services. So much for Section 1, Section 2, which covers CRLs, is equally interesting. However, Section 5 says, as a non-subscriber, that Verisign doesn't warrant certificate merchantability, fitness, or the accuracy of information. Then, of course, you won't hold Verisign liable in any way. So I see little value in Verisign certificates, infrastructure, and technologies; and any effort by Verisign to "secure DNS" of dubious value and a bit frightening. Marketing, yo! Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13256 for ; Wed, 16 Aug 2000 12:15:59 -0700 (PDT) Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA07801 for ; Wed, 16 Aug 2000 15:15:50 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: Date: Wed, 16 Aug 2000 15:12:23 -0400 To: ietf-pkix@imc.org From: Stephen Kent Subject: final minutes Content-Type: multipart/alternative; boundary="============_-1245669045==_ma============" --============_-1245669045==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Several folks sent messages correcting minor errors in the minutes. I have made the requested changes and will now submit a final version to the IETF Secretariat. Also, I was informed that the minutes from the Adelaide meeting did not make it into the IETF archive. I will attempt to address that problem as well. Finally, I have received slides from the speakers (in a timely fashion) and will be forwarding those as well. Steve ----- PKIX WG Meeting 8/1/00 Edited by Steve Kent (WG co-chair) The PKIX WG met once during the 48th IETF and a total of approximately 180 individuals participated in this meeting. The meeting began with the announcement that Tim Polk of NIST will take over from Warwick Ford as a co-chair of the WG. Warwick received a round of applause from the audience, for his service to the Wg since its inception. Tim began the meeting with a review of the status of all of the WG documents. The following text summarizes the status of the documents: PKIX COMPLETED DOCUMENTS (RFCs) PKIX Cert/CRL Profile (RFC 2459) HTTP/FTP Operations (RFC 2585) LDAP V2 Operational Protocols (RFC 2559) LDAP V2 Schema (RFC 2587) OCSP (RFC 2560) CMP (RFC 2510) CRMF (RFC 2511) CMC (RFC 2797) Diffie-Hellman POP (RFC 2875) Certificate Policy/Practices Guideline (RFC 2527) KEA Algorithms for Profile (RFC 2528) PKIX WORK IN PROGRESS (Internet Drafts) Revised Profile (draft-ietf-pkix-new-part1-02.txt) Algorithms for Profile (draft-ietf-pkix-ipki-pkalgs-00.txt) Qualified Certificates (draft-ietf-pkix-qc-05.txt) Time Stamp (draft-ietf-pkix-time-stamp-09.txt) PKIX Roadmap (draft-ietf-pkix-roadmap-05.txt) Revised CMP (draft-ietf-pkix-rfc2510bis.01) CMP Transports (draft-ietf-pkix-cmp-transport-protocols-01.txt) Operational Protocols - LDAPv3 (draft-ietf-pkix-ldap-v3-02.txt) Additional LDAP Schema (draft-ietf-pkix-ldap-schema-00.txt) Attribute Certificate Profile for Authorization (draft-ietf-pkix-ac509prof-04.txt) Limited Attribute Cert Acquisition Prot (draft-ietf-pkix-laap-01.txt) DCS (draft-ietf-pkix-dcs-05.txt) Simple Certificate Validation Protocol (SCVP) (draft-ietf-pkix-scvp-03.txt) Permanent Identifier (draft-ietf-pkix-pi-00.txt) Repository Locator Service (draft-ietf-pkix-pkixrep-00.txt) Tech. Rqmts. For Non-Repudiation (draft-ietf-pkix-technr-01.txt) ACTIVE PROJECTS: LDAP v3 Profile (D. Chadwick-U. of Salford) Split profile into two pieces: protocol vs. schema. The protocol parts should be completed in the next 6-8 weeks and be ready for WG last call. (Suggestion that the LDAP WG also be included in this last call.) The schema work will take longer, as it is a new topic. A major change for the schema is to allow searching on certificate fields, rather than searching on the directory attributes extracted from the certificate. For now, plan to keep the schema work related to certificates in PKIX, not in an LDAP WG, with David acting as principal liaison between the two groups. RFC 2459 evolution (T. Polk-NIST) 2459 has been split into algorithm profiles vs. certificate & CRL syntax and processing. This allows the algorithms document to be revised as algorithms change, without affecting the syntax and processing standard. There is little new material here, mostly clarifications, editorial revisions, etc. We will hold a straw poll on the list on naming mandatory algorithms, e.g., RSA and SHA-1. With the end of the RSA patent period, many other security WGs are taking similar steps. Also, if the WG decides to identify mandatory algorithms, we need to decide whether they are specified in the certificate and CRL processing document, or in the algorithms document. (See slides for more details.) We should be able to go to WG last call very soon on these documents. Qualified Certificates (S. Santesson-AddTrust) Discussions at this IETF meeting have resolved the few remaining points of contention with regard to this draft. Minor changes in wording will result in a new draft by the end of this week and this draft will be forwarded to the security area directors to proceed with the IESG last call. Permanent Identifiers (D, Pinkas-Bull) To be used only in certificates issued to individuals. Designed to track real world identity in the face of name changes, e.g., marriage or job changes within an organization. The ID is expressed as a new name type, with two components; an assigner authority and a name. The first component may be omitted, in which case the certificate Issuer is presumed to be the assigner authority. Note that a registered ID (from general name form) has the necessary property that it is globally unique, and permanent (although not directly meaningful). Thus, depending on which general name form is employed, one can compare names either within a CA domain, or globally, across all CAs. Plan for now is to proceed with it as a separate standards track document, not merged with the QC or son-of-RFC-2459 documents. (See slides for more details.) Time Stamping Protocol (D. Pinkas-Bull) Now on version 9. Several changes made after last call completed. Changes include definition of the serial number consistent with 2459 (can even be a hash of up to 160 bits!), change to SIA from AIA, etc. A number of minor wording changes were made, but the restriction on exclusive use of the TSA private key for signing responses has been preserved. Ready for forwarding to the IESG. Preface to OCSPX and SCVP discussions: As proposed at the Adelaide meeting, a small group was formed and generated a requirements document to characterize the motivations for remote validation services, to define the requirements for such services. The group did not compare the candidate protocols relative to these requirements. OCSP Extensions (M. Myers-VeriSign) Previous ID has expired, expunged from IETF web site. Mike argues that OCSP is the right choice for remote path processing (RPP), via the addition of extensions. Proposal is to revise RFC 2560, to fix minor problems, clarify OCPS role as a framework for remote validation services. Then, create separate documents to define extensions for remote path validation, remote path discovery, etc. So, there would not be an OCSPX document, but rather definitions for syntax and processing for standard extensions. (See slides for more details.) D. Pinkas provided some slides addressing the parameters of remote path processing, e.g., how the requestor constrains the path processing or path construction operation. So, the format needs to be able to indicate whether the requestor wants CRLs or OCSP responses, what security policy to use in evaluating a certificate path, other constraints, etc. Denis argues that the requirements document needs to cover more of these details. However, Paul Hoffman noted that the group was not able to agree to a larger set of "requirements." (See slides for more details.) SCVP (A. Malpani-ValiCert) The speaker reviewed RPP requirements and what OCSP does to support part of the process. Ambarish argues that changes to OCSP to meet these extended requirements may break existing OCSP implementations, and that the code base for OCSP is small, so there is not much to leverage in building an RPP protocol. SCVP will support both ASN.1 and XML, consistent with perceived client requirements to retain data in this format. (See slides for more details.) Attribute Certificates (S. Farrell-Baltimore) Profile has been updated, synchronized with latest X.509 version, and has completed WG last call. It is suggested that this document reference the successor to 2459, which clears up the residual reference issues. CMP (C. Adams-Entrust) CMP RFC is being revised to reflect minor changes. Plan is to wait until completion of interoperability testing (in the PKI forum) to finalize changes to this document, to reflect any further clarifications that arise from this testing. Repository Locator (P. Hallam-Baker-VeriSign) Goal of this document is to specify a means by which one can map an RFC822 name for a user to the LDAP server where the user's certificates are stored. The proposed approach is to use the SRV record in the DNS to provide the necessary pointer. The SRV record is analogous to an MX record, but more general, supporting a list of services and matching addresses. Open questions include the internationalization of DNS (which the DNS WG will address), plus communicating conventions for access protocols (LDAP, HTTP, ...). The base document is a very small work item, because it is merely profiling the existing SRV record. Separate documents will be generated to describe each access protocol convention, e.g., LDAP, OCSP, and HTTP. Need to coordinate with LDAP WG and maybe DNS WGs on their plans for using SRV records for LDAP directory location. (See slides for more details.) CMP Interoperability testing (R. Moskowitz-ICSA) ICSA is working with PKI Forum to coordinate these interoperability tests. Three workshops have been conducted to date, with more scheduled for August and September. Various algorithms, transport protocols, POP mechanisms have been tested. A number vendors have participated. Planned public demo at NISSC in October. Experience shows that variants in CA-side implementations do cause interoperability problems, and further clarifications are needed in RFC 2510 to help resolve ambiguities. CMC interoperability testing may also be pursued in the future. --============_-1245669045==_ma============ Content-Type: text/enriched; charset="us-ascii" Several folks sent messages correcting minor errors in the minutes. I have made the requested changes and will now submit a final version to the IETF Secretariat. Also, I was informed that the minutes from the Adelaide meeting did not make it into the IETF archive. I will attempt to address that problem as well. Finally, I have received slides from the speakers (in a timely fashion) and will be forwarding those as well. Steve ----- Courier_NewPKIX WG Meeting 8/1/00 Edited by Steve Kent (WG co-chair) The PKIX WG met once during the 48th IETF and a total of approximately 180 individuals participated in this meeting. The meeting began with the announcement that Tim Polk of NIST will take over from Warwick Ford as a co-chair of the WG. Warwick received a round of applause from the audience, for his service to the Wg since its inception. Tim began the meeting with a review of the status of all of the WG documents. The following text summarizes the status of the documents: PKIX COMPLETED DOCUMENTS (RFCs) PKIX Cert/CRL Profile (RFC 2459) HTTP/FTP Operations (RFC 2585) LDAP V2 Operational Protocols (RFC 2559) LDAP V2 Schema (RFC 2587) OCSP (RFC 2560) CMP (RFC 2510) CRMF (RFC 2511) CMC (RFC 2797) Diffie-Hellman POP (RFC 2875) Certificate Policy/Practices Guideline (RFC 2527) KEA Algorithms for Profile (RFC 2528) PKIX WORK IN PROGRESS (Internet Drafts) Revised Profile (draft-ietf-pkix-new-part1-02.txt) Algorithms for Profile (draft-ietf-pkix-ipki-pkalgs-00.txt) Qualified Certificates (draft-ietf-pkix-qc-05.txt) Time Stamp (draft-ietf-pkix-time-stamp-09.txt) PKIX Roadmap (draft-ietf-pkix-roadmap-05.txt) Revised CMP (draft-ietf-pkix-rfc2510bis.01) CMP Transports (draft-ietf-pkix-cmp-transport-protocols-01.txt) Operational Protocols - LDAPv3 (draft-ietf-pkix-ldap-v3-02.txt) Additional LDAP Schema (draft-ietf-pkix-ldap-schema-00.txt) Attribute Certificate Profile for Authorization (draft-ietf-pkix-ac509prof-04.txt) Limited Attribute Cert Acquisition Prot (draft-ietf-pkix-laap-01.txt) DCS (draft-ietf-pkix-dcs-05.txt) Simple Certificate Validation Protocol (SCVP) (draft-ietf-pkix-scvp-03.txt) Permanent Identifier (draft-ietf-pkix-pi-00.txt) Repository Locator Service (draft-ietf-pkix-pkixrep-00.txt) Tech. Rqmts. For Non-Repudiation (draft-ietf-pkix-technr-01.txt) ACTIVE PROJECTS: LDAP v3 Profile (D. Chadwick-U. of Salford) Split profile into two pieces: protocol vs. schema. The protocol parts should be completed in the next 6-8 weeks and be ready for WG last call. (Suggestion that the LDAP WG also be included in this last call.) The schema work will take longer, as it is a new topic. A major change for the schema is to allow searching on certificate fields, rather than searching on the directory attributes extracted from the certificate. For now, plan to keep the schema work related to certificates in PKIX, not in an LDAP WG, with David acting as principal liaison between the two groups. RFC 2459 evolution (T. Polk-NIST) 2459 has been split into algorithm profiles vs. certificate & CRL syntax and processing. This allows the algorithms document to be revised as algorithms change, without affecting the syntax and processing standard. There is little new material here, mostly clarifications, editorial revisions, etc. We will hold a straw poll on the list on naming mandatory algorithms, e.g., RSA and SHA-1. With the end of the RSA patent period, many other security WGs are taking similar steps. Also, if the WG decides to identify mandatory algorithms, we need to decide whether they are specified in the certificate and CRL processing document, or in the algorithms document. (See slides for more details.) We should be able to go to WG last call very soon on these documents. Qualified Certificates (S. Santesson-AddTrust) Discussions at this IETF meeting have resolved the few remaining points of contention with regard to this draft. Minor changes in wording will result in a new draft by the end of this week and this draft will be forwarded to the security area directors to proceed with the IESG last call. Permanent Identifiers (D, Pinkas-Bull) To be used only in certificates issued to individuals. Designed to track real world identity in the face of name changes, e.g., marriage or job changes within an organization. The ID is expressed as a new name type, with two components; an assigner authority and a name. The first component may be omitted, in which case the certificate Issuer is presumed to be the assigner authority. Note that a registered ID (from general name form) has the necessary property that it is globally unique, and permanent (although not directly meaningful). Thus, depending on which general name form is employed, one can compare names either within a CA domain, or globally, across all CAs. Plan for now is to proceed with it as a separate standards track document, not merged with the QC or son-of-RFC-2459 documents. (See slides for more details.) Time Stamping Protocol (D. Pinkas-Bull) Now on version 9. Several changes made after last call completed. Changes include definition of the serial number consistent with 2459 (can even be a hash of up to 160 bits!), change to SIA from AIA, etc. A number of minor wording changes were made, but the restriction on exclusive use of the TSA private key for signing responses has been preserved. Ready for forwarding to the IESG. Preface to OCSPX and SCVP discussions: As proposed at the Adelaide meeting, a small group was formed and generated a requirements document to characterize the motivations for remote validation services, to define the requirements for such services. The group did not compare the candidate protocols relative to these requirements. OCSP Extensions (M. Myers-VeriSign) Previous ID has expired, expunged from IETF web site. Mike argues that OCSP is the right choice for remote path processing (RPP), via the addition of extensions. Proposal is to revise RFC 2560, to fix minor problems, clarify OCPS role as a framework for remote validation services. Then, create separate documents to define extensions for remote path validation, remote path discovery, etc. So, there would not be an OCSPX document, but rather definitions for syntax and processing for standard extensions. (See slides for more details.) D. Pinkas provided some slides addressing the parameters of remote path processing, e.g., how the requestor constrains the path processing or path construction operation. So, the format needs to be able to indicate whether the requestor wants CRLs or OCSP responses, what security policy to use in evaluating a certificate path, other constraints, etc. Denis argues that the requirements document needs to cover more of these details. However, Paul Hoffman noted that the group was not able to agree to a larger set of "requirements." (See slides for more details.) SCVP (A. Malpani-ValiCert) The speaker reviewed RPP requirements and what OCSP does to support part of the process. Ambarish argues that changes to OCSP to meet these extended requirements may break existing OCSP implementations, and that the code base for OCSP is small, so there is not much to leverage in building an RPP protocol. SCVP will support both ASN.1 and XML, consistent with perceived client requirements to retain data in this format. (See slides for more details.) Attribute Certificates (S. Farrell-Baltimore) Profile has been updated, synchronized with latest X.509 version, and has completed WG last call. It is suggested that this document reference the successor to 2459, which clears up the residual reference issues. CMP (C. Adams-Entrust) CMP RFC is being revised to reflect minor changes. Plan is to wait until completion of interoperability testing (in the PKI forum) to finalize changes to this document, to reflect any further clarifications that arise from this testing. Repository Locator (P. Hallam-Baker-VeriSign) Goal of this document is to specify a means by which one can map an RFC822 name for a user to the LDAP server where the user's certificates are stored. The proposed approach is to use the SRV record in the DNS to provide the necessary pointer. The SRV record is analogous to an MX record, but more general, supporting a list of services and matching addresses. Open questions include the internationalization of DNS (which the DNS WG will address), plus communicating conventions for access protocols (LDAP, HTTP, ...). The base document is a very small work item, because it is merely profiling the existing SRV record. Separate documents will be generated to describe each access protocol convention, e.g., LDAP, OCSP, and HTTP. Need to coordinate with LDAP WG and maybe DNS WGs on their plans for using SRV records for LDAP directory location. (See slides for more details.) CMP Interoperability testing (R. Moskowitz-ICSA) ICSA is working with PKI Forum to coordinate these interoperability tests. Three workshops have been conducted to date, with more scheduled for August and September. Various algorithms, transport protocols, POP mechanisms have been tested. A number vendors have participated. Planned public demo at NISSC in October. Experience shows that variants in CA-side implementations do cause interoperability problems, and further clarifications are needed in RFC 2510 to help resolve ambiguities. CMC interoperability testing may also be pursued in the future. --============_-1245669045==_ma============-- Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA10745 for ; Wed, 16 Aug 2000 11:10:08 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 16 Aug 2000 12:09:27 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 16 Aug 2000 12:09:24 -0600 From: "Bob Jueneman" To: Cc: Subject: RE: Client-side revocation checking capability Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA10746 Peter, The current GroupWise S/MIME functionality is built upon the capabilities provided by IE5 and MS-CAPI, unlike other Novell applications which use our NICI crypto and are more tightly integrated with NDS. The currently shipping version of GroupWise does not support CRLs, although I believe that functionality will be included in the forthcoming release, later this year. Because of the more or less common infrastructure, plug-ins for other revocation/validation models, e.g., ValiCert's, should be straight-forward, assuming there is sufficient user demand. Since GroupWise shares the same underpinnings as IE5, we have both some of the same benefits and same problems as the existing browsers. In particular, looking forward a couple of years, I can foresee a chaotic situation where every organization on the planet want to have their own "root" CA, and the browsers and e-mail clients simply collapse under the weight of the trust administration. The single PEM-type of hierarchical structure obviously isn't going to work, but an unconstrained explosion of trusted roots isn't going to work either. Some commercial CA's will fail to gain sufficient acceptance, and others will just be ignored. If the existing TTPs are not willing to enable the use of subordinate CAs (some are and some aren't, for obvious business reasons), then an opportunity will arise for others to take on this responsibility. one way or the other, though, some coalescing of CAs is going have to take place before very long. >From my point of view, the existing PKI and validation structure has been perhaps excessively focused on the role of the subscriber and the CA and the identity function, and not enough attention has been payed to the management of the basic, underlying TRUST relationship by the relying party. For that reason, we are looking carefully at the use of the directory to provide local mediation and enterprise control over the trust relationships at the relying party end. Case in point, lets say that a hospital decides to revoke a Doctor's staff privileges, perhaps because a few too many of his patients have been dying. Not only do they not want him in the operating room, they don't want him reviewing patient records, issuing prescriptions or medical orders, etc. Most of those issues only involve access control, not nonrepudiation. Now, does the hospital care what say VeriSign thinks of that Doctor's credentials, or even the State of Utah? Clearly not. So CRL checking isn't the answer for managing _trust_, because the issue isn't identity, and it isn't key compromise either. An attribute certificate issued by the hospital, as opposed to an identity broker, might be the solution, but frankly just getting identity certs deployed and working has been a sufficient challenge. And it is really hard to imagine every hospital, pharmacy, HMO, etc., issuing their own individual attribute cert to every doctor, complete with their own revocation structure. This might be necessary if nonrepudiation were really an issue, but in most of these cases it probably isn't. In that case, a local directory can be used as the relying party's Delphic oracle with respect to privilege, and it may also be used to cache certificates and CRLs to minimize the computational load and bandwidth requirements. Where CRL checking does have a role to play in this environment, I believe, is in the case of extranet access control., In this case Enterprise A may issue identity certificates to one of their employees, perhaps using the Novell Security Attributes to confirm that Dr. Doakes is a doctor. Enterprise B, assuming they have a relationship with Enterprise A, may accept Dr. Doakes certificate as sufficient evidence of his credentials and allow him access to certain files, based only on his certificate and Enterprise A's say so (while of course auditing his actions based on the name in his certificate). In that type of scenario, Enterprise B would be relying on Enterprise A to revoke Dr. Doakes certificate if he is no longer working for them. But that revocation could take the form of a CRL, or alternately a directory status update. Each enterprise probably doesn't want to take on the management burden of managing the entries in the directory for all of the employees in the other enterprise, but they might be willing to accept the burden on an exception basis. Bob >>> Peter Williams 08/15/00 06:34PM >>> Bob, How does the GroupWise client handle revocation and trust points? Is the root of trust the Novell directory? -----Original Message----- From: Bob Jueneman [mailto:BJUENEMAN@novell.com] Sent: Monday, August 14, 2000 9:09 PM To: awa1@home.com Cc: juancarlos.perez@acepta.com; ietf-pkix@imc.org; anders.rundgren@telia.com Subject: Re: Client-side revocation checking capability Al, I don't disagree with you, but then I don't distribute the popular browsers or control what their defaults are, either. All that I was trying to say was that there are, substantive reasons to believe that the CRL "cure" may be worse than the disease, at least with respect to the current use of PKI consumer e-commerce sites. that's not to say that other applications may not have different trade-offs and criteria. Without making too big a deal of the whole issue, I think it is important to realize that the goal of PKI is to reduce risk to an affordable level, NOT necessarily to try to reduce that risk to absolute zero, regardless of cost. Bob >>> Al Arsenault 08/14/00 07:22PM >>> Bob, et alia: The scenario against which CRL-checking-for-server-certs-in-SSL-sessions protects is: - the key for Popular_fictional_site.com is compromised, and whoever has it sets up a duplicate site, with appropriate DNS spoofs to direct traffic to the duplicate site - the legitimate owners of Popular_fictional_site.com realize that the compromise has occurred, report it, and get a new cert. - now, along comes Jean User, connecting to Popular_fictional_site.com. Quick: is this the real site, or the spoof? Both have certs and matching private keys that trace back to the same trusted root. If the client checks the CRL, (s)he will detect that they cert/key offered by the spoof site is revoked, while the cert/key offered by the legitimate site will be okay. Okay, now, how realistic is that threat? Is that the one against which you're defending? Who knows? But it is one of the threats against which the revocation mechanism was designed to work. Al Arsenault Chief Security Architect Diversinet Corp. Bob Jueneman wrote: > > Anders, > > There is a lot of practical truth in what you say. > > CRL checking certainly seems like a nice thing to do cryptographically, until you consider what the threat is that you are trying to address. > > Let's suppose amazon.com's key were compromised somehow. What would happen? Well, the first thing is that they would call up their CA and get a new certificate, and then download that certificate to any SSL user. So the old certificate and key would be completely out of the picture, and hence no CRL would be needed, much less OCSP. since they don't use that certificate to sign anything other than SSL sessions, which in which the certificates are sent in line, they don't even need to revoke their old certs -- just stop using them. > > The only case where a CRL might be useful in that scenario would be in the case of some fly-by-night mafia.com type of store-front, where the CA might conceivably revoke the certificate for fraud or other cause. However, that would represent a substantial legal liability for the CA, and so that doesn't seem terribly likely in practice. > > Since the retail merchant accounts for the overwhelming use of PKI to date (e-mail is just barely beginning to make a dent, and everything else are just pilots, it isn't surprising that the browsers don't enable CRL checking by default. It would merely add lots of delay and processing time. > > Bob > > >>> "Anders Rundgren" 08/12/00 12:02AM >>> > Juan Carlos, > > That on-line checking of server-certificates is not standard in browsers is probably > beacuse a revocation is not that likely to happen. In case of a key compromize at the VeriSign > CA the whole world will be notified and in the case of key compromize in a web-server no > one will know or be notified. You can steal a web-cert+key from a lousy installation (most are) > in case you have sys-admin rights. Nothing to do about except tighten up internal security. > And if the host-name is no longer valid (the company filed for bancruptsy) the > server will be taken down some day. > > IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where > you may revoke yourself due to loss (of card) or by the company because you got fired. > > This is a slightly different answer than you get by asking a typical crypto expert but to my > knowledge they usually know zilch, nada etc. about practical things that may be 100 times more > important than the cryptologic solurtion. I.e. as long as there are serious practical problems > associated with server-certificates, CRLs etc. would basically add nothing (but delays). > > Regards > Anders Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA10340 for ; Wed, 16 Aug 2000 11:06:42 -0700 (PDT) Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA27278; Wed, 16 Aug 2000 14:06:00 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4F93746@vhqpostal.verisign.com> References: <2F3EC696EAEED311BB2D009027C3F4F4F93746@vhqpostal.verisign.com> Date: Wed, 16 Aug 2000 13:59:31 -0400 To: Warwick Ford From: Stephen Kent Subject: RE: Client-side revocation checking capability Cc: Lynn.Wheeler@firstdata.com, ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Warwick, >Steve: > >Seeing our corporate name used in vain here, I feel the need to correct a >misconception of the VeriSign business model that you are promulgating. > >VeriSign provides different types of PKI solutions in different >environments. One model is the "TTP" model, which we feel has served the >community well for some purposes, such as public SSL server authentication. >However, we also operate extensive enterprise and service provider PKI >businesses, in which we enable other organizations to be their own CAs or >even to allow their customers to be their own CAs, through selective >outsourcing of particular PKI functions or through service-provider >technology platforms. > >The concept of a "decentralized PKI" based on DNS is in not fundamentally >alien to our business strategy. > >Warwick > We agree that VeriSign supports several different PKI models. However, VeriSign, through its marketing arm, promotes the TTP model most aggressively, almost to the point of ignoring other PKI models that you support. For example, last week the dirtector of operations for veriSig was invited to address the Defense Science Board Information Assurance panel, in CA. His briefing began with some marketing slides (for which he apologized). The PKI portion of those slides (the rest emphasized the scope of the NSI DNS business) were almost exclusively devoted to the TTP business, especially the web server aspect. In fact, I had to raise the fact that VeriSIgn offered programs such as VeriSign Onsite to bring out the other aspects of the business. So, while we agree that, from a technical perspective that VeriSign does offer more than just TTP services, the public perception, which has been cultivated by VeriSign, focuses almost exclusively on the TTP model. Steve Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08257 for ; Wed, 16 Aug 2000 10:15:12 -0700 (PDT) From: Lynn.Wheeler@firstdata.com Received: from mailgw.firstdata.com ([204.48.27.156]) by mail-ewr-3.pilot.net with ESMTP id NAA21099; Wed, 16 Aug 2000 13:15:03 -0400 (EDT) Received: from lnsunr02.firstdata.com (localhost [127.0.0.1]) by mailgw.firstdata.com with SMTP id NAA26643; Wed, 16 Aug 2000 13:15:02 -0400 (EDT) Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525693D.005E4131 ; Wed, 16 Aug 2000 13:09:30 -0400 X-Lotus-FromDomain: FDC To: Stephen Kent cc: ietf-pkix@imc.org Message-ID: <8525693D.005E4021.00@lnsunr02.firstdata.com> Date: Wed, 16 Aug 2000 10:13:33 -0700 Subject: Re: Client-side revocation checking capability Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline actually I believe in CERTS containing some amount of "account" data that can be used in offline environments when access to the account record is not available. In that sense, for business applications that are account record oriented, CERTS can provide a stale (possibly subset) of what might appear in the business account record. however, in an online model where a transaction or message has to "hit" the account record in any case, it is possible to obtain the public key from the "master" in the account record ... w/o having to bother with an account record substitute represented by a CERT (i.e. a certification authority has a master account record someplace with most/all information that went into a CERT ... along with audit trails and other business requirements that are ordinary part of business account transaction). In the DNS case, lack of trusted DNS is even a problem for certification authorities issueing SSL certificates ... since the domain name "authority" that the certificationa authority has to reference to validate the information to put in a CERT ... is the same untrusted DNS infrastructure (as some of the comments about domain name hijacking represents). Part of the solution for created a trusting domain name "authority" operation is to add public keys and digital signature authentication to DNS operation. That would even closes integrity "holes" that SSL certificates have because the authority for the domain information that goes into the SSL certificates can now be trusted. My observation is just that with the addition of public keys to domain name infrastructure ... then the DNS operation not only "hits" an online account record ... but also one that may include the trusted public key (part of making the entry trusted and harder to hijack). DNS already supports returning all sorts of information in addition to host names to ip address mapping ... so the ability of returning such public keys as part of a trusted DNS operation is straight forward. At this point, all DNS operations now could provide both trusted address mapping and public key binding as part of each online operation. Such a facility would then make the majority of existing server-side SSL certificates superfulous and redundant. The side observation is there is a requirement for such a trusted DNS infrastructure ... just to improve the integrity of existing server-side SSL certificates (i.e. problem with hijacking host name and then obtaining a SSL certificate since the certification authority has to resort to using the DNS infrastructure as the authoritative entity for validating DNS information). But addressing that requirement then also makes the need for such servier-side SSL certificates superfulous and redundant. Stephen Kent on 08/15/2000 01:30:47 PM To: Lynn Wheeler@firstdata.com cc: ietf-pkix@imc.org Subject: Re: Client-side revocation checking capability Lynn, I agree that a PKI based on the DNS would be a great benefit to the Internet. Now that VeriSIgn has bought NSI, the likelihood of creating such a PKI seems remote, as it would create a decentralized PKI that would challenge the VeriSign TTP model. DNSSEC makes use of non-certificate constructs (for understandable reasons having to do with DNS security details), that are not really a good substitute for real certs. Of course, you're a strong believer in no certs at all, so I'm not surprised that you would find DNSSEC a suitable alternative all by itself :-). Steve Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA17747 for ; Wed, 16 Aug 2000 06:07:15 -0700 (PDT) Received: from kant [129.27.152.76] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A1E36C500A8; Wed, 16 Aug 2000 15:06:43 +0200 Message-ID: <00e501c00782$d312c720$4c981b81@iaik.tugraz.ac.at> From: "Christian Vogel" To: Subject: TSP implementation IP address change Date: Wed, 16 Aug 2000 15:06:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA17751 The IP address has changed to: 129.27.142.227:318 Regards Christian Vogel -- Christian Vogel office: [cvogel@iaik.at] [http://jcewww.iaik.tu-graz.ac.at] private: [bird@sbox.tu-graz.ac.at] [http://www.sbox.tu-graz.ac.at/home/b/bird] Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA20049 for ; Tue, 15 Aug 2000 17:44:45 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Tue, 15 Aug 2000 17:34:53 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE235E387@seine.valicert.com> From: Peter Williams To: "'Bob Jueneman'" Cc: ietf-pkix@imc.org Subject: RE: Client-side revocation checking capability Date: Tue, 15 Aug 2000 17:34:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Bob, How does the GroupWise client handle revocation and trust points? Is the root of trust the Novell directory? -----Original Message----- From: Bob Jueneman [mailto:BJUENEMAN@novell.com] Sent: Monday, August 14, 2000 9:09 PM To: awa1@home.com Cc: juancarlos.perez@acepta.com; ietf-pkix@imc.org; anders.rundgren@telia.com Subject: Re: Client-side revocation checking capability Al, I don't disagree with you, but then I don't distribute the popular browsers or control what their defaults are, either. All that I was trying to say was that there are, substantive reasons to believe that the CRL "cure" may be worse than the disease, at least with respect to the current use of PKI consumer e-commerce sites. that's not to say that other applications may not have different trade-offs and criteria. Without making too big a deal of the whole issue, I think it is important to realize that the goal of PKI is to reduce risk to an affordable level, NOT necessarily to try to reduce that risk to absolute zero, regardless of cost. Bob >>> Al Arsenault 08/14/00 07:22PM >>> Bob, et alia: The scenario against which CRL-checking-for-server-certs-in-SSL-sessions protects is: - the key for Popular_fictional_site.com is compromised, and whoever has it sets up a duplicate site, with appropriate DNS spoofs to direct traffic to the duplicate site - the legitimate owners of Popular_fictional_site.com realize that the compromise has occurred, report it, and get a new cert. - now, along comes Jean User, connecting to Popular_fictional_site.com. Quick: is this the real site, or the spoof? Both have certs and matching private keys that trace back to the same trusted root. If the client checks the CRL, (s)he will detect that they cert/key offered by the spoof site is revoked, while the cert/key offered by the legitimate site will be okay. Okay, now, how realistic is that threat? Is that the one against which you're defending? Who knows? But it is one of the threats against which the revocation mechanism was designed to work. Al Arsenault Chief Security Architect Diversinet Corp. Bob Jueneman wrote: > > Anders, > > There is a lot of practical truth in what you say. > > CRL checking certainly seems like a nice thing to do cryptographically, until you consider what the threat is that you are trying to address. > > Let's suppose amazon.com's key were compromised somehow. What would happen? Well, the first thing is that they would call up their CA and get a new certificate, and then download that certificate to any SSL user. So the old certificate and key would be completely out of the picture, and hence no CRL would be needed, much less OCSP. since they don't use that certificate to sign anything other than SSL sessions, which in which the certificates are sent in line, they don't even need to revoke their old certs -- just stop using them. > > The only case where a CRL might be useful in that scenario would be in the case of some fly-by-night mafia.com type of store-front, where the CA might conceivably revoke the certificate for fraud or other cause. However, that would represent a substantial legal liability for the CA, and so that doesn't seem terribly likely in practice. > > Since the retail merchant accounts for the overwhelming use of PKI to date (e-mail is just barely beginning to make a dent, and everything else are just pilots, it isn't surprising that the browsers don't enable CRL checking by default. It would merely add lots of delay and processing time. > > Bob > > >>> "Anders Rundgren" 08/12/00 12:02AM >>> > Juan Carlos, > > That on-line checking of server-certificates is not standard in browsers is probably > beacuse a revocation is not that likely to happen. In case of a key compromize at the VeriSign > CA the whole world will be notified and in the case of key compromize in a web-server no > one will know or be notified. You can steal a web-cert+key from a lousy installation (most are) > in case you have sys-admin rights. Nothing to do about except tighten up internal security. > And if the host-name is no longer valid (the company filed for bancruptsy) the > server will be taken down some day. > > IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where > you may revoke yourself due to loss (of card) or by the company because you got fired. > > This is a slightly different answer than you get by asking a typical crypto expert but to my > knowledge they usually know zilch, nada etc. about practical things that may be 100 times more > important than the cryptologic solurtion. I.e. as long as there are serious practical problems > associated with server-certificates, CRLs etc. would basically add nothing (but delays). > > Regards > Anders Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18180 for ; Tue, 15 Aug 2000 16:33:25 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id QAA23947; Tue, 15 Aug 2000 16:33:09 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Tue, 15 Aug 2000 16:31:40 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4F93746@vhqpostal.verisign.com> From: Warwick Ford To: Stephen Kent , Lynn.Wheeler@firstdata.com Cc: ietf-pkix@imc.org Subject: RE: Client-side revocation checking capability Date: Tue, 15 Aug 2000 16:31:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Steve: Seeing our corporate name used in vain here, I feel the need to correct a misconception of the VeriSign business model that you are promulgating. VeriSign provides different types of PKI solutions in different environments. One model is the "TTP" model, which we feel has served the community well for some purposes, such as public SSL server authentication. However, we also operate extensive enterprise and service provider PKI businesses, in which we enable other organizations to be their own CAs or even to allow their customers to be their own CAs, through selective outsourcing of particular PKI functions or through service-provider technology platforms. The concept of a "decentralized PKI" based on DNS is in not fundamentally alien to our business strategy. Warwick > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Tuesday, August 15, 2000 1:31 PM > To: Lynn.Wheeler@firstdata.com > Cc: ietf-pkix@imc.org > Subject: Re: Client-side revocation checking capability > > > Lynn, > > I agree that a PKI based on the DNS would be a great benefit to the > Internet. Now that VeriSIgn has bought NSI, the likelihood of > creating such a PKI seems remote, as it would create a decentralized > PKI that would challenge the VeriSign TTP model. > > DNSSEC makes use of non-certificate constructs (for understandable > reasons having to do with DNS security details), that are not really > a good substitute for real certs. Of course, you're a strong > believer in no certs at all, so I'm not surprised that you would find > DNSSEC a suitable alternative all by itself :-). > > Steve > Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16176 for ; Tue, 15 Aug 2000 15:25:11 -0700 (PDT) Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA28463; Tue, 15 Aug 2000 18:24:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <8525693B.0068C56E.00@lnsunr02.firstdata.com> References: <8525693B.0068C56E.00@lnsunr02.firstdata.com> Date: Tue, 15 Aug 2000 16:30:47 -0400 To: Lynn.Wheeler@firstdata.com From: Stephen Kent Subject: Re: Client-side revocation checking capability Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Lynn, I agree that a PKI based on the DNS would be a great benefit to the Internet. Now that VeriSIgn has bought NSI, the likelihood of creating such a PKI seems remote, as it would create a decentralized PKI that would challenge the VeriSign TTP model. DNSSEC makes use of non-certificate constructs (for understandable reasons having to do with DNS security details), that are not really a good substitute for real certs. Of course, you're a strong believer in no certs at all, so I'm not surprised that you would find DNSSEC a suitable alternative all by itself :-). Steve Received: from avocet.prod.itd.earthlink.net (avocet.prod.itd.earthlink.net [207.217.121.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11161 for ; Tue, 15 Aug 2000 12:02:17 -0700 (PDT) Received: from [38.29.130.217] (ip217.phoenix16.az.pub-ip.psi.net [38.29.130.217]) by avocet.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id MAA02624; Tue, 15 Aug 2000 12:01:05 -0700 (PDT) Mime-Version: 1.0 X-Sender: hoytkesterson@mail.earthlink.net Message-Id: Date: Tue, 15 Aug 2000 11:59:49 -0700 To: OSI Directory List , ietf-pkix@imc.org, pki-twg@nist.gov From: "Hoyt L. Kesterson II" Subject: a new revision of the draft 4th edition of X.509 is on the server Content-Type: text/plain; charset="us-ascii" ; format="flowed" hello all we have been receiving comments on the x509 text (thank you all) and have been making corrections. a new revision of the draft 4th edition of x509 is on the directory server in both pdf and office 98 formats. the urls are: ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV5.pdf ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV5.doc this revision (v5) contains: 1) an correction to an asn.1 abstract data type name In the ASN.1 in Clause 11.2.9, replaced "PolicyID ::= CertPolicyID" with: "PolicyID ::= CertPolicyId" This same correction made in Annex A in the AuthenticationFramework module, on page 97 (about 2/3 of the way down the page) 2) a corrected text cross reference In clause 8.2.2.6, 2nd sentence, the reference "as described in 12.4.3", is replaced with "as described in 10". 3) corrections to handle the inhibitAnyPolicy extension Clause 10.1 Path processing inputs: - added item f) to list of inputs to the certification path processing - renumbered old f) to g) and - added f) to the paragraph following list list. Clause 10.3 Path processing variables - added item g) to the list of variables used by the procedure - renumbered old item f) to g) - revised the text of item h) Clause 10.4 Initialization step - revised item h) to reflect the 3 rather than 2 settings Clause 10.5 Certificate processing - Under "The following checks are applied to a certificate": - replaced old steps d) e) and f) with revised steps d), e) and f) - Under "For an intermediate certificate, ..." - added item f) to the list of checks - renumbered old item f) to g) - Under "For all certificates ..." - added a new 2nd bullet to the list - revised the second last paragraph of the clause and delete the last paragraph (redundant). Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA19347 for ; Tue, 15 Aug 2000 05:20:14 -0700 (PDT) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2650.21) id ; Tue, 15 Aug 2000 08:19:59 -0400 Message-ID: <6304000F355DD4119C9000204804F0CC798A96@rbmail101.chamb.disa.mil> From: "Kirlin, Maureen" To: ietf-pkix@imc.org Subject: unsubscribe Date: Tue, 15 Aug 2000 08:19:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Received: from gatekeeper.itsec-debis.de (gatekeeper.itsec-debis.de [195.227.50.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA18217 for ; Tue, 15 Aug 2000 05:00:31 -0700 (PDT) Received: from gatekeeper (gatekeeper [192.168.2.1] (may be forged)) by gatekeeper.itsec-debis.de (8.8.8+Sun/8.8.8) with SMTP id NAA07086 for ; Tue, 15 Aug 2000 13:57:36 +0200 (MET DST) Received: by itsec-debis.de id OAA28543; Tue, 15 Aug 2000 14:29:01 +0200 Message-ID: <39993045.276B1EF9@debis.com> Date: Tue, 15 Aug 2000 13:57:57 +0200 From: Jochen Gottsmann Organization: debis Systemhaus Information Security Services GmbH X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: unsubscribe Content-Type: multipart/mixed; boundary="------------2C2C6C2F1C1F0F9D7FBF0EB6" This is a multi-part message in MIME format. --------------2C2C6C2F1C1F0F9D7FBF0EB6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------2C2C6C2F1C1F0F9D7FBF0EB6 Content-Type: text/x-vcard; charset=us-ascii; name="j.gottsmann.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Jochen Gottsmann Content-Disposition: attachment; filename="j.gottsmann.vcf" begin:vcard n:Gottsmann;Jochen tel;fax:+49 6196 961 451 tel;work:+49 6196 961 380 x-mozilla-html:FALSE org:debis Information Security Services GmbH version:2.1 email;internet:j.gottsmann@debis.com title:Diplom-Mathematiker adr;quoted-printable:;;Mergenthalerallee 38-40=0D=0A=0D=0A;65760 Eschborn;;; fn:Jochen Gottsmann end:vcard --------------2C2C6C2F1C1F0F9D7FBF0EB6-- Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA20815 for ; Mon, 14 Aug 2000 22:01:33 -0700 (PDT) Received: by border.alcanet.com.au id <115212>; Tue, 15 Aug 2000 15:00:39 +1000 Date: Tue, 15 Aug 2000 14:58:14 +1000 From: Raphael Ahn Subject: unsubscribe To: ietf-pkix@imc.org Reply-to: Raphael Ahn Message-Id: <00Aug15.150039est.115212@border.alcanet.com.au> Organization: Alcatel Australia MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal unsubscribe Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA17524 for ; Mon, 14 Aug 2000 21:10:09 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 14 Aug 2000 22:09:19 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 14 Aug 2000 22:09:09 -0600 From: "Bob Jueneman" To: Cc: , , Subject: Re: Client-side revocation checking capability Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id VAA17525 Al, I don't disagree with you, but then I don't distribute the popular browsers or control what their defaults are, either. All that I was trying to say was that there are, substantive reasons to believe that the CRL "cure" may be worse than the disease, at least with respect to the current use of PKI consumer e-commerce sites. that's not to say that other applications may not have different trade-offs and criteria. Without making too big a deal of the whole issue, I think it is important to realize that the goal of PKI is to reduce risk to an affordable level, NOT necessarily to try to reduce that risk to absolute zero, regardless of cost. Bob >>> Al Arsenault 08/14/00 07:22PM >>> Bob, et alia: The scenario against which CRL-checking-for-server-certs-in-SSL-sessions protects is: - the key for Popular_fictional_site.com is compromised, and whoever has it sets up a duplicate site, with appropriate DNS spoofs to direct traffic to the duplicate site - the legitimate owners of Popular_fictional_site.com realize that the compromise has occurred, report it, and get a new cert. - now, along comes Jean User, connecting to Popular_fictional_site.com. Quick: is this the real site, or the spoof? Both have certs and matching private keys that trace back to the same trusted root. If the client checks the CRL, (s)he will detect that they cert/key offered by the spoof site is revoked, while the cert/key offered by the legitimate site will be okay. Okay, now, how realistic is that threat? Is that the one against which you're defending? Who knows? But it is one of the threats against which the revocation mechanism was designed to work. Al Arsenault Chief Security Architect Diversinet Corp. Bob Jueneman wrote: > > Anders, > > There is a lot of practical truth in what you say. > > CRL checking certainly seems like a nice thing to do cryptographically, until you consider what the threat is that you are trying to address. > > Let's suppose amazon.com's key were compromised somehow. What would happen? Well, the first thing is that they would call up their CA and get a new certificate, and then download that certificate to any SSL user. So the old certificate and key would be completely out of the picture, and hence no CRL would be needed, much less OCSP. since they don't use that certificate to sign anything other than SSL sessions, which in which the certificates are sent in line, they don't even need to revoke their old certs -- just stop using them. > > The only case where a CRL might be useful in that scenario would be in the case of some fly-by-night mafia.com type of store-front, where the CA might conceivably revoke the certificate for fraud or other cause. However, that would represent a substantial legal liability for the CA, and so that doesn't seem terribly likely in practice. > > Since the retail merchant accounts for the overwhelming use of PKI to date (e-mail is just barely beginning to make a dent, and everything else are just pilots, it isn't surprising that the browsers don't enable CRL checking by default. It would merely add lots of delay and processing time. > > Bob > > >>> "Anders Rundgren" 08/12/00 12:02AM >>> > Juan Carlos, > > That on-line checking of server-certificates is not standard in browsers is probably > beacuse a revocation is not that likely to happen. In case of a key compromize at the VeriSign > CA the whole world will be notified and in the case of key compromize in a web-server no > one will know or be notified. You can steal a web-cert+key from a lousy installation (most are) > in case you have sys-admin rights. Nothing to do about except tighten up internal security. > And if the host-name is no longer valid (the company filed for bancruptsy) the > server will be taken down some day. > > IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where > you may revoke yourself due to loss (of card) or by the company because you got fired. > > This is a slightly different answer than you get by asking a typical crypto expert but to my > knowledge they usually know zilch, nada etc. about practical things that may be 100 times more > important than the cryptologic solurtion. I.e. as long as there are serious practical problems > associated with server-certificates, CRLs etc. would basically add nothing (but delays). > > Regards > Anders Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA02288 for ; Mon, 14 Aug 2000 18:23:13 -0700 (PDT) Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000815012256.IFNR4590.mail.rdc1.md.home.com@home.com>; Mon, 14 Aug 2000 18:22:56 -0700 Message-ID: <39989B4F.A0FF0C63@home.com> Date: Mon, 14 Aug 2000 21:22:23 -0400 From: Al Arsenault Organization: @Home Network X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Jueneman CC: juancarlos.perez@acepta.com, ietf-pkix@imc.org, anders.rundgren@telia.com Subject: Re: Client-side revocation checking capability References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob, et alia: The scenario against which CRL-checking-for-server-certs-in-SSL-sessions protects is: - the key for Popular_fictional_site.com is compromised, and whoever has it sets up a duplicate site, with appropriate DNS spoofs to direct traffic to the duplicate site - the legitimate owners of Popular_fictional_site.com realize that the compromise has occurred, report it, and get a new cert. - now, along comes Jean User, connecting to Popular_fictional_site.com. Quick: is this the real site, or the spoof? Both have certs and matching private keys that trace back to the same trusted root. If the client checks the CRL, (s)he will detect that they cert/key offered by the spoof site is revoked, while the cert/key offered by the legitimate site will be okay. Okay, now, how realistic is that threat? Is that the one against which you're defending? Who knows? But it is one of the threats against which the revocation mechanism was designed to work. Al Arsenault Chief Security Architect Diversinet Corp. Bob Jueneman wrote: > > Anders, > > There is a lot of practical truth in what you say. > > CRL checking certainly seems like a nice thing to do cryptographically, until you consider what the threat is that you are trying to address. > > Let's suppose amazon.com's key were compromised somehow. What would happen? Well, the first thing is that they would call up their CA and get a new certificate, and then download that certificate to any SSL user. So the old certificate and key would be completely out of the picture, and hence no CRL would be needed, much less OCSP. since they don't use that certificate to sign anything other than SSL sessions, which in which the certificates are sent in line, they don't even need to revoke their old certs -- just stop using them. > > The only case where a CRL might be useful in that scenario would be in the case of some fly-by-night mafia.com type of store-front, where the CA might conceivably revoke the certificate for fraud or other cause. However, that would represent a substantial legal liability for the CA, and so that doesn't seem terribly likely in practice. > > Since the retail merchant accounts for the overwhelming use of PKI to date (e-mail is just barely beginning to make a dent, and everything else are just pilots, it isn't surprising that the browsers don't enable CRL checking by default. It would merely add lots of delay and processing time. > > Bob > > >>> "Anders Rundgren" 08/12/00 12:02AM >>> > Juan Carlos, > > That on-line checking of server-certificates is not standard in browsers is probably > beacuse a revocation is not that likely to happen. In case of a key compromize at the VeriSign > CA the whole world will be notified and in the case of key compromize in a web-server no > one will know or be notified. You can steal a web-cert+key from a lousy installation (most are) > in case you have sys-admin rights. Nothing to do about except tighten up internal security. > And if the host-name is no longer valid (the company filed for bancruptsy) the > server will be taken down some day. > > IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where > you may revoke yourself due to loss (of card) or by the company because you got fired. > > This is a slightly different answer than you get by asking a typical crypto expert but to my > knowledge they usually know zilch, nada etc. about practical things that may be 100 times more > important than the cryptologic solurtion. I.e. as long as there are serious practical problems > associated with server-certificates, CRLs etc. would basically add nothing (but delays). > > Regards > Anders Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA01047 for ; Mon, 14 Aug 2000 18:12:55 -0700 (PDT) Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000815011237.HXOT4590.mail.rdc1.md.home.com@home.com>; Mon, 14 Aug 2000 18:12:37 -0700 Message-ID: <399898E3.BBFC5AE1@home.com> Date: Mon, 14 Aug 2000 21:12:03 -0400 From: Al Arsenault Organization: @Home Network X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Morrill, Dan" CC: "'Dennis Glatting'" , Anders Rundgren , Bob Jueneman , juancarlos.perez@acepta.com, ietf-pkix@imc.org Subject: Re: Client-side revocation checking capability References: <07278C38CF83D21181B200105AA34A859DD4B3@cnbskpt2.cnbs.navy.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is getting kind of off-the-track of "checking whether or not user certificates have been revoked", but... Of equal interest to CA compromise is the case where the CA goes bankrupt. Then the CA's private key is in essence "compromised" by, for example, being auctioned to the highest bidder. It's analogous to the situation that happens all too often today where, when a dot.com starts running into financial trouble, or actually goes under, the customers' private information is sold to the highest bidder or to many bidders to raise funds, pay off creditors, etc. So the company with its public key embedded in IE and/or Netscape goes belly-up. In swoops "Joe's Storm Door and Network Security Company" with a sweet financial bid for the private key, either directly or through the bankruptcy court. (That private key is an asset of the company and can be disposed of in a manner that raises the most value for the creditors.) Once "JSD&NSC" has the private key, who knows what kinds of certs get issued. And since the public key is embedded in millions of copies of the browsers, and can't easily be removed except for millions of users doing it manually, or upgrading to the next version of the browser that doesn't have that "trusted" root key embedded in it, ... (I'll leave it to the reader to figure out what can happen, to whom, and for how long.) BTW: this has already happened, in real life. Apparently, the bids in bankruptcy court for the private key started soaring to fairly high levels, rather quickly. Turned out to be just about the only marketable asset the company had. Al Arsenault "Morrill, Dan" wrote: > > Dennis, > > My question then is, has anyone ever had a CA compromised? (not that it > could not happen, but usually CA's are on the "Must Secure at all costs" > level) Wouldn't that compromise be part of a policy statement? With > appropriate protocols to address a security issue. > > I know that with the CA's that I have worked on, all of them are geared high > (Paranoid) on a sensor like Real Secure, with NetRanger and some Enterprise > management backup, so that if it goes red (looks like it is under attack), > the system is cut off the net whenever there is a possible breach, then the > folks are paged to come take a look. Normal response times, metrics and > other ways of reporting data then take over. If warranted, backups, disaster > recovery protocols then go into effect. Then there is network issues that > can go a long way to secure a CA from compromise. > > I think that security of a CA is more policy than is a technical > specification. Feel free to disagree. > R/ > Dan Morrill > Computer Sciences Corporation > > -----Original Message----- > From: Dennis Glatting [mailto:dennis.glatting@software-munitions.com] > Sent: Monday, August 14, 2000 01:02 PM > To: Anders Rundgren > Cc: Bob Jueneman; juancarlos.perez@acepta.com; ietf-pkix@imc.org > Subject: Re: Client-side revocation checking capability > > Anders Rundgren wrote: > > > > To get a new server-certificate is BTW not that trivial so it makes sense > to improve > > local security in various ways. > > > > One of the (many) problems with the PKI as it is today (okay, SSL/TLS) > is all you need is to compromise one CA and you can issue bogus server > certificates and set up bogus web sites to your hearts content, at > least for a while. The popular browsers have many root certificates, > 58 in Netscape I believe. If you compromise one of those roots then a > browser is going to accept a certificate from a compromised CA with > Amazon.COM and DNS spoofed without distinction from the real > Amazon.COM. Another trick is to send a viral laden e-mail message to > the masses and implant a root certificate. > > In both cases I am skeptical of the value of CR. I am also skeptical > that all consumers would repair their systems even with a flood of > strongly worded advertising. So, :), I believe a compromised or > spoofed (bogus embeded root certificate) root is the kind of gift that > keeps on giving. Received: from cnbskpt2.cnbs.navy.mil (cnbskpt2.cnbs.navy.mil [164.221.184.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA26768 for ; Mon, 14 Aug 2000 14:04:17 -0700 (PDT) Received: by cnbskpt2.cnbs.navy.mil with Internet Mail Service (5.5.2650.21) id ; Mon, 14 Aug 2000 13:59:41 -0700 Message-ID: <07278C38CF83D21181B200105AA34A859DD4B5@cnbskpt2.cnbs.navy.mil> From: "Morrill, Dan" To: "'Tony Bartoletti'" , "Morrill, Dan" , "'Dennis Glatting'" , Anders Rundgren Cc: Bob Jueneman , juancarlos.perez@acepta.com, ietf-pkix@imc.org Subject: RE: Client-side revocation checking capability Date: Mon, 14 Aug 2000 13:59:40 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Tony & co. Sorry, this really peaks my interest, cause this is something I am dealing with. Here goes.... Tony>> I'm my view, the "likely" scenario of a CA root key compromise would follow Tony>> from a "trusted" hardware technician working on the inside, swapping chips Tony>> or boards under the guise of "routine service". It won't be from some net- Tony>> hacker swooping in from afar. Ok, since a server cert is 1 to 1 bound to IP and lots of other data for 1/2 the key, the CA cuts the other half the key, you would already have to have your 1/2 keys cut on your bogus servers, and have access to the systems to do this (RA), plus if it is entrust, you would need their web package, so much like a DDOS crack, this would have to be highly thought out and highly coordinated, with plenty of servers and bandwidth. All that for credit card numbers? It would be easier, and unfortunately far more realistic and frequent to grab the database that stores all this through the web server. I don't see a high return on this scenario for the work involved. Tony>> As Dennis Glatting points out, the far more reasonable scenario involves Tony>> the massive covert replacement of browser "root-certs" accomplished by Tony>> some viral email code, followed shortly thereafter by concerted DNS Tony>> redirection to "fake" commercial sites. The fraudulent root certificates Tony>> verify the fraudulent site certificates, take your credit card numbers Tony>> and run. Same issue, you would have had to prepped a whole catalog of systems, then run your code, easier to simulate the RA responses and mimic a trusted agent via a virus or hostile code? Again, lots of work, lots of really clever thinking if they have incorporated IPSec into the Network, plus overhead as above. Again, not a good value for the return, especially when it is easier to get credit card numbers from an improperly secured dBase or flat file driving the e-commerce site. Tony>> If and when that happens, I suppose browser manufacturers will see fit to make Tony>> it an "option" for consumers to "self-sign" or encrypt the installed Tony>> root-certs, and suffer being prompted for a "key" to verify each transaction. Browsers will already warn you about what is an unrecognized cert (one not in DB7 or the registry) or one that has expired, or one that is not meeting all the qualifications. If you poison a DNS system, and point xxx.xxx.xxx.xxx to a different server, all that cert information is really doing at the server level is initiating SSL/TLS. It is usually signed by Verisign, RSA, DST or any of the other 20+ 'root' certs already in your browser. There should be enough hokey things happening that the user will pay attention, and if they don't like with anything else, you suffer for your actions. I think again, the argument rests with, more trouble and work than it is worth because there are ton's easier ways to get credit card numbers. Now, if it was war time, and we had real enemies, this would be great for DoD's level of effort to exploit this on the web for intelligence information & etc. Maybe then this would be a "fun" issue to explore. Anyone ask what the Banking industry is doing now about this, or have they thought about it yet? Tony>> It seems that most "PKIs" are best suited to everyone BUT the public. On this point we agree. ;-) r/ Dan -----Original Message----- From: Tony Bartoletti [mailto:azb@llnl.gov] Sent: Monday, August 14, 2000 01:48 PM To: Morrill, Dan; 'Dennis Glatting'; Anders Rundgren Cc: Bob Jueneman; juancarlos.perez@acepta.com; ietf-pkix@imc.org Subject: RE: Client-side revocation checking capability At 01:09 PM 8/14/00 -0700, Morrill, Dan wrote: >Dennis, > >My question then is, has anyone ever had a CA compromised? (not that it >could not happen, but usually CA's are on the "Must Secure at all costs" >level) Wouldn't that compromise be part of a policy statement? With >appropriate protocols to address a security issue. > >I know that with the CA's that I have worked on, all of them are geared high >(Paranoid) on a sensor like Real Secure, with NetRanger and some Enterprise >management backup, so that if it goes red (looks like it is under attack), >the system is cut off the net whenever there is a possible breach, then the >folks are paged to come take a look. Normal response times, metrics and >other ways of reporting data then take over. If warranted, backups, disaster >recovery protocols then go into effect. Then there is network issues that >can go a long way to secure a CA from compromise. > >I think that security of a CA is more policy than is a technical >specification. Feel free to disagree. I'm my view, the "likely" scenario of a CA root key compromise would follow from a "trusted" hardware technician working on the inside, swapping chips or boards under the guise of "routine service". It won't be from some net- hacker swooping in from afar. As Dennis Glatting points out, the far more reasonable scenario involves the massive covert replacement of browser "root-certs" accomplished by some viral email code, followed shortly thereafter by concerted DNS redirection to "fake" commercial sites. The fraudulent root certificates verify the fraudulent site certificates, take your credit card numbers and run. If and when that happens, I suppose browser manufacturers will see fit to make it an "option" for consumers to "self-sign" or encrypt the installed root-certs, and suffer being prompted for a "key" to verify each transaction. It seems that most "PKIs" are best suited to everyone BUT the public. ___tony___ >-----Original Message----- >From: Dennis Glatting [mailto:dennis.glatting@software-munitions.com] >Sent: Monday, August 14, 2000 01:02 PM >To: Anders Rundgren >Cc: Bob Jueneman; juancarlos.perez@acepta.com; ietf-pkix@imc.org >Subject: Re: Client-side revocation checking capability > > >Anders Rundgren wrote: > > > > To get a new server-certificate is BTW not that trivial so it makes sense >to improve > > local security in various ways. > > > >One of the (many) problems with the PKI as it is today (okay, SSL/TLS) >is all you need is to compromise one CA and you can issue bogus server >certificates and set up bogus web sites to your hearts content, at >least for a while. The popular browsers have many root certificates, >58 in Netscape I believe. If you compromise one of those roots then a >browser is going to accept a certificate from a compromised CA with >Amazon.COM and DNS spoofed without distinction from the real >Amazon.COM. Another trick is to send a viral laden e-mail message to >the masses and implant a root certificate. > >In both cases I am skeptical of the value of CR. I am also skeptical >that all consumers would repair their systems even with a flood of >strongly worded advertising. So, :), I believe a compromised or >spoofed (bogus embeded root certificate) root is the kind of gift that >keeps on giving. Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26338 for ; Mon, 14 Aug 2000 13:54:05 -0700 (PDT) Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.11.0/8.11.0) with ESMTP id e7EKr4276886; Mon, 14 Aug 2000 13:53:04 -0700 (PDT) Message-ID: <39985C30.A8B91F74@software-munitions.com> Date: Mon, 14 Aug 2000 13:53:04 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Morrill, Dan" CC: Anders Rundgren , Bob Jueneman , juancarlos.perez@acepta.com, ietf-pkix@imc.org Subject: Re: Client-side revocation checking capability References: <07278C38CF83D21181B200105AA34A859DD4B3@cnbskpt2.cnbs.navy.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Morrill, Dan" wrote: > > Dennis, > > My question then is, has anyone ever had a CA compromised? (not that it > could not happen, but usually CA's are on the "Must Secure at all costs" > level) Wouldn't that compromise be part of a policy statement? With > appropriate protocols to address a security issue. > I have not heard of any CA compromise. > I know that with the CA's that I have worked on, all of them are geared high > (Paranoid) on a sensor like Real Secure, with NetRanger and some Enterprise > management backup, so that if it goes red (looks like it is under attack), > the system is cut off the net whenever there is a possible breach, then the > folks are paged to come take a look. Normal response times, metrics and > other ways of reporting data then take over. If warranted, backups, disaster > recovery protocols then go into effect. Then there is network issues that > can go a long way to secure a CA from compromise. > > I think that security of a CA is more policy than is a technical > specification. Feel free to disagree. Of course CAs can be compromised, web sites spoofed, implementations be of low caliber, and browsers and computers attacked in various imaginative was. Some of these things are unlikely and others very likely. All are possible and some aren't very hard. The overall point of my comments is by checking CRLs we improve the quality of transactions. Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA25855 for ; Mon, 14 Aug 2000 13:40:48 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id NAA21902; Mon, 14 Aug 2000 13:39:02 -0700 (PDT) Message-Id: <4.2.2.20000814133155.00aa0100@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 14 Aug 2000 13:48:16 -0700 To: "Morrill, Dan" , "'Dennis Glatting'" , Anders Rundgren From: Tony Bartoletti Subject: RE: Client-side revocation checking capability Cc: Bob Jueneman , juancarlos.perez@acepta.com, ietf-pkix@imc.org In-Reply-To: <07278C38CF83D21181B200105AA34A859DD4B3@cnbskpt2.cnbs.navy. mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:09 PM 8/14/00 -0700, Morrill, Dan wrote: >Dennis, > >My question then is, has anyone ever had a CA compromised? (not that it >could not happen, but usually CA's are on the "Must Secure at all costs" >level) Wouldn't that compromise be part of a policy statement? With >appropriate protocols to address a security issue. > >I know that with the CA's that I have worked on, all of them are geared high >(Paranoid) on a sensor like Real Secure, with NetRanger and some Enterprise >management backup, so that if it goes red (looks like it is under attack), >the system is cut off the net whenever there is a possible breach, then the >folks are paged to come take a look. Normal response times, metrics and >other ways of reporting data then take over. If warranted, backups, disaster >recovery protocols then go into effect. Then there is network issues that >can go a long way to secure a CA from compromise. > >I think that security of a CA is more policy than is a technical >specification. Feel free to disagree. I'm my view, the "likely" scenario of a CA root key compromise would follow from a "trusted" hardware technician working on the inside, swapping chips or boards under the guise of "routine service". It won't be from some net- hacker swooping in from afar. As Dennis Glatting points out, the far more reasonable scenario involves the massive covert replacement of browser "root-certs" accomplished by some viral email code, followed shortly thereafter by concerted DNS redirection to "fake" commercial sites. The fraudulent root certificates verify the fraudulent site certificates, take your credit card numbers and run. If and when that happens, I suppose browser manufacturers will see fit to make it an "option" for consumers to "self-sign" or encrypt the installed root-certs, and suffer being prompted for a "key" to verify each transaction. It seems that most "PKIs" are best suited to everyone BUT the public. ___tony___ >-----Original Message----- >From: Dennis Glatting [mailto:dennis.glatting@software-munitions.com] >Sent: Monday, August 14, 2000 01:02 PM >To: Anders Rundgren >Cc: Bob Jueneman; juancarlos.perez@acepta.com; ietf-pkix@imc.org >Subject: Re: Client-side revocation checking capability > > >Anders Rundgren wrote: > > > > To get a new server-certificate is BTW not that trivial so it makes sense >to improve > > local security in various ways. > > > >One of the (many) problems with the PKI as it is today (okay, SSL/TLS) >is all you need is to compromise one CA and you can issue bogus server >certificates and set up bogus web sites to your hearts content, at >least for a while. The popular browsers have many root certificates, >58 in Netscape I believe. If you compromise one of those roots then a >browser is going to accept a certificate from a compromised CA with >Amazon.COM and DNS spoofed without distinction from the real >Amazon.COM. Another trick is to send a viral laden e-mail message to >the masses and implant a root certificate. > >In both cases I am skeptical of the value of CR. I am also skeptical >that all consumers would repair their systems even with a flood of >strongly worded advertising. So, :), I believe a compromised or >spoofed (bogus embeded root certificate) root is the kind of gift that >keeps on giving. Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 Received: from cnbskpt2.cnbs.navy.mil (cnbskpt2.cnbs.navy.mil [164.221.184.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA25082 for ; Mon, 14 Aug 2000 13:14:27 -0700 (PDT) Received: by cnbskpt2.cnbs.navy.mil with Internet Mail Service (5.5.2650.21) id ; Mon, 14 Aug 2000 13:09:50 -0700 Message-ID: <07278C38CF83D21181B200105AA34A859DD4B3@cnbskpt2.cnbs.navy.mil> From: "Morrill, Dan" To: "'Dennis Glatting'" , Anders Rundgren Cc: Bob Jueneman , juancarlos.perez@acepta.com, ietf-pkix@imc.org Subject: RE: Client-side revocation checking capability Date: Mon, 14 Aug 2000 13:09:50 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Dennis, My question then is, has anyone ever had a CA compromised? (not that it could not happen, but usually CA's are on the "Must Secure at all costs" level) Wouldn't that compromise be part of a policy statement? With appropriate protocols to address a security issue. I know that with the CA's that I have worked on, all of them are geared high (Paranoid) on a sensor like Real Secure, with NetRanger and some Enterprise management backup, so that if it goes red (looks like it is under attack), the system is cut off the net whenever there is a possible breach, then the folks are paged to come take a look. Normal response times, metrics and other ways of reporting data then take over. If warranted, backups, disaster recovery protocols then go into effect. Then there is network issues that can go a long way to secure a CA from compromise. I think that security of a CA is more policy than is a technical specification. Feel free to disagree. R/ Dan Morrill Computer Sciences Corporation -----Original Message----- From: Dennis Glatting [mailto:dennis.glatting@software-munitions.com] Sent: Monday, August 14, 2000 01:02 PM To: Anders Rundgren Cc: Bob Jueneman; juancarlos.perez@acepta.com; ietf-pkix@imc.org Subject: Re: Client-side revocation checking capability Anders Rundgren wrote: > To get a new server-certificate is BTW not that trivial so it makes sense to improve > local security in various ways. > One of the (many) problems with the PKI as it is today (okay, SSL/TLS) is all you need is to compromise one CA and you can issue bogus server certificates and set up bogus web sites to your hearts content, at least for a while. The popular browsers have many root certificates, 58 in Netscape I believe. If you compromise one of those roots then a browser is going to accept a certificate from a compromised CA with Amazon.COM and DNS spoofed without distinction from the real Amazon.COM. Another trick is to send a viral laden e-mail message to the masses and implant a root certificate. In both cases I am skeptical of the value of CR. I am also skeptical that all consumers would repair their systems even with a flood of strongly worded advertising. So, :), I believe a compromised or spoofed (bogus embeded root certificate) root is the kind of gift that keeps on giving. Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24687 for ; Mon, 14 Aug 2000 13:02:39 -0700 (PDT) Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.11.0/8.11.0) with ESMTP id e7EK1d276724; Mon, 14 Aug 2000 13:01:39 -0700 (PDT) Message-ID: <39985023.EF5B5ED8@software-munitions.com> Date: Mon, 14 Aug 2000 13:01:39 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Rundgren CC: Bob Jueneman , juancarlos.perez@acepta.com, ietf-pkix@imc.org Subject: Re: Client-side revocation checking capability References: <002601c0062c$6dc07130$0201a8c0@mega.vincent.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Anders Rundgren wrote: > To get a new server-certificate is BTW not that trivial so it makes sense to improve > local security in various ways. > One of the (many) problems with the PKI as it is today (okay, SSL/TLS) is all you need is to compromise one CA and you can issue bogus server certificates and set up bogus web sites to your hearts content, at least for a while. The popular browsers have many root certificates, 58 in Netscape I believe. If you compromise one of those roots then a browser is going to accept a certificate from a compromised CA with Amazon.COM and DNS spoofed without distinction from the real Amazon.COM. Another trick is to send a viral laden e-mail message to the masses and implant a root certificate. In both cases I am skeptical of the value of CR. I am also skeptical that all consumers would repair their systems even with a flood of strongly worded advertising. So, :), I believe a compromised or spoofed (bogus embeded root certificate) root is the kind of gift that keeps on giving. Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24455 for ; Mon, 14 Aug 2000 13:00:15 -0700 (PDT) Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.11.0/8.11.0) with ESMTP id e7EJx4276707; Mon, 14 Aug 2000 12:59:04 -0700 (PDT) Message-ID: <39984F88.43FAF1C3@software-munitions.com> Date: Mon, 14 Aug 2000 12:59:04 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: henrik.bergman@x-obi.com CC: juancarlos.perez@acepta.com, ietf-pkix@imc.org, anders.rundgren@telia.com Subject: Re: Client-side revocation checking capability References: <399832D7.44313089@software-munitions.com> <39984756.A83E7C87@x-obi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Henrik Bergman wrote: > > Dennis, > > The case you are discribing is hardly a good example to show why CRL's are needed for server-certificates. > If www.amazon.com uses unsecure DNS and gets poisoned, the action is hardly the put the stolen cert i a > CRL. > Assume we have a fairly crappy DNS server, such as the one serving pki2.com (mine and hopefully not crappy :). Start nslookup and point to my server. Tell it to look up information from your custom server (i.e., ask pki2 to lookup www.whatever.com, a zone delegated to you). Have your custom server return the sought information plus information in the extra data segment, such as "www.amazon.com IN A 206.129.5.135". Some servers will cache this extra data without checking it; others, such as BIND 8.x, will discard and log it. Since pki2 in this example is crappy then when I query it for www.amazon.com I am going to go to 206.129.5.135, not Amazon's real web site. In this case we did not poison Amazon's DNS, rather pki2's. If my browser checked for CRLs then it is likely I will see Amazon's certificate had been revoked. On the other hand, if www.amazon.com is spoofed then so can the CRL host address (it's just "extra data"). Then the question becomes what would my browser do if the spoofed CRL host doesn't answer to a CRL request. Not perfect but does raise the bar, IMO. > Shouldn't the action be to cure the DNS? If someone can poison the unsecure DNS, shouldn't the long term > goal be to secure the DNS, rather than letting all users check all servers cert in CRL's all the time? > I am highly skeptical of DNSsec. Assuming we get the roots signed; trusted keys embedded in servers; and TSIG to clients, we have to get all COMs/NETs/whatever to sign their zones and all DNS servers to upgraded. If all these things do not happen, IMO, DNSsec is fairly worthless because you are operating in an untrusted environment. Certainly you can configure your local DNS server as to which zones are DNSsec'd, which is what is done now, but that list will quickly become very long and we might as well go back to FTPing HOSTS.TXT. Received: from angel.algonet.se (angel.algonet.se [194.213.74.112]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA23594 for ; Mon, 14 Aug 2000 12:21:40 -0700 (PDT) Received: (qmail 22597 invoked from network); 14 Aug 2000 21:21:11 +0200 Received: from sinclair.tninet.se (HELO algonet.se) (195.100.94.101) by angel.algonet.se with SMTP; 14 Aug 2000 21:21:11 +0200 Received: from x-obi.com (sdu157-198.ppp.algonet.se [195.163.198.157]) by sinclair.tninet.se (BLUETAIL Mail Robustifier 2.2.1) with ESMTP id 607611.280868.966sinclair-s2 ; Mon, 14 Aug 2000 21:21:08 +0200 Message-ID: <39984756.A83E7C87@x-obi.com> Date: Mon, 14 Aug 2000 21:24:06 +0200 From: Henrik Bergman Reply-To: henrik.bergman@x-obi.com Organization: X-OBI X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: sv,en MIME-Version: 1.0 To: Dennis Glatting CC: juancarlos.perez@acepta.com, ietf-pkix@imc.org, anders.rundgren@telia.com Subject: Re: Client-side revocation checking capability References: <399832D7.44313089@software-munitions.com> Content-Type: multipart/mixed; boundary="------------C80DAA36B6275D04FE1C0472" This is a multi-part message in MIME format. --------------C80DAA36B6275D04FE1C0472 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dennis, The case you are discribing is hardly a good example to show why CRL's are needed for server-certificates. If www.amazon.com uses unsecure DNS and gets poisoned, the action is hardly the put the stolen cert i a CRL. Shouldn't the action be to cure the DNS? If someone can poison the unsecure DNS, shouldn't the long term goal be to secure the DNS, rather than letting all users check all servers cert in CRL's all the time? Henrik Bergman X-OBI To access one uses Dennis Glatting wrote: > Bob Jueneman wrote: > > > > Anders, > > > > There is a lot of practical truth in what you say. > > > > CRL checking certainly seems like a nice thing to do > > cryptographically, until you consider what the threat is that you > > are trying to address. > > > > Let's suppose amazon.com's key were compromised somehow. What > > would happen? Well, the first thing is that they would call up > > their CA and get a new certificate, and then download that > > certificate to any SSL user. So the old certificate and key would > > be completely out of the picture, and hence no CRL would be > > needed, much less OCSP. since they don't use that certificate to > > sign anything other than SSL sessions, which in which the > > certificates are sent in line, they don't even need to revoke > > their old certs -- just stop using them. > > > > The only case where a CRL might be useful in that scenario would > > be in the case of some fly-by-night mafia.com type of store-front, > > where the CA might conceivably revoke the certificate for fraud > > or other cause. However, that would represent a substantial legal > > liability for the CA, and so that doesn't seem terribly likely > > in practice. > > > > Since the retail merchant accounts for the overwhelming use of PKI > > to date (e-mail is just barely beginning to make a dent, and > > everything else are just pilots, it isn't surprising that the > > browsers don't enable CRL checking by default. It would merely add > > lots of delay and processing time. > > > > I disagree. To access www.amazon.com one uses DNS, which is not secure > and often easy to poison. Consequently, mafia.com can redirect some > number of browsers by poisoning some number of DNS servers, present a > Amazon.COM store front, and use Amazon's cert and private key. If the > browser doesn't check for revocation then the consumer is none the > wiser, at least for a while. > > > Bob > > > > >>> "Anders Rundgren" 08/12/00 12:02AM >>> > > Juan Carlos, > > > > That on-line checking of server-certificates is not standard in browsers is probably > > beacuse a revocation is not that likely to happen. In case of a key compromize at the VeriSign > > CA the whole world will be notified and in the case of key compromize in a web-server no > > one will know or be notified. You can steal a web-cert+key from a lousy installation (most are) > > in case you have sys-admin rights. Nothing to do about except tighten up internal security. > > And if the host-name is no longer valid (the company filed for bancruptsy) the > > server will be taken down some day. > > > > IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where > > you may revoke yourself due to loss (of card) or by the company because you got fired. > > > > This is a slightly different answer than you get by asking a typical crypto expert but to my > > knowledge they usually know zilch, nada etc. about practical things that may be 100 times more > > important than the cryptologic solurtion. I.e. as long as there are serious practical problems > > associated with server-certificates, CRLs etc. would basically add nothing (but delays). > > > > Regards > > Anders > > -- > Dennis Glatting > Copyright (c) 2000 Software Munitions -- __________________________________________ Henrik Bergman, X-OBI, mob 070-866 87 72 e-mail: henrik.bergman@x-obi.com --------------C80DAA36B6275D04FE1C0472 Content-Type: text/x-vcard; charset=us-ascii; name="henrik.bergman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Henrik Bergman Content-Disposition: attachment; filename="henrik.bergman.vcf" begin:vcard n:Bergman;Henrik tel;cell:070-866 87 72 x-mozilla-html:FALSE org:X-OBI adr:;;;;;; version:2.1 email;internet:henrik.bergman@x-obi.com x-mozilla-cpt:;24768 fn:Henrik Bergman end:vcard --------------C80DAA36B6275D04FE1C0472-- Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23304 for ; Mon, 14 Aug 2000 12:17:22 -0700 (PDT) Received: from mega (t3o69p11.telia.com [62.20.145.11]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id VAA15310; Mon, 14 Aug 2000 21:16:44 +0200 (CEST) Message-ID: <002601c0062c$6dc07130$0201a8c0@mega.vincent.se> From: "Anders Rundgren" To: "Dennis Glatting" , "Bob Jueneman" Cc: , Subject: Re: Client-side revocation checking capability Date: Mon, 14 Aug 2000 22:15:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA23306 Dennis, >I disagree. To access www.amazon.com one uses DNS, which is not secure >and often easy to poison. Consequently, mafia.com can redirect some >number of browsers by poisoning some number of DNS servers, present a >Amazon.COM store front, and use Amazon's cert and private key. If the >browser doesn't check for revocation then the consumer is none the >wiser, at least for a while. I assume that you refer to the situation where a web-site key is compromized (stolen, copied)? This is very hard to detect if they have low security standards. And if they have high security standards it is unlikely to happen. Since server-based PKI is likely to skyrocket for other purposes than SSL, I believe that it is more important to get cheap hardware-based key-stores with built-in crypto-processing rather than on-line revocation processing, to minimize doubts like "did John copy our server key when he was found in the server-room where he should not be?" To get a new server-certificate is BTW not that trivial so it makes sense to improve local security in various ways. Anders Received: from mail02-ewr.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22891 for ; Mon, 14 Aug 2000 12:10:18 -0700 (PDT) From: Lynn.Wheeler@firstdata.com Received: from mailgw.firstdata.com ([204.48.27.156]) by mail02-ewr.pilot.net with ESMTP id PAA03336; Mon, 14 Aug 2000 15:09:57 -0400 (EDT) Received: from lnsunr02.firstdata.com (localhost [127.0.0.1]) by mailgw.firstdata.com with SMTP id PAA03531; Mon, 14 Aug 2000 15:09:56 -0400 (EDT) Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525693B.0068C730 ; Mon, 14 Aug 2000 15:04:27 -0400 X-Lotus-FromDomain: FDC To: Dennis Glatting cc: Bob Jueneman , juancarlos.perez@acepta.com, ietf-pkix@imc.org, anders.rundgren@telia.com Message-ID: <8525693B.0068C56E.00@lnsunr02.firstdata.com> Date: Mon, 14 Aug 2000 12:08:31 -0700 Subject: Re: Client-side revocation checking capability Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline it goes further than that ... since the "authority" for which domain name certificates are issued is the domain authority .... it is possible to "poisen" that infrastructure (domain name hijacking) ... apply for a certificate ... have it verified as valid by the domain name infrastructure, and have such a certificate certified as valid. there are proposals for improving the infrastructure of the domain name infrastructure with digital signatures and public keys .... which addresses both dynamic poisening as well as domain name hijacking types of poisen. Such a trusted DNS infrastructure then could also return the same public key as part of domain name lookup. At that point, existing certificates become superfulous and redundant. In part, the problem of vulnerable DNS infrastructure is not only the dynamic name lookups but also extends to core DNS infrastructure ... which domain name certificates rely on for validating information that goes into a certificate. Addressing the vulnerabilities of the DNS infrastructure (for both dynamic name lookup as well as certification/validating of certificate information) turns out to also make certificates redundant and superfulous. Dennis Glatting on 08/14/2000 10:56:39 AM To: Bob Jueneman cc: juancarlos.perez@acepta.com, ietf-pkix@imc.org, anders.rundgren@telia.com Subject: Re: Client-side revocation checking capability I disagree. To access www.amazon.com one uses DNS, which is not secure and often easy to poison. Consequently, mafia.com can redirect some number of browsers by poisoning some number of DNS servers, present a Amazon.COM store front, and use Amazon's cert and private key. If the browser doesn't check for revocation then the consumer is none the wiser, at least for a while. > Bob > > >>> "Anders Rundgren" 08/12/00 12:02AM >>> > Juan Carlos, > > That on-line checking of server-certificates is not standard in browsers is probably > beacuse a revocation is not that likely to happen. In case of a key compromize at the VeriSign > CA the whole world will be notified and in the case of key compromize in a web-server no > one will know or be notified. You can steal a web-cert+key from a lousy installation (most are) > in case you have sys-admin rights. Nothing to do about except tighten up internal security. > And if the host-name is no longer valid (the company filed for bancruptsy) the > server will be taken down some day. > > IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where > you may revoke yourself due to loss (of card) or by the company because you got fired. > > This is a slightly different answer than you get by asking a typical crypto expert but to my > knowledge they usually know zilch, nada etc. about practical things that may be 100 times more > important than the cryptologic solurtion. I.e. as long as there are serious practical problems > associated with server-certificates, CRLs etc. would basically add nothing (but delays). > > Regards > Anders -- Dennis Glatting Copyright (c) 2000 Software Munitions Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21551 for ; Mon, 14 Aug 2000 10:57:54 -0700 (PDT) Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.11.0/8.11.0) with ESMTP id e7EHue275864; Mon, 14 Aug 2000 10:56:40 -0700 (PDT) Message-ID: <399832D7.44313089@software-munitions.com> Date: Mon, 14 Aug 2000 10:56:39 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Jueneman CC: juancarlos.perez@acepta.com, ietf-pkix@imc.org, anders.rundgren@telia.com Subject: Re: Client-side revocation checking capability References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob Jueneman wrote: > > Anders, > > There is a lot of practical truth in what you say. > > CRL checking certainly seems like a nice thing to do > cryptographically, until you consider what the threat is that you > are trying to address. > > Let's suppose amazon.com's key were compromised somehow. What > would happen? Well, the first thing is that they would call up > their CA and get a new certificate, and then download that > certificate to any SSL user. So the old certificate and key would > be completely out of the picture, and hence no CRL would be > needed, much less OCSP. since they don't use that certificate to > sign anything other than SSL sessions, which in which the > certificates are sent in line, they don't even need to revoke > their old certs -- just stop using them. > > The only case where a CRL might be useful in that scenario would > be in the case of some fly-by-night mafia.com type of store-front, > where the CA might conceivably revoke the certificate for fraud > or other cause. However, that would represent a substantial legal > liability for the CA, and so that doesn't seem terribly likely > in practice. > > Since the retail merchant accounts for the overwhelming use of PKI > to date (e-mail is just barely beginning to make a dent, and > everything else are just pilots, it isn't surprising that the > browsers don't enable CRL checking by default. It would merely add > lots of delay and processing time. > I disagree. To access www.amazon.com one uses DNS, which is not secure and often easy to poison. Consequently, mafia.com can redirect some number of browsers by poisoning some number of DNS servers, present a Amazon.COM store front, and use Amazon's cert and private key. If the browser doesn't check for revocation then the consumer is none the wiser, at least for a while. > Bob > > >>> "Anders Rundgren" 08/12/00 12:02AM >>> > Juan Carlos, > > That on-line checking of server-certificates is not standard in browsers is probably > beacuse a revocation is not that likely to happen. In case of a key compromize at the VeriSign > CA the whole world will be notified and in the case of key compromize in a web-server no > one will know or be notified. You can steal a web-cert+key from a lousy installation (most are) > in case you have sys-admin rights. Nothing to do about except tighten up internal security. > And if the host-name is no longer valid (the company filed for bancruptsy) the > server will be taken down some day. > > IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where > you may revoke yourself due to loss (of card) or by the company because you got fired. > > This is a slightly different answer than you get by asking a typical crypto expert but to my > knowledge they usually know zilch, nada etc. about practical things that may be 100 times more > important than the cryptologic solurtion. I.e. as long as there are serious practical problems > associated with server-certificates, CRLs etc. would basically add nothing (but delays). > > Regards > Anders -- Dennis Glatting Copyright (c) 2000 Software Munitions Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA20959 for ; Mon, 14 Aug 2000 10:37:52 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 14 Aug 2000 11:36:38 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 14 Aug 2000 11:36:38 -0600 From: "Bob Jueneman" To: , , Subject: Re: Client-side revocation checking capability Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA20960 Anders, There is a lot of practical truth in what you say. CRL checking certainly seems like a nice thing to do cryptographically, until you consider what the threat is that you are trying to address. Let's suppose amazon.com's key were compromised somehow. What would happen? Well, the first thing is that they would call up their CA and get a new certificate, and then download that certificate to any SSL user. So the old certificate and key would be completely out of the picture, and hence no CRL would be needed, much less OCSP. since they don't use that certificate to sign anything other than SSL sessions, which in which the certificates are sent in line, they don't even need to revoke their old certs -- just stop using them. The only case where a CRL might be useful in that scenario would be in the case of some fly-by-night mafia.com type of store-front, where the CA might conceivably revoke the certificate for fraud or other cause. However, that would represent a substantial legal liability for the CA, and so that doesn't seem terribly likely in practice. Since the retail merchant accounts for the overwhelming use of PKI to date (e-mail is just barely beginning to make a dent, and everything else are just pilots, it isn't surprising that the browsers don't enable CRL checking by default. It would merely add lots of delay and processing time. Bob >>> "Anders Rundgren" 08/12/00 12:02AM >>> Juan Carlos, That on-line checking of server-certificates is not standard in browsers is probably beacuse a revocation is not that likely to happen. In case of a key compromize at the VeriSign CA the whole world will be notified and in the case of key compromize in a web-server no one will know or be notified. You can steal a web-cert+key from a lousy installation (most are) in case you have sys-admin rights. Nothing to do about except tighten up internal security. And if the host-name is no longer valid (the company filed for bancruptsy) the server will be taken down some day. IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where you may revoke yourself due to loss (of card) or by the company because you got fired. This is a slightly different answer than you get by asking a typical crypto expert but to my knowledge they usually know zilch, nada etc. about practical things that may be 100 times more important than the cryptologic solurtion. I.e. as long as there are serious practical problems associated with server-certificates, CRLs etc. would basically add nothing (but delays). Regards Anders Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13109 for ; Mon, 14 Aug 2000 08:05:32 -0700 (PDT) Received: from kant [129.27.152.76] by iaik.tu-graz.ac.at (SMTPD32-6.00) id AAA337E0090; Mon, 14 Aug 2000 17:05:07 +0200 Message-ID: <002801c00601$05b4c1c0$4c981b81@iaik.tugraz.ac.at> From: "Christian Vogel" To: Subject: Time Stamp Protocol implementation Date: Mon, 14 Aug 2000 17:05:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA13110 I have implemented the Time Stamp Protocol . I would be pleased to test my implementation against other implementations. I will run a TCP/IP time stamping server on the IP address 129.27.142.232 port 318 The time stamp is still very inaccurate, since the automatic time correction of the server doesn't work until now but in a few days. The server does not accept any PolicyInformation and no Extensions (but you can try it). The accuracy was adjusted to 3600.111999 seconds;-) I am grateful for each note. Thanks Christian Vogel -- Christian Vogel office: [cvogel@iaik.at] [http://jcewww.iaik.tu-graz.ac.at] private: [bird@sbox.tu-graz.ac.at] [http://www.sbox.tu-graz.ac.at/home/b/bird] Received: from picard.noroff.no ([212.20.204.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11892 for ; Mon, 14 Aug 2000 07:15:13 -0700 (PDT) Received: by picard.noroff.no (Postfix, from userid 815) id D89D62201F; Mon, 14 Aug 2000 16:59:32 +0200 (CEST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by picard.noroff.no (Postfix) with ESMTP id 2719DB3802 for ; Mon, 14 Aug 2000 16:59:27 +0200 (CEST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA19907 for ietf-123-outbound.09@ietf.org; Mon, 14 Aug 2000 09:25:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA18755 for ; Mon, 14 Aug 2000 07:02:10 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03351; Mon, 14 Aug 2000 07:02:10 -0400 (EDT) Message-Id: <200008141102.HAA03351@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-pi-01.txt Date: Mon, 14 Aug 2000 07:02:10 -0400 Sender: nsyracus@cnri.reston.va.us X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Permanent Identifier Author(s) : D. Pinkas, T. Gindin Filename : draft-ietf-pkix-pi-01.txt Pages : 9 Date : 11-Aug-00 This document define a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to a physical person. The permanent identifier is an optional feature that may be used by a CA to indicate that the certificate relates to the same individual even if the name of that individual has changed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-pi-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-pi-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000811100400.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-pi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-pi-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000811100400.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from exchng-fairfax.pec.com (exchng-fairfax.pec.com [204.254.216.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10260 for ; Mon, 14 Aug 2000 05:50:16 -0700 (PDT) Received: by EXCHNG-FAIRFAX with Internet Mail Service (5.5.2650.21) id ; Mon, 14 Aug 2000 08:51:24 -0400 Message-ID: <5023FFCA43D8D311A8360008C7F450FDABFE3F@EXCHNG-FAIRFAX> From: GMurphy To: "'ietf-pkix@imc.org'" Subject: Date: Mon, 14 Aug 2000 08:51:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C005EE.59E77760" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C005EE.59E77760 Content-Type: text/plain unsubscribe ------_=_NextPart_001_01C005EE.59E77760 Content-Type: text/html

unsubscribe

------_=_NextPart_001_01C005EE.59E77760-- Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA08780 for ; Mon, 14 Aug 2000 04:02:31 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03351; Mon, 14 Aug 2000 07:02:10 -0400 (EDT) Message-Id: <200008141102.HAA03351@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-pi-01.txt Date: Mon, 14 Aug 2000 07:02:10 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Permanent Identifier Author(s) : D. Pinkas, T. Gindin Filename : draft-ietf-pkix-pi-01.txt Pages : 9 Date : 11-Aug-00 This document define a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to a physical person. The permanent identifier is an optional feature that may be used by a CA to indicate that the certificate relates to the same individual even if the name of that individual has changed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-pi-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-pi-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000811100400.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-pi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-pi-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000811100400.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA01939 for ; Mon, 14 Aug 2000 00:16:03 -0700 (PDT) Received: from sigma (sigma.initech.com [203.238.37.133]) by venus.initech.com (8.9.3/8.9.3) with SMTP id QAA26818 for ; Mon, 14 Aug 2000 16:12:47 +0900 (KST) Reply-To: From: "Kwon, YongChul" To: Subject: PKIFailureInfo in RFC-2510 Date: Mon, 14 Aug 2000 16:13:37 +0900 Message-ID: <005901c005bf$2ae02940$8525eecb@initech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="EUC-KR" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal I have a question in PKIFailureInfo in RFC-2510 the PKIFailureInfo type is defined in 2510 like this. PKIFailureInfo ::= BIT STRING { badAlg (0), badMessageCheck (1), badRequest (2), ... } the value (0), (1), (2)... means just INTEGER value? or n-th bit is on? if it just means INTEGER, I wonder why its type is defined as BIT STRING rather than INTEGER. :-( --------------- Kwon, YongChul(godslord@initech.com) Institute of Researching Security Technology of Initiative Technology, Inc. Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA09677 for ; Fri, 11 Aug 2000 23:05:03 -0700 (PDT) Received: from m3.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0006-Fujitsu Gateway) id PAA01942 for ; Sat, 12 Aug 2000 15:03:51 +0900 (JST) (envelope-from takiguti@fjh.se.fujitsu.co.jp) Received: from nic10.fjh.se.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.9.3/3.7W-0008-Fujitsu Domain Master) id PAA23810; Sat, 12 Aug 2000 15:03:50 +0900 (JST) Received: from anakin (anakin.fjh.se.fujitsu.co.jp [10.131.201.130]) by nic10.fjh.se.fujitsu.co.jp (8.9.3+3.2W/3.7W) with ESMTP id PAA28203 for ; Sat, 12 Aug 2000 15:03:49 +0900 (JST) Date: Sat, 12 Aug 2000 15:03:49 +0900 From: TAKIGUCHI Naruhito To: ietf-pkix@imc.org Subject: Re: CRL number in CRL and ARL In-Reply-To: References: Message-Id: <20000812145530.5F39.TAKIGUTI@fjh.se.fujitsu.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00 (beta 25) Ambarish, Sharon, Thank you very much. I could understand clearly about the numbering of CRL. > An additional point on the numbering of CRLs. In the 2000 edition of > X.509, additional flexibility for CRLs was added. For example, a status > referrals extension can indicate that an authority has changed its > partitioning scheme, indirect delta CRL streams were added etc. To help > reduce confusion over the CRL numbering, the new cRLStreamIdentifier > extension was added. This new extension basically identifies a context > (e.g. full crls, CRL DPs, delta for a given CRLDP,indirect delta for a > given scope, etc) within which the cRLNumber must be unique. This > is defined in 8.5.2.7 of the 2000 text of 509: > > ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/ > > Sharon > > > -----Original Message----- > > From: Ambarish Malpani [mailto:ambarish@valicert.com] > > Sent: Thursday, August 10, 2000 7:33 PM > > To: 'TAKIGUCHI Naruhito'; ietf-pkix@imc.org > > Subject: RE: CRL number in CRL and ARL > > > > > > > > That is perfectly legal. > > > > Regards, > > Ambarish > > > > --------------------------------------------------------------------- > > Ambarish Malpani > > Architect 650.567.5457 > > ValiCert, Inc. ambarish@valicert.com > > 339 N. Bernardo Ave. http://www.valicert.com > > Mountain View, CA 94043 > > > > > > > -----Original Message----- > > > From: TAKIGUCHI Naruhito [mailto:takiguti@fjh.se.fujitsu.co.jp] > > > Sent: Thursday, August 10, 2000 4:52 AM > > > To: ietf-pkix@imc.org > > > Subject: Re: CRL number in CRL and ARL > > > > > > > > > Ambarish, > > > > > > > If you are using CRLDPs, the numbering for each DP is independent. > > > > > > > > It is okay to number them in the following way: > > > > > > > > Time DP1 DP2 > > > > 1 10 5 > > > > 2 12 17 > > > > 3 15 18 > > > > 4 99 201 > > > > 5 202 202 > > > > > > > > Or any other interesting scheme you would prefer, as long as > > > > the numbers for DP1 are monotonically increasing and the > > > > numbers for DP2 are monotoncally increasing. > > > > > > > > Note: This example is *not* meant to imply that you even need to > > > > issue both DPs at all the times specified. > > > > > > Thank you very much. > > > I see that the CRL number is a monotonically increasing > > > number for each CRL scope. > > > > > > But, in your example, the CRL number is not a sequence number. > > > Is this right? > > > > > > ----- > > > Naruhito TAKIGUCHI > > > FUJITSU HOKURIKU SYSTEMS LTD. > > > > > > > > ----- Naruhito TAKIGUCHI FUJITSU HOKURIKU SYSTEMS LTD. Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA05615 for ; Fri, 11 Aug 2000 22:03:55 -0700 (PDT) Received: from mega (t5o69p73.telia.com [213.64.110.73]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id HAA29863; Sat, 12 Aug 2000 07:03:07 +0200 (CEST) Message-ID: <002201c00422$d9da85b0$0201a8c0@mega.vincent.se> From: "Anders Rundgren" To: , "'Ietf-Pkix" Subject: Re: Client-side revocation checking capability Date: Sat, 12 Aug 2000 08:02:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA05617 Juan Carlos, That on-line checking of server-certificates is not standard in browsers is probably beacuse a revocation is not that likely to happen. In case of a key compromize at the VeriSign CA the whole world will be notified and in the case of key compromize in a web-server no one will know or be notified. You can steal a web-cert+key from a lousy installation (most are) in case you have sys-admin rights. Nothing to do about except tighten up internal security. And if the host-name is no longer valid (the company filed for bancruptsy) the server will be taken down some day. IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where you may revoke yourself due to loss (of card) or by the company because you got fired. This is a slightly different answer than you get by asking a typical crypto expert but to my knowledge they usually know zilch, nada etc. about practical things that may be 100 times more important than the cryptologic solurtion. I.e. as long as there are serious practical problems associated with server-certificates, CRLs etc. would basically add nothing (but delays). Regards Anders Received: from nxs_vyr_dns.sie.cl ([206.48.156.90]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA13998 for ; Fri, 11 Aug 2000 15:11:38 -0700 (PDT) Received: from jperez ([192.168.4.178]) by nxs_vyr_dns.sie.cl (8.9.3/8.9.3) with SMTP id SAA05524; Fri, 11 Aug 2000 18:15:48 -0400 Reply-To: From: =?iso-8859-1?Q?Juan_Carlos_P=E9rez_Aguayo?= To: "'Ietf-Pkix" , Subject: RE: Client-side revocation checking capability Date: Fri, 11 Aug 2000 18:09:59 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Ambarish: I have been the "magic extensions" in Netscape and I belive that's ok, but only Netscape Server does those checking... If clients applications don't have native on-line checking support, then the options like the check-box in the Advanced\Options\Security in IE5.x, when say "Chek for publisher's certificate revocation" and "Chek for server certificate revocation" does not do anything at all , Ok ? I think that only check if a server certificate, on a SSL connection, belong to the "trusted certificate store" defined for IE. Those type of messages seem communicate erroneus propose... Regards Juan Carlos > -----Original Message----- >De: "Ambarish Malpani" >Para: ; ; "''Ietf-Pkix'" >Asunto: RE: Client-side revocation checking capability >Fecha: Jueves, 10 de Agosto de 2000 19:46 >Hi Juan, > I agree with Jeff that most client applications don't do >revocation checking. To the best of my belief, some of the 3.0 >versions of Netscape Navigator etc. could do CRL checking if the >cert had some magic extensions in them. > >Communicator 4.7, with the PSM module does a pretty reasonable >job of revocation checking with OCSP. We (ValiCert) do have >a plugin for both IE 5.0 and Outlook that can also enable those >applications to do revocation checking with OCSP. > >We also have plugins for Netscape Enterprise Server and IIS, but >you don't seem to be interested in servers from your mail. > >Regards, >Ambarish > > >--------------------------------------------------------------------- >Ambarish Malpani >Architect 650.567.5457 >ValiCert, Inc. ambarish@valicert.com >339 N. Bernardo Ave. http://www.valicert.com >Mountain View, CA 94043 > -----Original Message----- > From: Jeff Spinney [mailto:spinneyj@flashcom.net] > Sent: Thursday, August 10, 2000 3:05 PM > To: juancarlos.perez@acepta.com; ''Ietf-Pkix' > Subject: RE: Client-side revocation checking capability > > > OCSP server vendors such as CertCo (www.certco.com) or Valicert > (www.valicert.com) have toolkits with which you can OCSP 'enable' an > application. This is great for application vendors who wish > to make their > apps more robust and certificate enabled. Most applications > at this point in > the game are not OCSP enabled even if they can deal with > certificates, they > do the basic crypto checking *if* they have the issuer cert > on hand, but do > not do real time status checking to see whether or not the > cert has been > revoked since it was issued. > > in that regard, it seems as though the application > market needs to be > persuaded to make their software support real time certificate status > checking. > > > As for Netscape, they do have an OCSP client for their > browser. I am unsure > if it is publically available at this time. It loads into the > security area, > under 'advanced' and gives you the option to specify an OCSP > responder. In > my experiance, and it was in the early stages of this modules > lifetime, it > was very finicky. If i remember correctly, it wanted the > OCSP response to > be sgned by the same cert that signed the cert being checked. > This may not > always be the case. > > > -j > > > > -----Original Message----- > From: Juan Carlos Pérez Aguayo [mailto:juancarlos.perez@acepta.com] > Sent: Thursday, August 10, 2000 12:36 PM > To: 'Ietf-Pkix > Subject: Client-side revocation checking capability > > > I am in trouble about this: What is the real support that have the > client-side software for certificate revocation checking now? > i.e. (Internet > Explorer, Netscape, etc.) > > I heard that, in fact, client-applications don`t do any > revocation checking > at all? It's that truly? > > What is the real capability of those client applications this time? > > By example, I know that Netscape define some certificate > extensions for > managing revocation, but I am not sure if realy work > > Can anyone give me some help? > > Thanks you > > > > Juan Carlos Pérez Aguayo > Software Engineer > Acepta.com > juancarlos.perez@acepta.com > > Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA12879 for ; Fri, 11 Aug 2000 14:18:25 -0700 (PDT) From: Lynn.Wheeler@firstdata.com Received: from mailgw.firstdata.com ([204.48.27.156]) by mail01-ewr.pilot.net with ESMTP id RAA23532; Fri, 11 Aug 2000 17:17:52 -0400 (EDT) Received: from lnsunr02.firstdata.com (localhost [127.0.0.1]) by mailgw.firstdata.com with SMTP id RAA02591; Fri, 11 Aug 2000 17:17:51 -0400 (EDT) Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256938.007463EA ; Fri, 11 Aug 2000 17:11:17 -0400 X-Lotus-FromDomain: FDC To: kelm@secorvo.de cc: "'ietf-pkix@imc.org'" Message-ID: <85256938.007461E6.00@lnsunr02.firstdata.com> Date: Fri, 11 Aug 2000 14:06:39 -0700 Subject: STANDARDS WHICH SUPPORT DIGITAL SIGNATURES AVAILABLE Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=PuERWxyshKgIejOeIJKeAOqBsWgZ1j9rTIhS1rDD9bLDWgkZmA55tjH3" Content-Disposition: inline --0__=PuERWxyshKgIejOeIJKeAOqBsWgZ1j9rTIhS1rDD9bLDWgkZmA55tjH3 Content-type: text/plain; charset=us-ascii Content-Disposition: inline possibly of some interest ... ---------------------- Forwarded by Lynn Wheeler/CA/FDMS/FDC on 08/11/2000 12:38 PM --------------------------- dbarnes@aba.com on 08/10/2000 08:51:10 AM To: Distribution@www.Autometricweb.COM Subject: STANDARDS WHICH SUPPORT DIGITAL SIGNATURES AVAILABLE http://www.x9.org/altavista/x9/dispatch.cgi/_T_X9F_docshare/showFolder/100119C ONTACT: John Hall (202) 663-5473 STANDARDS WHICH SUPPORT DIGITAL SIGNATURES AVAILABLE WASHINGTON, Aug. 10 -- Standards for adopting digital signatures -- the latest financial tool for validating e-commerce transactions -- are availaable through the Accredited Standards Committee X9, the national standards setting body for the financial services industry. ASC X9 is accredited by the American National Standards Institute (ANSI). These standards are the cornerstone for the new federal law governing digital signatures, which goes into effect in October of this year. Assuring wide usage, the ASC X9 digital signature standards listed below have all been adopted in the Federal Information Processing Standard (FIPS) FIPS 186-2, Digital Signature Standard (DSS), as the only signature algorithms approved for use by the U.S. government. ASC X9 and the National Institute for Standards and Technology (NIST), an agency of the federal government, are developing procedures for testing and validating products designed to use these standards. Once established, institutions will be able to purchase products validated by a laboratory accredited by both the U.S. and Canadian governments. The standards define procedures for generating, verifying and securing digital signatures. They include: Public Key Cryptography Using Irreversible Algorithms (X9.30-1), Part 1: The Digital Signature Algorithm (DSA). This standard defines a method for digital signature generation and verification of financial messages and data using the DSA. In addition, the standard provides criteria for generation of public and private keys required by DSA and the procedural controls needed for the secure use of the algorithm. Public Key Cryptography Using Irreversible Algorithms (X9.30-2), Part 2: The Secure Hash Algorithm (SHA-1). This standard defines a technique for computing a shortened representation of a message digest, which is computed during the digital signature generation and verification process. Any subsequent change to the message will, with a very high probability, result in a different message digest, and the signature will fail to verify. Digital Signatures Using Reversible Public Key Cryptography for the Financial Services Industry (X9.31) This standard defines a method for digital signature generation and verification to protect financial messages and data using reversible public key cryptography systems with message recovery. The standard also provides the criteria for the generation of public and private keys required by the algorithm and the procedural controls required for algorithm security. The standard guards against more modern factoring attacks such as the Elliptic Curve Method, the Quadratic Sieve and the Number Field Sieve by requiring that the key be sufficiently large to make attacks infeasible. Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA) (X9.62) This standard defines methods for digital signature generation and verification for the protection of messages and data using the ECDSA. ECDSA is the elliptic curve analogue of the Digital Signature Algorithm (DSA). In addition, this ECDSA standard provides the criteria for the generation of public and private keys that are required by the algorithm and the procedural controls required for the secure use of the algorithm. Priced from $40 - $80 each, they are available electronically at the ASC X9 Web site's Electronic Standards Store (ESS) at www.x9.org or through the ANSI Web store at www.ansi.org. To order hard copies of these standards and more, call Global Engineering Documents at 1-800-854-7179. For more information about ASC X9 or its committees, contact Cynthia Fuller, managing director, at (202) 663-5284 Accredited Standards Committee X9 is the only industry-wide forum that brings together bankers, securities professionals, manufacturers, regulators, associations, consultants and others in the financial services arena to address technical problems, find the best solutions and codify them as nationally accepted standards. The American National Standards Institute (ANSI) accredited ASC X9 in 1984. The American Bankers Association serves as ASC X9 secretariat, providing administrative support. The ABA brings together all categories of banking institutions to best represent the interests of this rapidly changing industry. Its membership --0__=PuERWxyshKgIejOeIJKeAOqBsWgZ1j9rTIhS1rDD9bLDWgkZmA55tjH3 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable =F9 which includes community, regional and money center banks and holding companies, as we= ll as savings associations, trust companies and savings banks makes ABA the l= argest banking trade association in the country. ABA can be found on the Inter= net at www.aba.com. # # # Hector Cruz ABA, Public Relations hcruz@aba.com (202) 663-5315 Forum: X9F - Data & Information Security Discussions and Documents Entry: STANDARDS WHICH SUPPORT DIGITAL SIGNATURES AVAILABLE From: David Barnes Date: 08/10/00 09:46 AM = --0__=PuERWxyshKgIejOeIJKeAOqBsWgZ1j9rTIhS1rDD9bLDWgkZmA55tjH3-- Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA12534 for ; Fri, 11 Aug 2000 14:09:34 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <39939CCD.35D95A82@penta3.es> References: <39939CCD.35D95A82@penta3.es> Date: Fri, 11 Aug 2000 14:09:00 -0700 To: ietf-pkix@imc.org From: Paul Hoffman / IMC Subject: Re: Unsuscribe Content-Type: text/plain; charset="us-ascii" ; format="flowed" To everyone who is trying to unsubscribe: Send a message to ietf-pkix-request@imc.org, with the single word "unsubscribe" in the body of the message. (Yes, this is identical to the instructions that you received when you subscribed to the mailing list...) If you have problems, send a message to me. Please do not send messages to the whole mailing list. It is a waste of everyone's time to read your request, and it does not get you unsubscribed from the list. --Paul Hoffman, Director --Internet Mail Consortium Received: from wafw.bear.com (wafw.bear.com [207.162.228.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18548 for ; Fri, 11 Aug 2000 07:23:44 -0700 (PDT) Received: from bear.com (localhost [127.0.0.1]) by wafw.bear.com (8.9.3/8.9.2) with SMTP id KAA24045 for ; Fri, 11 Aug 2000 10:19:01 -0400 (EDT) Received: from 147.107.147.19 by whmsxvs1.is.bear.com (InterScan E-Mail VirusWall NT); Fri, 11 Aug 2000 10:13:36 -0400 (Eastern Daylight Time) Received: by whmsx2.is.bear.com with Internet Mail Service (5.5.2448.0) id ; Fri, 11 Aug 2000 10:17:41 -0400 Message-ID: <991708270E97D211998300A0C99B237602EA24E6@whmsx19.is.bear.com> From: "Luo, Feng (Exchange)" To: "'ietf-pkix@imc.org'" Subject: Date: Fri, 11 Aug 2000 10:17:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Unsubscribe *********************************************************************** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *********************************************************************** Received: from picard.noroff.no ([212.20.204.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16861 for ; Fri, 11 Aug 2000 06:57:27 -0700 (PDT) Received: by picard.noroff.no (Postfix, from userid 815) id AA13C22002; Fri, 11 Aug 2000 16:41:11 +0200 (CEST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by picard.noroff.no (Postfix) with ESMTP id 048E7B3802 for ; Fri, 11 Aug 2000 16:41:09 +0200 (CEST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA11354 for ietf-123-outbound.09@ietf.org; Fri, 11 Aug 2000 09:15:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA10097 for ; Fri, 11 Aug 2000 07:01:55 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08870; Fri, 11 Aug 2000 07:01:55 -0400 (EDT) Message-Id: <200008111101.HAA08870@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ac509prof-05.txt Date: Fri, 11 Aug 2000 07:01:54 -0400 Sender: nsyracus@cnri.reston.va.us X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : An Internet Attribute Certificate Profile for Authorization Author(s) : S. Farrell, R. Housley Filename : draft-ietf-pkix-ac509prof-05.txt Pages : 37 Date : 10-Aug-00 This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ac509prof-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ac509prof-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000810140212.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ac509prof-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ac509prof-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000810140212.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from issmr5003.arthurandersen.com (ISSMR5003.awo.com [170.253.236.71]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15575 for ; Fri, 11 Aug 2000 06:37:42 -0700 (PDT) From: robert.c.boutell@us.arthurandersen.com Received: from us.arthurandersen.com (AMRHM3999.arthurandersen.com [10.0.60.29]) by issmr5003.arthurandersen.com (8.9.3/8.9.3) with SMTP id IAA23474 for ; Fri, 11 Aug 2000 08:25:09 -0500 (CDT) Received: by us.arthurandersen.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999)) id 06256938.00502CD9 ; Fri, 11 Aug 2000 08:35:43 -0600 X-Lotus-FromDomain: ANDERSEN WO To: ietf-pkix@imc.org Message-ID: <06256938.005026AA.00@us.arthurandersen.com> Date: Fri, 11 Aug 2000 08:32:22 -0600 Subject: Unsubscribe Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Unsubscribe *******************Internet Email Confidentiality Footer******************* Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it. Received: from web109.yahoomail.com (web109.yahoomail.com [205.180.60.76]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA14923 for ; Fri, 11 Aug 2000 06:10:06 -0700 (PDT) Received: (qmail 5577 invoked by uid 60001); 11 Aug 2000 13:09:31 -0000 Message-ID: <20000811130931.5576.qmail@web109.yahoomail.com> Received: from [216.62.218.132] by web109.yahoomail.com; Fri, 11 Aug 2000 06:09:31 PDT Date: Fri, 11 Aug 2000 06:09:31 -0700 (PDT) From: Jarred Stover Subject: Unsubscribe To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii ===== "Consistency is the Hobgoblin of little minds." -Emerson __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14524 for ; Fri, 11 Aug 2000 06:00:46 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Fri, 11 Aug 2000 08:59:40 -0400 Message-ID: From: Sharon Boeyen To: "'Ambarish Malpani'" , "'TAKIGUCHI Naruhito'" , ietf-pkix@imc.org Subject: RE: CRL number in CRL and ARL Date: Fri, 11 Aug 2000 08:56:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" An additional point on the numbering of CRLs. In the 2000 edition of X.509, additional flexibility for CRLs was added. For example, a status referrals extension can indicate that an authority has changed its partitioning scheme, indirect delta CRL streams were added etc. To help reduce confusion over the CRL numbering, the new cRLStreamIdentifier extension was added. This new extension basically identifies a context (e.g. full crls, CRL DPs, delta for a given CRLDP,indirect delta for a given scope, etc) within which the cRLNumber must be unique. This is defined in 8.5.2.7 of the 2000 text of 509: ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/ Sharon > -----Original Message----- > From: Ambarish Malpani [mailto:ambarish@valicert.com] > Sent: Thursday, August 10, 2000 7:33 PM > To: 'TAKIGUCHI Naruhito'; ietf-pkix@imc.org > Subject: RE: CRL number in CRL and ARL > > > > That is perfectly legal. > > Regards, > Ambarish > > --------------------------------------------------------------------- > Ambarish Malpani > Architect 650.567.5457 > ValiCert, Inc. ambarish@valicert.com > 339 N. Bernardo Ave. http://www.valicert.com > Mountain View, CA 94043 > > > > -----Original Message----- > > From: TAKIGUCHI Naruhito [mailto:takiguti@fjh.se.fujitsu.co.jp] > > Sent: Thursday, August 10, 2000 4:52 AM > > To: ietf-pkix@imc.org > > Subject: Re: CRL number in CRL and ARL > > > > > > Ambarish, > > > > > If you are using CRLDPs, the numbering for each DP is independent. > > > > > > It is okay to number them in the following way: > > > > > > Time DP1 DP2 > > > 1 10 5 > > > 2 12 17 > > > 3 15 18 > > > 4 99 201 > > > 5 202 202 > > > > > > Or any other interesting scheme you would prefer, as long as > > > the numbers for DP1 are monotonically increasing and the > > > numbers for DP2 are monotoncally increasing. > > > > > > Note: This example is *not* meant to imply that you even need to > > > issue both DPs at all the times specified. > > > > Thank you very much. > > I see that the CRL number is a monotonically increasing > > number for each CRL scope. > > > > But, in your example, the CRL number is not a sequence number. > > Is this right? > > > > ----- > > Naruhito TAKIGUCHI > > FUJITSU HOKURIKU SYSTEMS LTD. > > > > > Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA12317 for ; Fri, 11 Aug 2000 05:30:44 -0700 (PDT) Received: from jade.hut.fi (jei@jade.hut.fi [130.233.249.69]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id PAA23398 for ; Fri, 11 Aug 2000 15:30:08 +0300 (EET DST) Date: Fri, 11 Aug 2000 15:30:06 +0300 (EET DST) From: Jukka E Isosaari Reply-To: Jukka.Isosaari@hut.fi To: ietf-pkix@imc.org Subject: Startup looking for PKI & XML experts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Please excuse if this is out of topic. // Jukka ---------- Forwarded message ---------- Startup looking for PKI and XML developers CRF Box is a technology start-up aiming at shortening pharmaceutical R&D time and improving the quality of clinical data collected in clinical studies. This is achieved via CRF Box transaction and information platform, which provides enhanced physician connectivity through the Internet towards physicians who participate in the clinical study. At the emerging global market, we aim at being among the top suppliers in two year CRF Box benefits pharmaceutical and biotech companies as well as physicians who are able to perform their professional duties more efficiently. CRF Box is currently developing the first release of its product in partnership with a global pharmaceutical company. The development is to be finalized and product piloted in Finland during fall 2000, after which international roll-out will commence. CRF Box operations are currently privately funded, and the company office is located in Helsinki, Finland. At the moment, CRF Box product is being developed by seventeen professionals. By the end of this year, we expect to have 30 people. Part of them will be working in our Boston office. CRF Box is continuously looking for new talent to share and execute the company vision of providing a de-facto standard transaction platform for global pharmaceutical and biotech in dustries. The company culture of CRF Box relies on openness of communication and freedom with respect to the choice and scope of individual tasks. A personal compensation package is tailored to meet your needs and to incentivize individual performance according to your preferences. As a rapidly growing company, different skills are valued. The things that we especially look for are the ability to bring ideas in to reality, and the tendency to have an opinion. Knowledge and experience in PKI programming area is appreciated, in specific. For more information, please visit: http://www.crfbox.com or contact directly by email: recruiting@crfbox.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA07504 for ; Fri, 11 Aug 2000 04:02:31 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08870; Fri, 11 Aug 2000 07:01:55 -0400 (EDT) Message-Id: <200008111101.HAA08870@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ac509prof-05.txt Date: Fri, 11 Aug 2000 07:01:54 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : An Internet Attribute Certificate Profile for Authorization Author(s) : S. Farrell, R. Housley Filename : draft-ietf-pkix-ac509prof-05.txt Pages : 37 Date : 10-Aug-00 This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ac509prof-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ac509prof-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000810140212.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ac509prof-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ac509prof-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000810140212.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from acme.penta3.es ([195.171.34.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01885 for ; Fri, 11 Aug 2000 02:54:27 -0700 (PDT) Received: from penta3.es (mazingerdmz.penta3.es [212.163.11.195]) by acme.penta3.es (8.9.3/8.9.3) with ESMTP id LAA24451 for ; Fri, 11 Aug 2000 11:51:19 +0200 Message-ID: <3993CE6C.59991CC7@penta3.es> Date: Fri, 11 Aug 2000 11:59:08 +0200 From: Javier Torres Seco de Herrera X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-pkix@imc.org" Subject: Unsuscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA28472 for ; Fri, 11 Aug 2000 02:10:04 -0700 (PDT) Received: by balinese.baltimore.ie; id KAA21979; Fri, 11 Aug 2000 10:09:26 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma021892; Fri, 11 Aug 00 10:08:49 +0100 Received: from dna (dna.ie.baltimore.com [192.168.21.111]) by bobcat.baltimore.ie (8.9.3/8.9.3) with SMTP id KAA04409 for ; Fri, 11 Aug 2000 10:08:49 +0100 Reply-To: From: "Dave Dineen" To: Subject: Unsuscribe Date: Fri, 11 Aug 2000 10:10:44 +0100 Message-ID: <005a01c00374$083059d0$6f15a8c0@dna.baltimore.ie> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Received: from acme.penta3.es ([195.171.34.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA20081 for ; Thu, 10 Aug 2000 23:22:55 -0700 (PDT) Received: from penta3.es (mazingerdmz.penta3.es [212.163.11.195]) by acme.penta3.es (8.9.3/8.9.3) with ESMTP id IAA22598 for ; Fri, 11 Aug 2000 08:19:47 +0200 Message-ID: <39939CCD.35D95A82@penta3.es> Date: Fri, 11 Aug 2000 08:27:26 +0200 From: Javier Torres Seco de Herrera X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-pkix@imc.org" Subject: Unsuscribe Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msA41F226F0ED820E39A6C1103" This is a cryptographically signed message in MIME format. --------------msA41F226F0ED820E39A6C1103 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Unsuscribe --------------msA41F226F0ED820E39A6C1103 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIJoAYJKoZIhvcNAQcCoIIJkTCCCY0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B5EwggKEMIIB76ADAgECAgEkMAsGCSqGSIb3DQEBBDB4MQ8wDQYDVQQIFAZNYWRyaWQxDzAN BgNVBAcUBk1hZHJpZDEMMAoGA1UEAxQDU1RBMRMwEQYDVQQLFApEZW1vIFNJQk9TMSQwIgYD VQQKFBtHbG9iYWwgVHJ1c3QgQXV0aG9yaXR5KEdUQSkxCzAJBgNVBAYUAkVTMB4XDTAwMDgx MDEzMjYwMFoXDTAxMDcyNjAxMDAwMFowgZsxDzANBgNVBAgUBk1hZHJpZDEPMA0GA1UECxQG Q3J5cHRvMQ8wDQYDVQQKFAZQRU5UQTMxDzANBgNVBAcUBk1hZHJpZDEgMB4GCSqGSIb3DQEJ ARYRanRvcnJlc0BwZW50YTMuZXMxJjAkBgNVBAMUHUphdmllciBUb3JyZXMgU2VjbyBkZSBI ZXJyZXJhMQswCQYDVQQGFAJFUzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvURDBi7c gjNAQcKBOQWunKWfivGGCuQc6O0qW9O/YuJiqEdBDdbBQG9mDw1UUlEk1mThxKAz1oYDtF8K EmOU/88Xj0usxFzrgTUEP27ro320RWvRKvkwlyp4BoNBUiNupyhVFZCE7+H+lgpa4p+0iJWR FxSSdgojkju54zCmLzMCAwEAATALBgkqhkiG9w0BAQQDgYEAJZJOwEKuV63pOdwpo4rmkqde 16a/o1V/VR9aPHPPhZKOvktpMKxY+Uz5EcZA0nZ5CXEvbuceKtDaH/j/i20mXeBYvsWhie1P d6Ccw9E7xzJlNUP6yfEFPkinHEhhTpL6aoW9oXL6iRvVk54ZkoNpbMyVfaA8yohHGrbOqdxv ow4wggKQMIIB+6ADAgECAgEEMAsGCSqGSIb3DQEBBDBuMQ8wDQYDVQQIFAZNYWRyaWQxDzAN BgNVBAcUBk1hZHJpZDEMMAoGA1UEAxQDTVRBMQ4wDAYDVQQLFAVTSUJPUzEfMB0GA1UEChQW R2xvYmFsIFRydXN0IEF1dGhvcml0eTELMAkGA1UEBhQCRVMwHhcNMDAwNzMxMTE0NTAwWhcN MDEwNzIxMDEwMDAwWjB4MQ8wDQYDVQQIFAZNYWRyaWQxDzANBgNVBAcUBk1hZHJpZDEMMAoG A1UEAxQDU1RBMRMwEQYDVQQLFApEZW1vIFNJQk9TMSQwIgYDVQQKFBtHbG9iYWwgVHJ1c3Qg QXV0aG9yaXR5KEdUQSkxCzAJBgNVBAYUAkVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQC1c9Z3Ez08hWowDuAUWUhwBy92bHjmO1oRJzxkPpgDkJWKn9Q3pJtADUIs5JjjpASi8Yn7 bpaVqEzl/GV1krvt+pFFVgYbLzIpfYJaakh+opcnSRR9N3qY+mfJZ850Qlu6U5W6vYlPM3UR C6qzEWnBhZj8xHk1+d9TQzeCUGhYDQIDAQABozgwNjALBgNVHQ8EBAMCAZIwJwYDVR0lBCAw HgYIKwYBBQUHAwQGCCsGAQUFBwMCBggrBgEFBQcDATALBgkqhkiG9w0BAQQDgYEAeIRNqAJP GJfmqnexemupqxTVRGGp+vTWjResGHq41qUUiA2CC0WHoalW4HCjcPdIR1zngV+YUbENb888 Ooyg/IlSdQ6bX7YWXSS5NwCk6d4H6nAu8XTFRyRO/WsHu2CkBlUkfayEoK7tnhbW7dwYHyV2 vNVHWsUgVzUFnjhL+XEwggJxMIIB3KADAgECAgEFMA0GCSqGSIb3DQEBBAUAMIGQMQ8wDQYD VQQIFAZNYWRyaWQxDzANBgNVBAcUBk1hZHJpZDERMA8GA1UEAxQIR1RBIFJvb3QxJTAjBgNV BAsUHEdsb2JhbCBUcnVzdCBBdXRob3JpdHkgKEdUQSkxJTAjBgNVBAoUHEdsb2JhbCBUcnVz dCBBdXRob3JpdHkgKEdUQSkxCzAJBgNVBAYUAkVTMB4XDTAwMDczMTExMjIwMFoXDTAxMDcy OTAxMDAwMFowbjEPMA0GA1UECBQGTWFkcmlkMQ8wDQYDVQQHFAZNYWRyaWQxDDAKBgNVBAMU A01UQTEOMAwGA1UECxQFU0lCT1MxHzAdBgNVBAoUFkdsb2JhbCBUcnVzdCBBdXRob3JpdHkx CzAJBgNVBAYUAkVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7tjoug3J4iCmQP+A1 WEonWbuzvwfpoYff6VLi7ksljSkdyL7purgrvpx20WqVsZA7uE3WARfBYH5i14IzNeMnBljY P7lpAgQlWJWnIJa6PUFG8gbkeBw0QFgHUTCFY7jRztMzifyxnmmJuPe86gjJR5uuKm51ADw/ OX8PzGn/GwIDAQABMAsGCSqGSIb3DQEBBAOBgQBCO7t72Po02tkOVHlhpRFERP7M6eIle0ve 82XpkBcLvgtsAfyEi7RFv3rCorEyWHKoAsYNh42aWEyUpDk211NLNkVRgn5+ReM/hCGSgEfd RyTuAd3uRRTrcN2NjXQ5RG4qpFHXG+zRVE+iKOMK6ndJb9UWDvbmaw3t+EHljofvDDGCAdcw ggHTAgEBMH0weDEPMA0GA1UECBQGTWFkcmlkMQ8wDQYDVQQHFAZNYWRyaWQxDDAKBgNVBAMU A1NUQTETMBEGA1UECxQKRGVtbyBTSUJPUzEkMCIGA1UEChQbR2xvYmFsIFRydXN0IEF1dGhv cml0eShHVEEpMQswCQYDVQQGFAJFUwIBJDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDgxMTA2MjczMFowIwYJKoZIhvcNAQkE MRYEFElySmBQoPhOwvoFKfj0hn+ObaATMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MA0GCSqGSIb3DQEBAQUABIGAPE74Sm7DKq08HeCUf0l+8PDM0QHyS0EbHqlDHXVQAFP/yN6o u5U321hDZ+QVlvCpEeCHf6LrUAgMS1bJuS1vC4rza9OQsnrBZ62DOBHQnGNHSQQePFD0RRR9 zgGzCYJ6gc+F3YCe/vQEjUBHHbURDcR32UgK292lwGUpao7feYY= --------------msA41F226F0ED820E39A6C1103-- Received: from lafontaine.cybercable.fr (lafontaine.cybercable.fr [212.198.0.202]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA14088 for ; Thu, 10 Aug 2000 21:49:23 -0700 (PDT) Received: (qmail 758215 invoked from network); 11 Aug 2000 04:48:46 -0000 Received: from r209m73.cybercable.tm.fr (HELO aeg) ([195.132.209.73]) (envelope-sender ) by lafontaine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 11 Aug 2000 04:48:46 -0000 From: "Abdellah EL GARANI" To: Subject: Date: Fri, 11 Aug 2000 06:51:17 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <27FF4FAEA8CDD211B97E00902745CBE2B4182B@seine.valicert.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal unsuscribe Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA21222 for ; Thu, 10 Aug 2000 16:48:51 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 10 Aug 2000 17:41:40 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 10 Aug 2000 14:27:39 -0600 From: "Bob Jueneman" To: , , Cc: Subject: RE: OCSP and XML Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_5B03FCA4.36573A78" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_5B03FCA4.36573A78 Content-Type: multipart/alternative; boundary="=_5B03FCA4.37563B79" --=_5B03FCA4.37563B79 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable >You don't prefer XML to ASN.1? I most certainly don't for this purpose, and that has=20 nothing whatsoever to do with the language's=20 expressive power, efficiency, or whatever. By now, anyone who is processing directories, certificates, etc., has already climbed up the ladder of ASN.1 competence. In our case we wrote our own set of libraries in a very short=20 time, and have had no trouble using them. What I DON'T want to have to do is support two different ways of=20 doing the same thing. It adds to code bloat, significantly increases=20 the already too-high testing burden, etc. In addition, and a more subtle point, is the fact that it is almost=20 never possible to exactly translate between two languages -- there is always something in one specification that doesn't quite=20 have an exact analog in the other language. As a result, attempts to translate a specification in one language into=20 another will typically fail the first or even the second time, and as a result the specification becomes ambiguous. Rewriting, rethinking, and recoding all of the work that has already=20 been done would be an enormous undertaking, and certainly not worth doing. To quote Winston Churchill in a different context, "That is the sort of nonsense up with which I shall not put." Bob Robert R. Jueneman Consultant Engineer, PKI/Security Architect Novell, Inc. -- the leading provider of Net services software 1800 South Novell Place Provo, UT 84606 www.novell.com bjueneman@novell.com 1-801-861-7387 DISCLAIMER: If this message (with or without attached documents) is digitally = signed, and/or if certificates are attached, the intended purpose is to=20 (1) Ensure that e-mail came from the apparent sender (2) Protect e-mail from tampering (3) Ensure that the content of e-mail sent to me and encrypted in my = dual-use key cannot be viewed by others. It is explicitly NOT the intent of any such signed message or document = to represent any type or form of legally binding contract or other = representation, and any such interpretation should not be considered = commercially reasonable and will be repudiated, notwithstanding any = wording or implications to the opposite effect in the text of the message = itself. --=_5B03FCA4.37563B79 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>You don't prefer XML to ASN.1?
I most certainly don't for this purpose, and that has
nothing whatsoever to do with the language's
expressive power, efficiency, or whatever.
 
By now, anyone who is processing directories, certificates,
etc., has already climbed up the ladder of ASN.1 competence.
In our case we wrote our own set of libraries in a very short
time, and have had no trouble using them.
 
What I DON'T want to have to do is support two different ways of =
doing the same thing.  It adds to code bloat, significantly = increases=20
the already too-high testing burden, etc.
 
In addition, and a more subtle point, is the fact that it is almost =
never possible to exactly translate between two languages --
there is always something in one specification that doesn't quite =
have an exact analog in the other language.
 
As a result, attempts to translate a specification in one language = into=20
another will typically fail the first or even the second time, and = as
a result the specification becomes ambiguous.
 
Rewriting, rethinking, and recoding all of the work that has already =
been done would be an enormous undertaking, and certainly not
worth doing.
 
To quote Winston Churchill in a different context,
"That is the sort of nonsense up with which I shall not put."
 
Bob
 
 
 
Robert R. Jueneman
Consultant Engineer, PKI/Security Architect
 
Novell, Inc. -- the leading provider of Net services software
1800 = South=20 Novell Place
Provo, UT 84606
www.novell.com
 
bjueneman@novell.com
1-801-861-= 7387
 
DISCLAIMER:
  If this message (with or without attached = documents)=20 is digitally signed, and/or if certificates are attached, the intended = purpose=20 is to
   (1) Ensure that e-mail came from the apparent=20 sender
   (2) Protect e-mail from tampering
   = (3)=20 Ensure that the content of e-mail sent to me and encrypted in  my = dual-use=20 key cannot be viewed by others.
  It is explicitly NOT the intent = of any=20 such signed message or document to represent any type or form of legally = binding=20 contract or other representation, and any such interpretation should not = be=20 considered commercially reasonable and will be repudiated, notwithstanding = any=20 wording or implications to the opposite effect in the text of the = message=20 itself.
--=_5B03FCA4.37563B79-- --=_5B03FCA4.36573A78 Content-Type: text/plain Content-Disposition: attachment; filename="Bob Jueneman.vcf" BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Bob Jueneman TEL;WORK:801-861-7387 ORG:Novell Inc. -- the leading provider of Net services software;eBusiness Solutions TEL;PREF;FAX:801-861-2522 EMAIL;WORK;PREF;S/MIME:BJUENEMAN@novell.com N:Jueneman;Robert TITLE:consultant Engineer, PKI/Security Architect ADR;INTL;WORK;PARCEL;POSTAL:;;Novell, Inc.\n1800 South Novell Place\n;Provo;Utah;84606;USA LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Bob Jueneman=0A= Novell, Inc.=0A= 1800 South Novell Place=0A= =0A= Provo, Utah 84606=0A= USA LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Bob Jueneman=0A= Novell, Inc.=0A= 1800 South Novell Place=0A= =0A= Provo, Utah 84606 X-GWUSERID:BJUENEMAN END:VCARD BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Robert R. Jueneman TEL;WORK:801-861-7387 ORG:Novell, Inc.;Network Security Development TEL;PREF;FAX:801-861-2522 EMAIL;WORK;PREF;NGW:BJUENEMAN@novell.com N:Jueneman;Bob TITLE:Consultant Engineer ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;USA LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A= PRV-F331=0A= 122 E. 1700 South=0A= Provo, Utah 84606=0A= USA LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A= PRV-F331=0A= 122 E. 1700 South=0A= Provo, Utah 84606 TEL;HOME:1-801-765-4378 TEL;CELL:1-801-361-1410 TEL;PREF:1-801-861-7387, 1-800-453-1267 X-GWUSERID:BJUENEMAN END:VCARD --=_5B03FCA4.36573A78-- Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20680 for ; Thu, 10 Aug 2000 16:42:32 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 16:32:31 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2B4182B@seine.valicert.com> From: Ambarish Malpani To: "'TAKIGUCHI Naruhito'" , ietf-pkix@imc.org Subject: RE: CRL number in CRL and ARL Date: Thu, 10 Aug 2000 16:32:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" That is perfectly legal. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: TAKIGUCHI Naruhito [mailto:takiguti@fjh.se.fujitsu.co.jp] > Sent: Thursday, August 10, 2000 4:52 AM > To: ietf-pkix@imc.org > Subject: Re: CRL number in CRL and ARL > > > Ambarish, > > > If you are using CRLDPs, the numbering for each DP is independent. > > > > It is okay to number them in the following way: > > > > Time DP1 DP2 > > 1 10 5 > > 2 12 17 > > 3 15 18 > > 4 99 201 > > 5 202 202 > > > > Or any other interesting scheme you would prefer, as long as > > the numbers for DP1 are monotonically increasing and the > > numbers for DP2 are monotoncally increasing. > > > > Note: This example is *not* meant to imply that you even need to > > issue both DPs at all the times specified. > > Thank you very much. > I see that the CRL number is a monotonically increasing > number for each CRL scope. > > But, in your example, the CRL number is not a sequence number. > Is this right? > > ----- > Naruhito TAKIGUCHI > FUJITSU HOKURIKU SYSTEMS LTD. > > Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20481 for ; Thu, 10 Aug 2000 16:41:21 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 16:31:20 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2B4182A@seine.valicert.com> From: Ambarish Malpani To: "'jspinney@securify.com'" , juancarlos.perez@acepta.com, "''Ietf-Pkix'" Subject: RE: Client-side revocation checking capability Date: Thu, 10 Aug 2000 16:31:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA20482 Hi Juan, I agree with Jeff that most client applications don't do revocation checking. To the best of my belief, some of the 3.0 versions of Netscape Navigator etc. could do CRL checking if the cert had some magic extensions in them. Communicator 4.7, with the PSM module does a pretty reasonable job of revocation checking with OCSP. We (ValiCert) do have a plugin for both IE 5.0 and Outlook that can also enable those applications to do revocation checking with OCSP. We also have plugins for Netscape Enterprise Server and IIS, but you don't seem to be interested in servers from your mail. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Jeff Spinney [mailto:spinneyj@flashcom.net] > Sent: Thursday, August 10, 2000 3:05 PM > To: juancarlos.perez@acepta.com; ''Ietf-Pkix' > Subject: RE: Client-side revocation checking capability > > > OCSP server vendors such as CertCo (www.certco.com) or Valicert > (www.valicert.com) have toolkits with which you can OCSP 'enable' an > application. This is great for application vendors who wish > to make their > apps more robust and certificate enabled. Most applications > at this point in > the game are not OCSP enabled even if they can deal with > certificates, they > do the basic crypto checking *if* they have the issuer cert > on hand, but do > not do real time status checking to see whether or not the > cert has been > revoked since it was issued. > > in that regard, it seems as though the application > market needs to be > persuaded to make their software support real time certificate status > checking. > > > As for Netscape, they do have an OCSP client for their > browser. I am unsure > if it is publically available at this time. It loads into the > security area, > under 'advanced' and gives you the option to specify an OCSP > responder. In > my experiance, and it was in the early stages of this modules > lifetime, it > was very finicky. If i remember correctly, it wanted the > OCSP response to > be sgned by the same cert that signed the cert being checked. > This may not > always be the case. > > > -j > > > > -----Original Message----- > From: Juan Carlos Pérez Aguayo [mailto:juancarlos.perez@acepta.com] > Sent: Thursday, August 10, 2000 12:36 PM > To: 'Ietf-Pkix > Subject: Client-side revocation checking capability > > > I am in trouble about this: What is the real support that have the > client-side software for certificate revocation checking now? > i.e. (Internet > Explorer, Netscape, etc.) > > I heard that, in fact, client-applications don`t do any > revocation checking > at all? It's that truly? > > What is the real capability of those client applications this time? > > By example, I know that Netscape define some certificate > extensions for > managing revocation, but I am not sure if realy work > > Can anyone give me some help? > > Thanks you > > > > Juan Carlos Pérez Aguayo > Software Engineer > Acepta.com > juancarlos.perez@acepta.com > > Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA19258 for ; Thu, 10 Aug 2000 16:11:38 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <4.3.2.7.2.20000810135026.00aef890@homebase.htt-consult.com> References: <4.3.2.7.2.20000810135026.00aef890@homebase.htt-consult.com> Date: Thu, 10 Aug 2000 16:11:04 -0700 To: ietf-pkix@imc.org From: Paul Hoffman / IMC Subject: RE: OCSP and XML Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 1:51 PM -0400 8/10/00, Robert Moskowitz wrote: >>You don't prefer XML to ASN.1? > >You first get PKCS#7 and S/MIME to switch away from ASN.1 to XML. >Then we will talk about doing it in PKIX.... Bob, could you explain this a bit? Using XML as a message format for SCVP is completely unrelated to PKCS#7. It is a method for bundling the parts of the query about a certificate, and for bundling the parts of the answer. Why should that be tied to an unrelated protocol? --Paul Hoffman, Director --Internet Mail Consortium Received: from c014.sfo.cp.net (c014-h022.c014.sfo.cp.net [209.228.12.86]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA16832 for ; Thu, 10 Aug 2000 15:09:11 -0700 (PDT) Received: (cpmta 23591 invoked from network); 10 Aug 2000 15:08:02 -0700 Received: from 3ff8359b.dsl.flashcom.net (HELO concord) (63.248.53.155) by smtp.flashcom.net with SMTP; 10 Aug 2000 15:08:02 -0700 X-Sent: 10 Aug 2000 22:08:02 GMT Reply-To: From: "Jeff Spinney" To: , "''Ietf-Pkix'" Subject: RE: Client-side revocation checking capability Date: Thu, 10 Aug 2000 18:04:34 -0400 Message-ID: <000701c00316$f8359980$6501010a@jeffshouse.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal OCSP server vendors such as CertCo (www.certco.com) or Valicert (www.valicert.com) have toolkits with which you can OCSP 'enable' an application. This is great for application vendors who wish to make their apps more robust and certificate enabled. Most applications at this point in the game are not OCSP enabled even if they can deal with certificates, they do the basic crypto checking *if* they have the issuer cert on hand, but do not do real time status checking to see whether or not the cert has been revoked since it was issued. in that regard, it seems as though the application market needs to be persuaded to make their software support real time certificate status checking. As for Netscape, they do have an OCSP client for their browser. I am unsure if it is publically available at this time. It loads into the security area, under 'advanced' and gives you the option to specify an OCSP responder. In my experiance, and it was in the early stages of this modules lifetime, it was very finicky. If i remember correctly, it wanted the OCSP response to be sgned by the same cert that signed the cert being checked. This may not always be the case. -j -----Original Message----- From: Juan Carlos Pérez Aguayo [mailto:juancarlos.perez@acepta.com] Sent: Thursday, August 10, 2000 12:36 PM To: 'Ietf-Pkix Subject: Client-side revocation checking capability I am in trouble about this: What is the real support that have the client-side software for certificate revocation checking now? i.e. (Internet Explorer, Netscape, etc.) I heard that, in fact, client-applications don`t do any revocation checking at all? It's that truly? What is the real capability of those client applications this time? By example, I know that Netscape define some certificate extensions for managing revocation, but I am not sure if realy work Can anyone give me some help? Thanks you Juan Carlos Pérez Aguayo Software Engineer Acepta.com juancarlos.perez@acepta.com Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12620 for ; Thu, 10 Aug 2000 13:22:10 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 13:12:05 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE235E36D@seine.valicert.com> From: Peter Williams To: Renato Portela , "'ietf-pkix@imc.org'" Subject: RE: OCSP and XML Date: Thu, 10 Aug 2000 13:12:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Renato, you can specify an XML-format payload for OCSP at your leisure and at your will, and be entirely conforming to the draft standard in using the payload-format options. Talk to Ambarish, inside or outside IETF - as Steve directs. -----Original Message----- From: Michael Myers [mailto:MMyers@verisign.com] Sent: Thursday, August 10, 2000 11:12 AM To: Renato Portela; 'ietf-pkix@imc.org' Subject: RE: OCSP and XML Not at this time. Mike > -----Original Message----- > From: Renato Portela [mailto:RPortela@sibs.mailcom.pt] > Sent: Thursday, August 10, 2000 7:17 AM > To: 'ietf-pkix@imc.org' > Subject: OCSP and XML > > > The syntax of SCVP is being specified with XML. > Is any chance do the same to OCSP? > > Thanks > Renato Portela > Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06519 for ; Thu, 10 Aug 2000 11:13:49 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id LAA20174; Thu, 10 Aug 2000 11:13:28 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 11:12:01 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4F9353B@vhqpostal.verisign.com> From: Michael Myers To: Renato Portela , "'ietf-pkix@imc.org'" Subject: RE: OCSP and XML Date: Thu, 10 Aug 2000 11:11:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Not at this time. Mike > -----Original Message----- > From: Renato Portela [mailto:RPortela@sibs.mailcom.pt] > Sent: Thursday, August 10, 2000 7:17 AM > To: 'ietf-pkix@imc.org' > Subject: OCSP and XML > > > The syntax of SCVP is being specified with XML. > Is any chance do the same to OCSP? > > Thanks > Renato Portela > Received: from htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA05114 for ; Thu, 10 Aug 2000 10:54:52 -0700 (PDT) Received: from rgm.htt-consult.com ([63.82.18.195]) by htt-consult.com ; Thu, 10 Aug 2000 13:54:13 -0400 Message-Id: <4.3.2.7.2.20000810135026.00aef890@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 10 Aug 2000 13:51:37 -0400 To: Renato Portela , "'Denis Pinkas'" From: Robert Moskowitz Subject: RE: OCSP and XML Cc: "'ietf-pkix@imc.org'" In-Reply-To: <63DA964A0E78D211B53E0008C7A4F56D014DC1AE@sibsex.sibs> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 05:31 PM 8/10/2000 +0100, Renato Portela wrote: >The idea is not have more protocols but have a transition from ASN.1 to XML. > >Work with XML is much simpler. Exists parsers everywhere and for almost >every language, is interoperable and finally is human readable. > >You don't prefer XML to ASN.1? You first get PKCS#7 and S/MIME to switch away from ASN.1 to XML. Then we will talk about doing it in PKIX.... Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com Received: from racine.cybercable.fr (racine.cybercable.fr [212.198.0.201]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA04694 for ; Thu, 10 Aug 2000 10:48:22 -0700 (PDT) Received: (qmail 598492 invoked from network); 10 Aug 2000 17:47:42 -0000 Received: from r209m73.cybercable.tm.fr (HELO aeg) ([195.132.209.73]) (envelope-sender ) by racine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 10 Aug 2000 17:47:42 -0000 From: "Abdellah EL GARANI" To: "'Ietf-Pkix" Subject: unsubscribe Date: Thu, 10 Aug 2000 19:50:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 unsubscribe Received: from nxs_vyr_dns.sie.cl ([206.48.156.90]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01008 for ; Thu, 10 Aug 2000 09:38:49 -0700 (PDT) Received: from jperez ([192.168.4.178]) by nxs_vyr_dns.sie.cl (8.9.3/8.9.3) with SMTP id MAA29306 for ; Thu, 10 Aug 2000 12:43:07 -0400 Reply-To: From: =?iso-8859-1?Q?Juan_Carlos_P=E9rez_Aguayo?= To: "'Ietf-Pkix" Subject: Client-side revocation checking capability Date: Thu, 10 Aug 2000 12:36:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal I am in trouble about this: What is the real support that have the client-side software for certificate revocation checking now? i.e. (Internet Explorer, Netscape, etc.) I heard that, in fact, client-applications don`t do any revocation checking at all? It's that truly? What is the real capability of those client applications this time? By example, I know that Netscape define some certificate extensions for managing revocation, but I am not sure if realy work Can anyone give me some help? Thanks you Juan Carlos Pérez Aguayo Software Engineer Acepta.com juancarlos.perez@acepta.com Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA29694 for ; Thu, 10 Aug 2000 09:26:59 -0700 (PDT) Received: (qmail 31547 invoked from network); 10 Aug 2000 16:17:24 -0000 Received: from unknown (HELO mail.sibs.pt) (172.17.0.2) by 172.16.0.3 with SMTP; 10 Aug 2000 16:17:24 -0000 Received: from edi.van ([194.117.48.12]) by mail.sibs.pt (Netscape Mail Server v2.02) with ESMTP id AAA19863; Thu, 10 Aug 2000 17:25:22 +0100 Received: from SIBSEX.sibs ([192.168.250.26]) by edi.van (8.8.2/8.8.2) with ESMTP id RAA28745; Thu, 10 Aug 2000 17:23:22 +0100 (PST) Received: by sibsex.sibs with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 17:31:35 +0100 Message-ID: <63DA964A0E78D211B53E0008C7A4F56D014DC1AE@sibsex.sibs> From: Renato Portela To: "'Denis Pinkas'" Cc: "'ietf-pkix@imc.org'" Subject: RE: OCSP and XML Date: Thu, 10 Aug 2000 17:31:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" The idea is not have more protocols but have a transition from ASN.1 to XML. Work with XML is much simpler. Exists parsers everywhere and for almost every language, is interoperable and finally is human readable. You don't prefer XML to ASN.1? Renato -----Original Message----- From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] Sent: Thursday, August 10, 2000 3:29 PM To: Renato Portela Cc: 'ietf-pkix@imc.org' Subject: Re: OCSP and XML > The syntax of SCVP is being specified with XML. ... and ASN.1. At this time, there is no decision to support SCVP or an equivalent, as well as no decision to have XML in addition to ASN.1. > Is any chance do the same to OCSP? I hope there is not such a "chance". We already have too many protocols for the same purpose. :-) Denis > > Thanks > Renato Portela Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27536 for ; Thu, 10 Aug 2000 09:01:25 -0700 (PDT) Received: from asn-1.com (user-2ivf56f.dialup.mindspring.com [165.247.148.207]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id MAA17262; Thu, 10 Aug 2000 12:00:40 -0400 (EDT) Message-ID: <3992D240.4A623521@asn-1.com> Date: Thu, 10 Aug 2000 12:03:12 -0400 From: "Phillip H. Griffin" Reply-To: phil.griffin@asn-1.com Organization: Griffin Consulting X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: kelm@secorvo.de CC: "'ietf-pkix@imc.org'" Subject: Re: X9.79? References: <200008101425.QAA25728@rom.antech.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In general, Accredited Standards Committee X9 is the national standards setting body for the financial services industry. ASC X9 is accredited by ANSI. All approved X9 Standards are available in electronic form at the ASC X9 Web site's Electronic Standards Store (ESS) at www.x9.org or through the ANSI Web store at www.ansi.org. Hard copies can be obtained from Global Engineering Documents at 1-800-854-7179. For more information about ASC X9 or its committees, contact Cynthia Fuller, managing director, at (202) 663-5284. It is my understanding that X9.79 is a proposed standard of the X9F5 working group that has been balloted but has not yet been approved. Once it is approved it will be available through the X9/ANSI electronic bookstore. Until it is approved and published you can obtain a copy of the draft by joining X9, X9F or the X9 WG. Joining can give you access to all documents, the right to contribute to the development of the standards, to attend meetings, and to comment and vote. X9 is also the TAG for ISO TC68 (www.tc68.org) and work is already underway on either a derivative of X9.79 or an ISO level version of X9.79. The X9.79 proposed standard is very likely to be an input document to a TC68 working group. You can contact the TC68 representative for your country and get more information. Phil Stefan Kelm wrote: > > I apologize for sending this question to the PKIX list but I wasn't able to > find the ANSI draft X9.79 anywhere, not even on www.ansi.org. > > Does anyone out there know how to get a copy? Is it available to the public > at all? > > Any feedback is highly appreciated! > > Cheers, > > Stefan. > > -------------------------------------------------------- > PKI-Symposium, 10.-11.Oktober 2000, www.pki-symposium.de > -------------------------------------------------------- > Dipl.-Inform. Stefan Kelm > Security Consultant > > Secorvo Security Consulting GmbH > Albert-Nestler-Strasse 9, D-76131 Karlsruhe > > Tel. +49 721 6105-461, Fax +49 721 6105-455 > E-Mail kelm@secorvo.de, http://www.secorvo.de > ------------------------------------------------------- > PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B Phillip H. Griffin Griffin Consulting http://asn-1.com Secure ASN.1 Design & Implementation +1-919-832-7008 1625 Glenwood Avenue, Five Points +1-919-832-7390 [fax] Raleigh, North Carolina 27608 USA ------------------------------------------------------------ Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21858 for ; Thu, 10 Aug 2000 08:17:51 -0700 (PDT) Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA22352 for ; Thu, 10 Aug 2000 11:17:11 -0400 (EDT) Received: from anuxc.mv.lucent.com (h135-13-160-12.lucent.com [135.13.160.12]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA22152; Thu, 10 Aug 2000 11:17:04 -0400 (EDT) Received: from irene by anuxc.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA19146; Thu, 10 Aug 2000 11:14:06 -0400 (EDT) Message-Id: <4.1.20000810095846.00a209e0@anuxc.mv.lucent.com> X-Sender: irg@anuxc.mv.lucent.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 10 Aug 2000 11:17:21 -0400 To: Al Arsenault From: Irene Gassko Subject: RE: OCSP request Cc: "ietf-pkix@imc.org" In-Reply-To: <01C00119.59D0CC00.aarsenault@dvnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Al, Thanks for your analysis. My replies are inline. At 09:16 AM 08/08/2000 -0400, Al Arsenault wrote: >Irene Gassko wrote: > >So, it looks like efficiency really depends on how those certificates are >used. > >This part I'll agree with completely! As experience has shown repeatedly, >there's no "one best way" that always gives best performance from a PKI >implementation. It's a function of what application(s) you're trying to >support, what risks you're willing to take, what your constraints are in >terms of time, money, and technology, and a lot of other things, besides. > >I guess I started this by using the term "normal processing mode", so I'll >attempt to clarify - in some environments - e.g., where certificates are >being used to sign, encrypt, and verify e-mail messages - the approach >suggested by Irene seems to me to be less efficient than the approaches >currently defined in PKIX today, and in more-or-less common use. In other >environments, the approach she suggested MAY be more efficient, depending >on a lot of the factors identified above. > Now I understand what you mean by normal processing mode. You are right that we have different examples in mind when talking about certificates. I do not see why efficiency in cert processing is so important for email, when our speed of reading is so slow. I suspect that the main bottleneck in efficient processing of email is us, not certificate verification. When I think of certificates, I think more of hardware tokens and credit cards and cases when these need to be verified in quantity, say, by a vendor. It is not the only model I consider, but this is the first one I will think of when certs are mentioned. >Some specific comments in-line: >> >This is absolutely correct if you only want to check one individual certificate, >do not care about the possibility of revocation much and are not worried >about potential CA key compromise. Yes, and also if you trust directories >to tell you truthfully whether they have a particular certificate you are >looking for. > >AWA: I disagree to a greater or lesser extent with every clause in this >paragraph. The number of certificates does not have to be one; "small" for >appropriate values of that word will suffice. > >"Do not care about the possibility of revocation much" - huh? Where did >that come from? I pointed out that sometimes you're going to reject a >putative cert even BEFORE you check revocation status; e.g., because it got >garbled in transit and thus the signature fails. Why does "reject because >the signature failed before I ever bothered to check revocation" equal >"don't care about revocation"? > You are right, I missed that part, sorry for the confusion. In our scheme you have 2 checks for the price of 1. And if half of your correspondents have Verisign certificates, you can schedule checking Verisign's signature anytime you want, say while you get your well-deserved rest, and then you will need to check only a few hashes for each of these guys. If efficiency of checking is important for some reason, the hashes you need may even be attached to the cert. >"Are not worried about potential CA key compromise" - bear in mind that >there are a lot of factors that come into play if a CA key has been >compromised. Thus, making a decision to accept a certificate originally >signed with a key known to have been compromised requires a lot of >consideration. > Absolutely. Still our scheme allows much better recovery in this case, and if we come back to archiving, then the original CA keys have a substantial probability of being compromised over a long period of time (say, 50 years). OTOH, if the CA's key is quietly compromised only our scheme helps to catch forgery fast. >If you are checking a number of certificates from the same CA (say, Visa >cards) then you only need to check one signature and a few hashes, >which is much more efficient then checking a signature from every >certificate. You can even check that signature in advance, >for example a vendor can do it outside of rush hours and then only >a few hashes need to be computed: this is more >efficient than verifying a signature each time. If your certificate is your >credit card and today is your shopping day, you can prefetch >verification path to speed up approval for your purchases (in this >case I assume it to be a smartcard, as is common in Europe). > >AWA: yes, for this environment, the approach you suggest may be more >efficient than the traditional one. > >Besides efficiency issues there are other properties that a current scheme >does not possess. For example, if a CA key gets silently compromised, >and a certificate is forged quietly, with the current technology there is no >way to discover that a certificate is fake. However, in our scheme, in order >to fabricate a certificate, the root value of the Merkle tree has to be >altered, which will be too conspicuous to miss. > >AWA: forgive me if I get the technology wrong - I have some familiarity >with Merkle trees, but I'm certainly no expert on them. However, as I >understand the technology proposed, every time the CA issues a new >legitimate certificate, the root value has to be altered. In any kind of >dynamic environment - e.g., certificates issued every few (seconds, >minutes, hours,...), new certs are issued and thus the root value has to >change regularly. Thus, the event "root value altered because of a fake >cert signed by a compromised key" is very difficult to distinguish from >"root value altered because of legitimate cert signed by the real CA", >EXCEPT to the CA itself. Yes, if the CA is "eternally vigilant", you might >catch this happening, but then again you might not. > Let us look at the current practice of credit card companies. If you get your card or cancel it, all changes are actually done once a day. If we do the same for Merkle tree, it will a be a root of the day, a forgery of which will be very visible. You can do it more often, but most probably it will be at scheduled intervals and any update at inappropriate time will be obviously suspicious. >And another property. Even though directories are supposed to be untrusted >(or we would not need a CA signature at all), if we are looking for a >certificate, we are willing to believe that a particular certificate is not in the >directory, on the directory's say so. Our approach allows you get a get >a proof that this directory really does not possess a cert you are looking for. >No more trust needed for untrusted directories. > >AWA: If the directory tries to say "I have some certs, but not the one for >which you're looking", your approach works. If the directory says "I have >no certs at all", your approach provides the same results as the previous >approach. About which "attack" do you care? > If the directory says, "I have no certs", you go to another directory. If the directory says "I have all the certs, but the one you are looking for does not exist", you have either to double your effort by checking another, independent directory each time, or risk the fact that you are being cheated. I think that this "attack" is worse. Irene ---------------------------------------------------------------------------- ------------------------------------------------------- Irene Gassko Bell Laboratories http://www.lucent.com Lucent Technologies Secure Technologies Dept. 1600 Osgood Street phone: (978) 960-5767 Room 30-2-A31 e-mail: gassko@lucent.com N. Andover, MA 01845 fax: (978) 960-3240 Received: from rom.antech.de (dns.antech.de [194.45.12.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17806 for ; Thu, 10 Aug 2000 07:41:47 -0700 (PDT) Received: from scherbius.secorvo.de (scherbius.secorvo.de [194.45.12.219]) by rom.antech.de (8.9.3/8.9.3) with ESMTP id QAA25728 for ; Thu, 10 Aug 2000 16:25:12 +0200 Message-Id: <200008101425.QAA25728@rom.antech.de> From: "Stefan Kelm" Organization: Secorvo Security Consulting GmbH To: "'ietf-pkix@imc.org'" Date: Thu, 10 Aug 2000 16:40:14 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: X9.79? Reply-to: kelm@secorvo.de Priority: normal In-reply-to: <3992BC27.F565F259@bull.net> X-mailer: Pegasus Mail for Win32 (v3.12b) I apologize for sending this question to the PKIX list but I wasn't able to find the ANSI draft X9.79 anywhere, not even on www.ansi.org. Does anyone out there know how to get a copy? Is it available to the public at all? Any feedback is highly appreciated! Cheers, Stefan. -------------------------------------------------------- PKI-Symposium, 10.-11.Oktober 2000, www.pki-symposium.de -------------------------------------------------------- Dipl.-Inform. Stefan Kelm Security Consultant Secorvo Security Consulting GmbH Albert-Nestler-Strasse 9, D-76131 Karlsruhe Tel. +49 721 6105-461, Fax +49 721 6105-455 E-Mail kelm@secorvo.de, http://www.secorvo.de ------------------------------------------------------- PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17067 for ; Thu, 10 Aug 2000 07:30:09 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA19368; Thu, 10 Aug 2000 16:33:39 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA37718; Thu, 10 Aug 2000 16:28:53 +0200 Message-ID: <3992BC27.F565F259@bull.net> Date: Thu, 10 Aug 2000 16:28:55 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Renato Portela CC: "'ietf-pkix@imc.org'" Subject: Re: OCSP and XML References: <63DA964A0E78D211B53E0008C7A4F56D014DC1AC@sibsex.sibs> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > The syntax of SCVP is being specified with XML. ... and ASN.1. At this time, there is no decision to support SCVP or an equivalent, as well as no decision to have XML in addition to ASN.1. > Is any chance do the same to OCSP? I hope there is not such a "chance". We already have too many protocols for the same purpose. :-) Denis > > Thanks > Renato Portela Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA15715 for ; Thu, 10 Aug 2000 07:12:05 -0700 (PDT) Received: (qmail 21825 invoked from network); 10 Aug 2000 14:02:32 -0000 Received: from unknown (HELO mail.sibs.pt) (172.17.0.2) by 172.16.0.3 with SMTP; 10 Aug 2000 14:02:32 -0000 Received: from edi.van ([194.117.48.12]) by mail.sibs.pt (Netscape Mail Server v2.02) with ESMTP id AAA9174 for ; Thu, 10 Aug 2000 15:10:30 +0100 Received: from SIBSEX.sibs ([192.168.250.26]) by edi.van (8.8.2/8.8.2) with ESMTP id PAA08044 for ; Thu, 10 Aug 2000 15:08:32 +0100 (PST) Received: by sibsex.sibs with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 15:16:45 +0100 Message-ID: <63DA964A0E78D211B53E0008C7A4F56D014DC1AC@sibsex.sibs> From: Renato Portela To: "'ietf-pkix@imc.org'" Subject: OCSP and XML Date: Thu, 10 Aug 2000 15:16:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" The syntax of SCVP is being specified with XML. Is any chance do the same to OCSP? Thanks Renato Portela Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12644 for ; Thu, 10 Aug 2000 06:04:29 -0700 (PDT) From: fred@cisco.com Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.69.25.24]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA12151; Thu, 10 Aug 2000 06:03:04 -0700 (PDT) Received: (fred@localhost) by irp-view7.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA29980; Thu, 10 Aug 2000 06:02:48 -0700 (PDT) Date: Thu, 10 Aug 2000 06:02:48 -0700 (PDT) Message-Id: <200008101302.GAA29980@irp-view7.cisco.com> To: bob@example.test, ietf-pkix@imc.org, pbaker@verisign.com, sharon.boeyen@entrust.com Subject: draft-ietf-pkix-pkixrep-00.txt I notice that you recently posted a new internet draft. A document that might be worth reading is http://www.ietf.org/ID-nits.html This document was put together by members of the IESG to help the community know what are the most common problems that we see in documents, whether from working groups or individual submissions, and pro-actively avoid them. This is an automatic email; please don't conclude that I have discovered something awful about your draft, as I haven't even read it yet. Rather, I'm just letting you know that there is a list of common issues that get raised over and over again in IESG reviews, and I'd like to save you the hassle by letting you see for yourself whether any of them apply. Let me know if you have any questions I can answer. Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA07221 for ; Thu, 10 Aug 2000 04:53:00 -0700 (PDT) Received: from m3.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0006-Fujitsu Gateway) id UAA07447 for ; Thu, 10 Aug 2000 20:51:49 +0900 (JST) (envelope-from takiguti@fjh.se.fujitsu.co.jp) Received: from nic10.fjh.se.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.9.3/3.7W-0008-Fujitsu Domain Master) id UAA09811; Thu, 10 Aug 2000 20:51:48 +0900 (JST) Received: from anakin (anakin.fjh.se.fujitsu.co.jp [10.131.201.130]) by nic10.fjh.se.fujitsu.co.jp (8.9.3+3.2W/3.7W) with ESMTP id UAA07243 for ; Thu, 10 Aug 2000 20:51:48 +0900 (JST) Date: Thu, 10 Aug 2000 20:51:48 +0900 From: TAKIGUCHI Naruhito To: ietf-pkix@imc.org Subject: Re: CRL number in CRL and ARL In-Reply-To: <27FF4FAEA8CDD211B97E00902745CBE2B41816@seine.valicert.com> References: <27FF4FAEA8CDD211B97E00902745CBE2B41816@seine.valicert.com> Message-Id: <20000810151820.6BDC.TAKIGUTI@fjh.se.fujitsu.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00 (beta 25) Ambarish, > If you are using CRLDPs, the numbering for each DP is independent. > > It is okay to number them in the following way: > > Time DP1 DP2 > 1 10 5 > 2 12 17 > 3 15 18 > 4 99 201 > 5 202 202 > > Or any other interesting scheme you would prefer, as long as > the numbers for DP1 are monotonically increasing and the > numbers for DP2 are monotoncally increasing. > > Note: This example is *not* meant to imply that you even need to > issue both DPs at all the times specified. Thank you very much. I see that the CRL number is a monotonically increasing number for each CRL scope. But, in your example, the CRL number is not a sequence number. Is this right? ----- Naruhito TAKIGUCHI FUJITSU HOKURIKU SYSTEMS LTD. Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA13189 for ; Wed, 9 Aug 2000 23:15:09 -0700 (PDT) Received: by mystic1.trustcenter.de; id IAA02118; Thu, 10 Aug 2000 08:12:00 +0200 Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma002116; Thu, 10 Aug 00 08:11:26 +0200 Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id IAA02650; Thu, 10 Aug 2000 08:13:08 +0200 (MET DST) Message-Id: <3.0.5.32.20000810081311.038e0690@localhost> X-Sender: jbr@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 10 Aug 2000 08:13:11 +0200 To: Ambarish Malpani From: Juergen Brauckmann Subject: RE: OCSP request Cc: ietf-pkix@imc.org In-Reply-To: <27FF4FAEA8CDD211B97E00902745CBE2B417FC@seine.valicert.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 08:40 09.08.00 -0700, Ambarish Malpani wrote: > >Juergen, > We did have a discussion about what kinds of questions OCSP >should answer when we were writing the RFC and the concensus was >that we were only providing the status of the certificate. I think you misunderstood me. I did definitely not want to start another discussion what OCSP is. I said: >> The text may be correct, but it is possible to misinterpret it. Juergen Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA10056 for ; Wed, 9 Aug 2000 22:43:27 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 22:33:20 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2B41816@seine.valicert.com> From: Ambarish Malpani To: "'TAKIGUCHI Naruhito'" , ietf-pkix@imc.org Subject: RE: CRL number in CRL and ARL Date: Wed, 9 Aug 2000 22:33:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" If you are using CRLDPs, the numbering for each DP is independent. It is okay to number them in the following way: Time DP1 DP2 1 10 5 2 12 17 3 15 18 4 99 201 5 202 202 Or any other interesting scheme you would prefer, as long as the numbers for DP1 are monotonically increasing and the numbers for DP2 are monotoncally increasing. Note: This example is *not* meant to imply that you even need to issue both DPs at all the times specified. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: TAKIGUCHI Naruhito [mailto:takiguti@fjh.se.fujitsu.co.jp] > Sent: Wednesday, August 09, 2000 7:59 PM > To: ietf-pkix@imc.org > Subject: Re: CRL number in CRL and ARL > > > Ambarish, > > > If you are creating CRLs and ARLs that are not complete (i.e. > > don't contain all the entries the other does), it is very > > important that you use the CRLDP method of doing it. Put in > > CRLDP extensions in the certificates and IDP (Issuing Distribution > > Point) extensions in your CRLs/ARLs. > > > > If you don't use the CRLDP mechanism, you run the risk of having > > a bunch of applications misbehave with your CRLs. > > Thank you. I agree with your advice. > But, I'm going to discussion about the CRL number. > > I think that the method (a)(the CRL number is a sequece > number for each > CRL scope) is better than the method (b) for a relying party. > RFC2459 and son of RFC2459 describe following : > > The CRL number is a non-critical CRL extension which > conveys a mono- > tonically increasing sequence number for each CRL issued by a CA. > > Does "for each CRL issued by a CA" sentence mean the method (b) ? > > Thanks in advance. > > > Regards, > > Ambarish > > > > > --------------------------------------------------------------------- > > Ambarish Malpani > > Architect > 650.567.5457 > > ValiCert, Inc. > ambarish@valicert.com > > 339 N. Bernardo Ave. > http://www.valicert.com > > Mountain View, CA 94043 > > > > > > > -----Original Message----- > > > From: TAKIGUCHI Naruhito [mailto:takiguti@fjh.se.fujitsu.co.jp] > > > Sent: Tuesday, August 08, 2000 8:13 PM > > > To: ietf-pkix@imc.org > > > Subject: CRL number in CRL and ARL > > > > > > > > > Hi, all. > > > > > > I have a question about the cRLNumber extension. > > > > > > For example, a CA issues CRL(end-entity certificate > revocation list) > > > and ARL(CA certificate revocation list). > > > Which is correct (a) or (b) ? > > > > > > (a) In first CRL and ARL, the CRL number is 0. > > > In next CRL and ARL, the CRL number is 1. > > > > > > In other words, CRL and ARL have same value of > the CRL number. > > > The CRL number is a monotonically increasing > sequence number > > > for each CRL scope. > > > > > > (b) In first CRL, the CRL Number is 0. > > > In first ARL, the CRL Number is 1. > > > In next CRL, the CRL number is 2. > > > In next ARL, the CRL number is 3. > > > > > > In other words, the CRL number is monotonically increasing > > > sequence number for each CA. > > > > > > Could anyone advice me? > > > > > > Thanks in advance. > > > > > > ----- > > > Naruhito TAKIGUCHI > > > FUJITSU HOKURIKU SYSTEMS LTD. > > > > > ----- > Naruhito TAKIGUCHI > FUJITSU HOKURIKU SYSTEMS LTD. > Received: from bird (sero.mf.ejf.hu [193.225.84.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA28140; Wed, 9 Aug 2000 20:05:54 -0700 (PDT) From: nan@quotepool.com Received: from mxspr.mail.accesscomp1.net (host10.4ua.com) by bird with SMTP (1.39.111.2/16.2) id AA067490053; Thu, 10 Aug 2000 03:14:13 +0200 Date: Thu, 10 Aug 2000 03:14:13 +0200 Message-Id: <965875852.cqcoqcngetrm@cqcoqcngetrm.mail.accesscomp1.net> To: cqcoqcngetrm@accesscomp1.net Reply-To: nan@quotepool.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en Content-Type: text/html; Charset=us-ascii Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Are you looking for a J.O.B. or Financial Freedom? vyjxg

93% WHO RESPOND TO MY AD DON'T MAKE THE CUT!
(Only highly motivated people should call)

I'm dead serious! Now let me tell you why...

Most people don't have drive! They sit around waiting for something to happen.
They see that other people have nice homes, new cars, and MONEY, but why can't they?
They basically feel sorry for themselves, and I can't help these people!

Another reason people are not qualified...

They are skeptical. BUT, the truth is, they are skeptical of themselves!
They don't have the courage to break their routine.
They are comfortable with their set hours, their set pay, and their set future.
I was not comfortable with someone controlling my future,
and I'm not comfortable working with people who are!

STOP
If you are anything like the above, we won't be able to work together!

WHAT DO THE 7% WHO DO MAKE THE CUT DISCOVER?!

People I select through an "interview like" process are forever changed!
They are opened to a world around them that they didn't know existed.
In fact, it's a world that has existed around them their whole lives,
but was purposely hidden from them!


How would you like to...

- Drastically reduce personal, business and capital gains taxes?
- Protect all assets from any form of seizure, liens, or judgments?
- Create a six figure income every 4 months?

How about...

Restoring and preserving complete personal and financial privacy?
Amassing personal wealth, multiplying it and protecting it?
Realizing a 3 to 6 times greater return on your money?
Legally making yourself and your assets completely judgment-proof,
lien-proof, divorce-proof, attorney-proof, IRS-proof?
I could go on...

TAKE A SERIOUS LOOK AT YOUR LIFE

Do you think you are paid what you are worth?
Will you be set to retire in the next few years?
Do you control the course of your day? ...your life?

The fact is we have many people in our enterprise that earn over 50K per month
from the privacy of their own homes, and are retiring in 2 to 3 years (wealthy)
and have total freedom - both personal and financial!

Many have been conditioned to believe it must be illegal, immoral or unethical
to ever earn any real profits from our efforts.

The sad truth is, it's been designed that way by the ultra-rich
and ultra-powerful since before any of us were born!

Who am I?

I'm a BIG thinker, a BIG dreamer, and I believe that I deserve the best that life has to offer.
I answered an ad much like the one you are reading now,
and was eager to hear what it was about.

I knew that I couldn't invest only a few bucks and spend an hour or two
per week to achieve the results I was looking for. I found the right information
and now I control my own destiny!

If you are interested in radically changing your thoughts and your financial future,
I invite you to call TOLL FREE:

1 800 707 4817

My name is Krystina, and I look forward to working with some of you!

* REMEMBER *

I can't do it for you, but I can show you exactly how I do it.
It's as simple as that!

Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA27636 for ; Wed, 9 Aug 2000 20:00:44 -0700 (PDT) Received: from m3.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0006-Fujitsu Gateway) id LAA28304 for ; Thu, 10 Aug 2000 11:59:28 +0900 (JST) (envelope-from takiguti@fjh.se.fujitsu.co.jp) Received: from nic10.fjh.se.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.9.3/3.7W-0008-Fujitsu Domain Master) id LAA08788; Thu, 10 Aug 2000 11:59:27 +0900 (JST) Received: from anakin (anakin.fjh.se.fujitsu.co.jp [10.131.201.130]) by nic10.fjh.se.fujitsu.co.jp (8.9.3+3.2W/3.7W) with ESMTP id LAA22520 for ; Thu, 10 Aug 2000 11:59:25 +0900 (JST) Date: Thu, 10 Aug 2000 11:59:24 +0900 From: TAKIGUCHI Naruhito To: ietf-pkix@imc.org Subject: Re: CRL number in CRL and ARL In-Reply-To: <27FF4FAEA8CDD211B97E00902745CBE2B417FE@seine.valicert.com> References: <27FF4FAEA8CDD211B97E00902745CBE2B417FE@seine.valicert.com> Message-Id: <20000810111811.6BBF.TAKIGUTI@fjh.se.fujitsu.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00 (beta 25) Ambarish, > If you are creating CRLs and ARLs that are not complete (i.e. > don't contain all the entries the other does), it is very > important that you use the CRLDP method of doing it. Put in > CRLDP extensions in the certificates and IDP (Issuing Distribution > Point) extensions in your CRLs/ARLs. > > If you don't use the CRLDP mechanism, you run the risk of having > a bunch of applications misbehave with your CRLs. Thank you. I agree with your advice. But, I'm going to discussion about the CRL number. I think that the method (a)(the CRL number is a sequece number for each CRL scope) is better than the method (b) for a relying party. RFC2459 and son of RFC2459 describe following : The CRL number is a non-critical CRL extension which conveys a mono- tonically increasing sequence number for each CRL issued by a CA. Does "for each CRL issued by a CA" sentence mean the method (b) ? Thanks in advance. > Regards, > Ambarish > > --------------------------------------------------------------------- > Ambarish Malpani > Architect 650.567.5457 > ValiCert, Inc. ambarish@valicert.com > 339 N. Bernardo Ave. http://www.valicert.com > Mountain View, CA 94043 > > > > -----Original Message----- > > From: TAKIGUCHI Naruhito [mailto:takiguti@fjh.se.fujitsu.co.jp] > > Sent: Tuesday, August 08, 2000 8:13 PM > > To: ietf-pkix@imc.org > > Subject: CRL number in CRL and ARL > > > > > > Hi, all. > > > > I have a question about the cRLNumber extension. > > > > For example, a CA issues CRL(end-entity certificate revocation list) > > and ARL(CA certificate revocation list). > > Which is correct (a) or (b) ? > > > > (a) In first CRL and ARL, the CRL number is 0. > > In next CRL and ARL, the CRL number is 1. > > > > In other words, CRL and ARL have same value of the CRL number. > > The CRL number is a monotonically increasing sequence number > > for each CRL scope. > > > > (b) In first CRL, the CRL Number is 0. > > In first ARL, the CRL Number is 1. > > In next CRL, the CRL number is 2. > > In next ARL, the CRL number is 3. > > > > In other words, the CRL number is monotonically increasing > > sequence number for each CA. > > > > Could anyone advice me? > > > > Thanks in advance. > > > > ----- > > Naruhito TAKIGUCHI > > FUJITSU HOKURIKU SYSTEMS LTD. > > ----- Naruhito TAKIGUCHI FUJITSU HOKURIKU SYSTEMS LTD. Received: from dcntn1.datacert.com (adsl-216-63-79-58.dsl.hstntx.swbell.net [216.63.79.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02313 for ; Wed, 9 Aug 2000 09:18:37 -0700 (PDT) From: Cole.Morgan@datacert.com Subject: To: ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: Date: Wed, 9 Aug 2000 11:21:42 -0500 X-MIMETrack: Serialize by Router on dcntn1/ORT(Release 5.0.3 |March 21, 2000) at 08/09/2000 11:21:43 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii unsubscribe ietf-pkix Cole.Morgan@datacert.com Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00900 for ; Wed, 9 Aug 2000 09:00:14 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 08:50:12 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2B417FE@seine.valicert.com> From: Ambarish Malpani To: "'TAKIGUCHI Naruhito'" , ietf-pkix@imc.org Subject: RE: CRL number in CRL and ARL Date: Wed, 9 Aug 2000 08:50:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Hi Naruhito, If you are creating CRLs and ARLs that are not complete (i.e. don't contain all the entries the other does), it is very important that you use the CRLDP method of doing it. Put in CRLDP extensions in the certificates and IDP (Issuing Distribution Point) extensions in your CRLs/ARLs. If you don't use the CRLDP mechanism, you run the risk of having a bunch of applications misbehave with your CRLs. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: TAKIGUCHI Naruhito [mailto:takiguti@fjh.se.fujitsu.co.jp] > Sent: Tuesday, August 08, 2000 8:13 PM > To: ietf-pkix@imc.org > Subject: CRL number in CRL and ARL > > > Hi, all. > > I have a question about the cRLNumber extension. > > For example, a CA issues CRL(end-entity certificate revocation list) > and ARL(CA certificate revocation list). > Which is correct (a) or (b) ? > > (a) In first CRL and ARL, the CRL number is 0. > In next CRL and ARL, the CRL number is 1. > > In other words, CRL and ARL have same value of the CRL number. > The CRL number is a monotonically increasing sequence number > for each CRL scope. > > (b) In first CRL, the CRL Number is 0. > In first ARL, the CRL Number is 1. > In next CRL, the CRL number is 2. > In next ARL, the CRL number is 3. > > In other words, the CRL number is monotonically increasing > sequence number for each CA. > > Could anyone advice me? > > Thanks in advance. > > ----- > Naruhito TAKIGUCHI > FUJITSU HOKURIKU SYSTEMS LTD. > Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA00409 for ; Wed, 9 Aug 2000 08:45:13 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 08:40:11 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2B417FC@seine.valicert.com> From: Ambarish Malpani To: "'Juergen Brauckmann'" , Denis Pinkas , Simon Tardell Cc: ietf-pkix@imc.org Subject: RE: OCSP request Date: Wed, 9 Aug 2000 08:40:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C00218.19C39976" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C00218.19C39976 Content-Type: text/plain; charset="iso-8859-1" Juergen, We did have a discussion about what kinds of questions OCSP should answer when we were writing the RFC and the concensus was that we were only providing the status of the certificate. I am including most of the mails and different points of view about this topic when the discussion was going on. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Juergen Brauckmann [mailto:brauckmann@trustcenter.de] > Sent: Wednesday, August 09, 2000 8:31 AM > To: Denis Pinkas; Simon Tardell > Cc: ietf-pkix@imc.org > Subject: Re: OCSP request > > > At 16:48 09.08.00 +0200, Denis Pinkas wrote: > >THIS IS NOT A CORRECT INQUIRY. The protocol overview says: "The > >Online Certificate Status Protocol (OCSP) enables applications to > >determine the (revocation) state of an identified certificate". Good > >means "not revoked", no less no more. Nothing about "issued" or "not > >issued". > > Well, chapter 2.2 says > The "good" state indicates a positive response to the > status inquiry. > At a minimum, this positive response indicates that the certificate > is not revoked, but does not necessarily mean that the certificate > was ever issued... > > If good never means "issued", than it should not say "At a > minimum" and > "not necessarily". > > The text may be correct, but it is possible to misinterpret it. > > >> The other is the unclear wording of unknown. > > > >This is perfectly clear. If the server says "does not know", do not > >ask for what reasons it does not know. > > It is not described in rfc2560 what the client should do if > it receives > "unknown" (try later? try another responder? Tell the user that it got > "unknown"?). It is not described when or why a server might > give "unknown". > "Don't ask" may be adequate for a client programm, but is > definitely not > adequate for people developing an OCSP responder. > > Regards, > Juergen > ------_=_NextPart_000_01C00218.19C39976 Content-Type: message/rfc822 Content-Description: Re: [IETF-PKIX] OCSP Status Information on a Certificate Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2331DD0@seine.valicert.com> From: "David P. Kemp" Sender: owner-ietf-pkix@imc.org To: "'ietf-pkix@imc.org'" Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate Date: Tue, 28 Apr 1998 12:32:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mozilla-Status: 2013 X-Sun-Charset: US-ASCII X-POP3-Rcpt: ambarish@arctic Content-Type: text/plain; charset="iso-8859-1" > From: Marc Branchaud > > So I guess (unless I've forgotten someone) that the tally now stands at: > > Issued / Revoked / Expired == 1 > Revoked only == 0 > Abstain == 1 > Add one for Revoked only, or add a new category Revoked / Expired. As before, I don't see any rationale for Issued. Expired could be useful if one assumes that the client does not have a reliable clock, that the responder does have access to a trusted time source, and that the RP uses OCSP for every verification. Last month my wife's PC started dating files sometime in 2003 for no apparent reason. The lithium battery was fine, the clock has been fine since we reset it, and the machine doesn't have a modem installed so it's never been exposed to hackers on the net. Gamma rays, I guess. Anyway, OCSP Expired status may be useful. ------_=_NextPart_000_01C00218.19C39976 Content-Type: message/rfc822 Content-Description: Re: [IETF-PKIX] OCSP Status Information on a Certificate Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2331DBD@seine.valicert.com> From: Paul Hoffman / IMC Sender: "IETF X.509-based public key infrastructure mailing list" Reply-To: "IETF X.509-based public key infrastructure mailing list" To: "'IETF-PKIX@LISTS.TANDEM.COM'" Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate Date: Fri, 17 Apr 1998 14:01:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mozilla-Status: 2011 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.327 (Beta) X-POP3-Rcpt: ambarish@arctic X-Sender: paulh@mail.imc.org Content-Type: text/plain; charset="iso-8859-1" I agree with David Kemp's analysis and take back my suggestion that wasIssued be mandatory. --Paul Hoffman, Director --Internet Mail Consortium ------_=_NextPart_000_01C00218.19C39976 Content-Type: message/rfc822 Content-Description: Re: [IETF-PKIX] OCSP Status Information on a Certificate Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2331DBC@seine.valicert.com> From: SGalperin Sender: "IETF X.509-based public key infrastructure mailing list" Reply-To: "IETF X.509-based public key infrastructure mailing list" To: "'IETF-PKIX@LISTS.TANDEM.COM'" Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate Date: Fri, 17 Apr 1998 10:54:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mozilla-Status: 2011 X-Mailer: AOL 3.0 16-bit for Windows sub 38 X-POP3-Rcpt: ambarish@arctic Content-Type: text/plain; charset="iso-8859-1" In a message dated 98-04-17 12:31:04 EDT, you write: > > At 08:48 AM 4/17/98 -0700, you wrote: > >And in the event a client receives {is revoked, not issued}, which > >dominates? Similarly, {not revoked, not issued}. I remain unconvinced > this > >is no problem. > > To the client, "not issued" is always more important than revoked or not > revoked. We can put that in the OCSP spec. > > >As soon as OCSP clients are out there in any volume, there > >are those who will seek to determine the client's behavior in fringe cases. > > I fully agree. That's why I'm I don't think that issued/not issued should > be a MAY: I think it has to be a MUST. We can be sure that some clients > will blow the comparison unless they are always told whether or not the > cert was even issued. > Are we talking about fat OCSP client here ? Does the OCSP client in this case have full certificate chain ? Can we safely assume that fat OCSP client will need to verify signatures on the chain first, validity and other X509v3 constraints and only then submit OCSP request for status of every certificate in the chain ? If this is so then, essentially, OCSP client is already in the possession of the well-formed certificate signed by the (indirectly or directly) trusted CA key. In these circumstances receiving an anwer "not issued" may only mean that CA key is compromised and "unathorized" certificate has been signed. But if someone has the CA key and can sign anything with it (including "unathorized" certificates) then that someone can also make sure that "unathorized" certificate has the same serial number as one of "authorized" and as long as we only send serial number to identify a certificate in OCSP request the substitution of the "authorized" cert with "unathorized" one will be unnoticed. This makes "never issued" somewhat useless for fat OCSP clients. Is this reasoning wrong ? Also since CA archiving capacity is always finiteand we also talking about allowing "historical" OCSP queries "never issued" will have to be replaced with "info unavailable" at least in some cases. This further redices the value of "never issued" status. --Slava Galperin ------_=_NextPart_000_01C00218.19C39976 Content-Type: message/rfc822 Content-Description: Re: [IETF-PKIX] OCSP Status Information on a Certificate Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2331DBA@seine.valicert.com> From: "David P. Kemp" Sender: "IETF X.509-based public key infrastructure mailing list" Reply-To: "IETF X.509-based public key infrastructure mailing list" To: "'IETF-PKIX@LISTS.TANDEM.COM'" Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate Date: Fri, 17 Apr 1998 10:31:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mozilla-Status: 2011 X-Sun-Charset: US-ASCII X-POP3-Rcpt: ambarish@arctic Content-Type: text/plain; charset="iso-8859-1" > From: Paul Hoffman / IMC > > To the client, "not issued" is always more important than revoked or not > revoked. We can put that in the OCSP spec. > > >As soon as OCSP clients are out there in any volume, there > >are those who will seek to determine the client's behavior in fringe cases. > > I fully agree. That's why I'm I don't think that issued/not issued should > be a MAY: I think it has to be a MUST. We can be sure that some clients > will blow the comparison unless they are always told whether or not the > cert was even issued. I disagree that an Issued bit should be a MUST. For that matter, I don't see that it even needs to be a MAY in OCSP, but others seem to want it for some reason. If you have a certificate for which the signature verifies, you have prima facie evidence that: 1) the certificate was issued, or 2) the CA's private key was compromised, or 3) the signature algorithm is broken. In the latter two cases, all bets are off and OCSP isn't going to help -- why would you trust a signed OCSP response any more than a signed certificate? In the first case, you know the answer before you even ask the question. If you have a certificate for which the signature does not verify, what are you going to do with it, regardless of OCSP's claim that it has or has not been issued? And if you don't have a certificate and are just trolling the OCSP server by issuer/serial, subject name, or some other search criteria, why should it feel obliged to disclose which guesses are valid? Dave Kemp ------_=_NextPart_000_01C00218.19C39976 Content-Type: message/rfc822 Content-Description: Re: [IETF-PKIX] OCSP Status Information on a Certificate Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2331DB9@seine.valicert.com> From: Marc Branchaud Sender: "IETF X.509-based public key infrastructure mailing list" Reply-To: "IETF X.509-based public key infrastructure mailing list" To: "'IETF-PKIX@LISTS.TANDEM.COM'" Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate Date: Fri, 17 Apr 1998 09:52:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mozilla-Status: 2011 X-Mailer: exmh version 2.0gamma 1/27/96 X-POP3-Rcpt: ambarish@arctic Content-Type: text/plain; charset="iso-8859-1" -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii Michael Myers scrawled: > > And in the event a client receives {is revoked, not issued}, which I think you mean {is revoked, issued} here... > dominates? Similarly, {not revoked, not issued}. I remain unconvinced this > is no problem. As soon as OCSP clients are out there in any volume, there > are those who will seek to determine the client's behavior in fringe cases. > I agree that the implications are not trivial. For one thing, as I've said, a responder working solely with CRL information can not determine a certificate's existance if the cert has not been revoked. One bit is not enough to capture the semantics. Marc +------------------------------------------------------------------------+ Marc Branchaud \/ Chief PKI Architect /\CERT INTERNATIONAL INC. marcnarc@xcert.com PKI References page: www.xcert.com 604-640-6227 www.xcert.com/~marcnarc/PKI/ +------------------------------------------------------------------------+ PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBNTeI3lrdFXNdDxPlAQFnJQL8Cnti/rIncZp1o3IFfy2XeZPHQXluc8FO 8+KNr2FzAJQPeXWGovrZpp+6LoMRSJ1b+TWqLMdNSqlGin/CJtx2iHg6RkWgik40 b5gADHFKTv1BratoNpS4ZB07C9rp8/3d =Rxae -----END PGP SIGNATURE----- ------_=_NextPart_000_01C00218.19C39976 Content-Type: message/rfc822 Content-Description: Re: [IETF-PKIX] OCSP Status Information on a Certificate Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2331DC3@seine.valicert.com> From: Andreas Berger Sender: owner-ietf-pkix@imc.org To: 'pkix' Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate Date: Tue, 21 Apr 1998 02:40:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mozilla-Status: 2011 X-Mailer: Mozilla 4.04 [en] (X11; U; Linux 2.0.30 i586) X-POP3-Rcpt: ambarish@arctic Content-Type: text/plain; charset="iso-8859-1" Paul Hoffman / IMC wrote: > > At 08:48 AM 4/17/98 -0700, you wrote: > >And in the event a client receives {is revoked, not issued}, which > >dominates? Similarly, {not revoked, not issued}. I remain unconvinced this > >is no problem. > > To the client, "not issued" is always more important than revoked or not > revoked. We can put that in the OCSP spec. > > >As soon as OCSP clients are out there in any volume, there > >are those who will seek to determine the client's behavior in fringe cases. > > I fully agree. That's why I'm I don't think that issued/not issued should > be a MAY: I think it has to be a MUST. We can be sure that some clients > will blow the comparison unless they are always told whether or not the > cert was even issued. > > --Paul Hoffman, Director > --Internet Mail Consortium Paul, I disagree. The issued/not issued flag can only be answered by a small set of OCSP responders. Let's take - for example - a company that operates an OCSP responder of some of the most frequently used CAs in the world. It load their CRLs to reduce communication cost and offers these "CRLs on-line" to the internal client software (thus lowering the maintainance cost to distribute CRLs to all clients). Given a specific certificate, such an OCSP responder can only answer the question of revocation (revoked/not revoked) on the basis of the CRL (so revoked is: on the list, not revoked is: not on the list). So probably we need some kind of "don't know" of the OCSP responder. Regarding the question above: when a certificate was "not issued" this is a no-go for the verification process. I think that we could drop any other answers if the certificate was never issued. This is different for "issued: don't know" and "issued: yes". Andreas -- Erst kommt das Fressen, dann kommt die Moral -- Bertolt Brecht ------_=_NextPart_000_01C00218.19C39976 Content-Type: message/rfc822 Content-Description: Re: [IETF-PKIX] OCSP Status Information on a Certificate Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2331DB2@seine.valicert.com> From: Denis Pinkas Sender: "IETF X.509-based public key infrastructure mailing list" Reply-To: Denis.Pinkas@bull.net To: "'IETF-PKIX@LISTS.TANDEM.COM'" Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate Date: Fri, 17 Apr 1998 14:26:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mozilla-Status: 2011 X-Mailer: Mozilla 3.01 [fr] (Win16; I) X-POP3-Rcpt: ambarish@arctic Content-Type: text/plain; charset="iso-8859-1" Andreas, Your conclusion is: " I think we should not restrict OCSP in its semantics to CRL like semantics." I may agree with this. However, I think we should not mandate more than what is available by access to CRL information only. This means that we have to distinguish between a set of mandatory status and a set of optional status. > > Ambarish Malpani wrote: > > > > > Here is a list of the different kinds of status information that an OCSP > > > responder may want to return: > > > > > > 1. Revocation status of a certificate > > > - revoked > > > - on hold > > > - not revoked > > > - don't know about this CA > > > - know about this CA, but not about this cert (??? I am not sure I > > > think this state should ever be returned, but this corresponds > > > to the state where the responder is looking up the CA's database > > > and can't find this entry in the database. Mike, I believe you > > > think this is an important state - is that correct?) > > > > The later would mean that the OCSP responder has access to more > > information than just the CRL. I do not think that this response > > usefull for the client. If there were good arguments for keeping it (I > > have not been convinced by the arguments from Paul), then this status > > should be optional (no guarantee to get it back at any time). > > Sorry that I bring that up again: the answer about knowing about a CA > but not about the referenced certificate would be a good one for use of > OCSP in the German Signature Law, where such a service is required. As long as this is optional. > Short overview: When asking a CA for the status of a certificate, it > answer with two booleans: certificate was issued / was not issued and > certifcate is revoked / is not revoked (the latter only when the > certificate was issued). The signature key is related to the CA but is > not the CAs certifcate signing key. More exactly: it MUST issue one booolean : certificate is revoked / is not revoked it MAY issue another boolean: certificate was issued / was not issued > What we then need is a clarification between "not revoked": Let us > assume that an OCSP responder answers with "not revoked" based on a > decision of a CRLs where the certificate is NOT listed. This is a > different answer from "not revoked and I know about the certificate", > perhaps looked up on a CA database (see 3). > > > > 2. Expiration status of a certificate > > > - not yet valid (will be valid in the future) > > > - valid (in its validity period) > > > - expired > > > - don't know about the expiration status > > I think we have to rephrase that: not yet valid - certificate validity > period begins after the designated point in time. We will have to support some date as originally requested by Stephen. > > > 3. Issued status of the certificate > > > - never issued (no cert with this serial number was ever issued by > > > this CA) > > > - issued > > > - don't know if it was ever issued > > > > > My take on this issue: I believe OCSP is just a revocation status > > > protocol, so we should restrict the return status to just revoked, > > > onHold, notRevoked, and dontKnowAboutThisCA. This would leave the > > > syntax of the protocol simple and the semantics very clear - OCSP > > > basically returns the same information that you would get if you > > > had a CRL from the CA at the instant of the response (NOTE: I am > > > NOT implying that a CRL is ever issued). > > > > Agreed. Let us keep it simple. > > I think we should not restrict OCSP in its semantics to CRL like > semantics. > > Andreas See above. Regards, Denis -- Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net 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 ------_=_NextPart_000_01C00218.19C39976 Content-Type: message/rfc822 Content-Description: Re: [IETF-PKIX] OCSP Status Information on a Certificate Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2331DA4@seine.valicert.com> From: Marc Branchaud Sender: "IETF X.509-based public key infrastructure mailing list" Reply-To: "IETF X.509-based public key infrastructure mailing list" To: "'IETF-PKIX@LISTS.TANDEM.COM'" Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate Date: Tue, 14 Apr 1998 15:29:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mozilla-Status: 2011 X-Mailer: exmh version 2.0gamma 1/27/96 X-POP3-Rcpt: ambarish@arctic Content-Type: text/plain; charset="iso-8859-1" -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii Michael Myers scrawled: > > A related question: > > Given Marc's proposal for separate fields, should we provide guidance > towards the uniform resolution of ambiguous states in a multi-valued > response? I'm concerned about this protocol otherwise introducing into > clients exploitable behavior caused by less than full coverage of error > cases. > That's a valid concern, and I believe some guidance is required. As a start, it might help to list those combinations which should be considerd as malformed. First, recall the three status vectors: Revocation Status Expiration Status Issued Status ----------------- ----------------- ------------- revoked not yet valid issued on hold valid never issued not revoked expired unknown unknown CA unknown unknown cert - If Issued Status is "never issued" then the revocation status MUST be "unknown cert" and the expiration status MUST be "unknown", otherwise the response is malformed. If the responder knows that the cert was never issued, then the other values are indeterminable. Note that a responder can't determine if a certificate was never issued using only CRLs, so a responder working with CRLs only will never create a "never issued" response. - If Issued Status is "unknown" then the response is well-formed only if the revocation status is either "not revoked" or "unknown CA". This is because if the cert is "revoked" or "on hold" then it is listed in a CRL, and so the responder knows the cert was issued regardless of whether it is using CRLs or has direct access to the CA's database. Also, if Issued Status is "unknown" then "unknown cert" implies "unknown CA". Either the responder couldn't find a CRL or database for the cert's CA, or the responder has a CRL from the CA but the cert isn't listed (so it's really "not revoked"). - If Issued Status is "issued" then use the following table to determine if the response is malformed ("bad") or acceptable ("OK"). Revocation ||----------------- Expiration status --------------- status || not yet valid | valid | expired | unknown =============||=================|=========|===========|=========== revoked || OK | OK | OK | OK on hold || bad | OK | OK | OK not revoked || OK | OK | OK | OK unknown CA || bad | bad | bad | bad unknown cert || bad | bad | bad | bad The only way for a responder to know with any certainty that a cert has been issued is if it has direct access to the CA's database or if the cert is listed on a CRL. In either case, responding with "unknown CA" or "unknown cert" would be wrong. "Unknown cert" would really mean "never issued" (if the responder had direct access to a CA's database) or "not revoked" (if the responder were using CRLs). Also, I don't believe that a cert would be marked "on hold" before it became valid. Either it wouldn't appear on a CRL, or it wouldn't be marked as "on hold" in the CA's database. Hence the single "bad" entry in the "on hold" row. I'm willing to admit I'm wrong, though. "On hold" has always been a semantic riddle to me... All of this is only to determine if the client should reject a response out of hand. The behaviour of a client upon accepting a response -- whether or not it should accept the cert -- is a matter for the client's local policies. One thing this exercise has showed me is that "unknown cert" is really a useless response value, since it is either bogus or subsumed by other values (like "unknown CA"). Marc +------------------------------------------------------------------------+ Marc Branchaud \/ Chief PKI Architect /\CERT INTERNATIONAL INC. marcnarc@xcert.com PKI References page: www.xcert.com 604-640-6227 www.xcert.com/~marcnarc/PKI/ +------------------------------------------------------------------------+ PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBNTPjPlrdFXNdDxPlAQFtiQL/RRrfIPdX245xSp8YfQXWrj3s7bI4TuYA oyjziEucd8gRIUPPs10xro4WqFgbxBNNQs5B1L1JE2KIyc4DRBitIaTP32pjBDBg qrvistWEbGn8/SkpUtVswVaEVpRavpJh =TIKb -----END PGP SIGNATURE----- ------_=_NextPart_000_01C00218.19C39976 Content-Type: message/rfc822 Content-Description: [IETF-PKIX] OCSP Status Information on a Certificate Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2331D8E@seine.valicert.com> From: Ambarish Malpani Sender: "IETF X.509-based public key infrastructure mailing list" Reply-To: "IETF X.509-based public key infrastructure mailing list" To: "'IETF-PKIX@LISTS.TANDEM.COM'" Subject: [IETF-PKIX] OCSP Status Information on a Certificate Date: Mon, 13 Apr 1998 18:04:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mozilla-Status: 8001 X-Mailer: Mozilla 4.01 [en] (WinNT; U) X-POP3-Rcpt: ambarish@arctic Content-Type: text/plain; charset="iso-8859-1" Here is a list of the different kinds of status information that an OCSP responder may want to return: 1. Revocation status of a certificate - revoked - on hold - not revoked - don't know about this CA - know about this CA, but not about this cert (??? I am not sure I think this state should ever be returned, but this corresponds to the state where the responder is looking up the CA's database and can't find this entry in the database. Mike, I believe you think this is an important state - is that correct?) 2. Expiration status of a certificate - not yet valid (will be valid in the future) - valid (in its validity period) - expired - don't know about the expiration status 3. Issued status of the certificate - never issued (no cert with this serial number was ever issued by this CA) - issued - don't know if it was ever issued My take on this issue: I believe OCSP is just a revocation status protocol, so we should restrict the return status to just revoked, onHold, notRevoked and dontKnowAboutThisCA. This would leave the syntax of the protocol simple and the semantics very clear - OCSP basically returns the same information that you would get if you had a CRL from the CA at the instant of the response (NOTE: I am NOT implying that a CRL is ever issued). However, if the consensus of the group is that it is important that all three types of states be returned, I would prefer there to be 3 separate state fields, one for each of the different statii. This would allow us to add more states in the future (e.g. whether this certificate can be used for a specific kind of operation, or maybe some information about the CA of this cert) without affecting these basic status fields. What do the rest of you on the list feel about this issue: - Should OCSP support one or more of these statuses? - If we support multiple of these states, should we define separate fields, or should we merge all states into one field? Ambarish -- --------------------------------------------------------------------- Ambarish Malpani Architect (650) 849-9880 ValiCert, Inc. ambarish@valicert.com 3160 W. Bayshore Road http://www.valicert.com Palo Alto, CA 94303 ------_=_NextPart_000_01C00218.19C39976-- Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29725 for ; Wed, 9 Aug 2000 08:36:30 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 08:31:29 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2B417FB@seine.valicert.com> From: Ambarish Malpani To: "'Denis Pinkas'" , Simon Tardell Cc: ietf-pkix@imc.org Subject: RE: OCSP request Date: Wed, 9 Aug 2000 08:31:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" I agree completely. Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: Wednesday, August 09, 2000 7:48 AM > To: Simon Tardell > Cc: ietf-pkix@imc.org > Subject: Re: OCSP request > > > Simon, > > > > I do no think that any "clarification" is needed for RFC 2560 to > > > this respect. The text is crystal clear and does not need to be > > > changed. > > > > With the risk or reiterating myself, I must insist that the > wording of > > RFC2560 is not clear. > > With the risk of repeating myself, I must insist that the wording of > RFC2560 is crystal clear. > > > There are two problems. One is that the ternary > > certificate status (good, revoked, unknown) is not > orthogonal, i.e. good is > > not equivalent to !revoked. To dissect it: > > > > 'The "good" state indicates a positive response to the > status inquiry.' -- > > so if the status inquiry was "is this certificate not > revoked and issued" > > THIS IS NOT A CORRECT INQUIRY. The protocol overview says: "The > Online Certificate Status Protocol (OCSP) enables applications to > determine the (revocation) state of an identified certificate". Good > means "not revoked", no less no more. Nothing about "issued" or "not > issued". > > > and the certificate was not revoked and not issued, "good" > would not be > > correct. But clearly, "revoked" would not either. Note that > it does not say > > "to the revocation inquiry". > > > > 'At a minimum, this positive response indicates that the > certificate is not > > revoked, but does not necessarily mean that the certificate > was ever issued > > or that the time at which the response was produced is within the > > certificate's validity interval.' -- yes, but the "minimum" > answer is only > > reasonable if you don't ask (by request extensions or by > convention) for any > > further assertions. To put it in other words, the responder > is required by > > the protocol to make an assertion on the revocation status. > > > > 'Response extensions may be used to convey additional information on > > assertions made by the responder regarding the status of > the certificate > > such as positive statement about issuance, validity, etc.' > -- what about > > negative assertions on the same properties? Lack of the > same extension in > > the response? > > > > How would you suggest to signal "this certificate is not > revoked, but it has > > never been issued"? > > Very easy answer: > The current status means "this certificate is not revoked". > In an extension you can say whatever ADDITIONAL other information > you want (including "issued, never issued"). > > > The other is the unclear wording of unknown. > > This is perfectly clear. If the server says "does not know", do not > ask for what reasons it does not know. > > > "doesn't know about the > > certificate requested" is in ISIS an assertion that the > responder knows the > > certificate was never issued. Clearly, there seems to be > differences in this > > group about this. And the different interpretation of > "unknown" makes > > difference for the behaviour of the OCSP client. If > "unknown" means that > > some property of the certificate is bad (like in ISIS the issuance) > > processing stops there. But if it means that this responder > is unable or > > unwilling to answer your question about this specific > certificate (for > > whatever reason) maybe you can try another responder, or > the same responder > > later. > > > > I am not primarily after defining any extensions for extra > assertions in the > > base protocol. > > > > I want to push out any assertions about other properties than > > revocation status from CertStatus into extensions. > CertStatus should, in my > > mind, take one of "not revoked", "revoked" and "don't know". > > Good. So we strongly agree on this. > > > However, it does seem to me that many things you'd want to > ask an OCSP > > responder have the same response structure as revocation > ("good", "bad", > > "don't know"), so it could be beneficiary to define a > common type for > > representing that kind of assertions. > > Forget the "However, ..." and the rest of the text, since as > indicated above, we strongly agree. > > Regards, > > Denis > > > Simon. > > > > Simon Tardell, Software Architect, iD2 Technologies > > voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 > > simon.tardell@iD2tech.com, http://www.iD2tech.com > > Securing the Internet economy > Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA27919 for ; Wed, 9 Aug 2000 08:28:07 -0700 (PDT) Received: by mystic1.trustcenter.de; id RAA27766; Wed, 9 Aug 2000 17:29:36 +0200 Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma027758; Wed, 9 Aug 00 17:28:53 +0200 Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id RAA05330; Wed, 9 Aug 2000 17:30:35 +0200 (MET DST) Message-Id: <3.0.5.32.20000809173037.04582580@localhost> X-Sender: jbr@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Aug 2000 17:30:37 +0200 To: Denis Pinkas , Simon Tardell From: Juergen Brauckmann Subject: Re: OCSP request Cc: ietf-pkix@imc.org In-Reply-To: <39916F2D.8DFF9FAA@bull.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 16:48 09.08.00 +0200, Denis Pinkas wrote: >THIS IS NOT A CORRECT INQUIRY. The protocol overview says: "The >Online Certificate Status Protocol (OCSP) enables applications to >determine the (revocation) state of an identified certificate". Good >means "not revoked", no less no more. Nothing about "issued" or "not >issued". Well, chapter 2.2 says The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued... If good never means "issued", than it should not say "At a minimum" and "not necessarily". The text may be correct, but it is possible to misinterpret it. >> The other is the unclear wording of unknown. > >This is perfectly clear. If the server says "does not know", do not >ask for what reasons it does not know. It is not described in rfc2560 what the client should do if it receives "unknown" (try later? try another responder? Tell the user that it got "unknown"?). It is not described when or why a server might give "unknown". "Don't ask" may be adequate for a client programm, but is definitely not adequate for people developing an OCSP responder. Regards, Juergen Received: from kevin.feste.es ([194.143.203.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22129 for ; Wed, 9 Aug 2000 08:04:12 -0700 (PDT) Received: from oficina (ladra.feste.es [194.143.203.155]) by kevin.feste.es (8.9.3/8.9.3) with SMTP id RAA18222 for ; Wed, 9 Aug 2000 17:10:08 +0200 Message-ID: <002f01c00214$9a79d110$0a02a8c0@interno> From: "Oscar Conesa" To: Subject: CP & CPS in CertificatePolicies Extension Date: Wed, 9 Aug 2000 17:15:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Hi, We are creating templates to certificates and we have some questions about the CertificatePolicies Extension. We have a general CPS and several particular Certificate Policy, one CP for every type of certificate. CPS -> http://www.feste.com/rep/cps.html (Not published yet) OID: 1.3.6.1.4.1.5239.1 CP1, Personal Certificates http://www.feste.com/rep/cp1.html (Not published yet) OID: 1.3.6.1.4.1.5239.2.1 (Why not?) CP2, Web Certificates http://www.feste.com/rep/cp2.html (Not published yet) OID: 1.3.6.1.4.1.5239.2.2 And others CPs ..... We have a hierarchy with a Root CA (version 1) and one Subordinate CA for every type of certificate. What is the best implementation of CertificatePolicies Extension? This is a good solution?: --------------------------- Subordinate CA --------------------------- certificatePolicies PolicyInformation policyIdentifier 1.3.6.1.4.1.5239.2.1 policyQualifiers PolicyQualifierInfo policyQualifierId id-qt-cps; qualifier cPSuri http://www.feste.com/rep/cps.html PolicyQualifierInfo policyQualifierId id-qt-cps; qualifier cPSuri http://www.feste.com/rep/cp1.html ------------------------- User ------------------------- certificatePolicies PolicyInformation policyIdentifier 1.3.6.1.4.1.5239.1 policyQualifiers PolicyQualifierInfo policyQualifierId id-qt-unotice; qualifier userNotice "Certificado Reconocido segun el Real Decreto Ley de Firma Electronica 14/1999 ...... " PolicyQualifierInfo policyQualifierId id-qt-cps; qualifier cPSuri http://www.feste.com/rep/cps.html PolicyQualifierInfo policyQualifierId id-qt-cps; qualifier cPSuri http://www.feste.com/rep/cp1.html Thank you very much for your help Oscar Conesa Dtor Tecnico de FESTE Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20176 for ; Wed, 9 Aug 2000 07:44:33 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA33836; Wed, 9 Aug 2000 16:52:59 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA41842; Wed, 9 Aug 2000 16:48:16 +0200 Message-ID: <39916F2D.8DFF9FAA@bull.net> Date: Wed, 09 Aug 2000 16:48:13 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Simon Tardell CC: ietf-pkix@imc.org Subject: Re: OCSP request References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Simon, > > I do no think that any "clarification" is needed for RFC 2560 to > > this respect. The text is crystal clear and does not need to be > > changed. > > With the risk or reiterating myself, I must insist that the wording of > RFC2560 is not clear. With the risk of repeating myself, I must insist that the wording of RFC2560 is crystal clear. > There are two problems. One is that the ternary > certificate status (good, revoked, unknown) is not orthogonal, i.e. good is > not equivalent to !revoked. To dissect it: > > 'The "good" state indicates a positive response to the status inquiry.' -- > so if the status inquiry was "is this certificate not revoked and issued" THIS IS NOT A CORRECT INQUIRY. The protocol overview says: "The Online Certificate Status Protocol (OCSP) enables applications to determine the (revocation) state of an identified certificate". Good means "not revoked", no less no more. Nothing about "issued" or "not issued". > and the certificate was not revoked and not issued, "good" would not be > correct. But clearly, "revoked" would not either. Note that it does not say > "to the revocation inquiry". > > 'At a minimum, this positive response indicates that the certificate is not > revoked, but does not necessarily mean that the certificate was ever issued > or that the time at which the response was produced is within the > certificate's validity interval.' -- yes, but the "minimum" answer is only > reasonable if you don't ask (by request extensions or by convention) for any > further assertions. To put it in other words, the responder is required by > the protocol to make an assertion on the revocation status. > > 'Response extensions may be used to convey additional information on > assertions made by the responder regarding the status of the certificate > such as positive statement about issuance, validity, etc.' -- what about > negative assertions on the same properties? Lack of the same extension in > the response? > > How would you suggest to signal "this certificate is not revoked, but it has > never been issued"? Very easy answer: The current status means "this certificate is not revoked". In an extension you can say whatever ADDITIONAL other information you want (including "issued, never issued"). > The other is the unclear wording of unknown. This is perfectly clear. If the server says "does not know", do not ask for what reasons it does not know. > "doesn't know about the > certificate requested" is in ISIS an assertion that the responder knows the > certificate was never issued. Clearly, there seems to be differences in this > group about this. And the different interpretation of "unknown" makes > difference for the behaviour of the OCSP client. If "unknown" means that > some property of the certificate is bad (like in ISIS the issuance) > processing stops there. But if it means that this responder is unable or > unwilling to answer your question about this specific certificate (for > whatever reason) maybe you can try another responder, or the same responder > later. > > I am not primarily after defining any extensions for extra assertions in the > base protocol. > I want to push out any assertions about other properties than > revocation status from CertStatus into extensions. CertStatus should, in my > mind, take one of "not revoked", "revoked" and "don't know". Good. So we strongly agree on this. > However, it does seem to me that many things you'd want to ask an OCSP > responder have the same response structure as revocation ("good", "bad", > "don't know"), so it could be beneficiary to define a common type for > representing that kind of assertions. Forget the "However, ..." and the rest of the text, since as indicated above, we strongly agree. Regards, Denis > Simon. > > Simon Tardell, Software Architect, iD2 Technologies > voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 > simon.tardell@iD2tech.com, http://www.iD2tech.com > Securing the Internet economy Received: from dcntn1.datacert.com (adsl-216-63-79-58.dsl.hstntx.swbell.net [216.63.79.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19157 for ; Wed, 9 Aug 2000 07:35:58 -0700 (PDT) From: Cole.Morgan@datacert.com Subject: To: ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: Date: Wed, 9 Aug 2000 09:44:05 -0500 X-MIMETrack: Serialize by Router on dcntn1/ORT(Release 5.0.3 |March 21, 2000) at 08/09/2000 09:44:07 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii UNSUBSCRIBE Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA16935 for ; Wed, 9 Aug 2000 06:57:50 -0700 (PDT) Received: FROM aunt15.ausys.se BY naigwy ; Wed Aug 09 15:59:48 2000 +0200 Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 16:01:28 +0200 Message-ID: From: Simon Tardell To: "'Denis Pinkas'" , Simon Tardell Cc: ietf-pkix@imc.org Subject: RE: OCSP request Date: Wed, 9 Aug 2000 16:01:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" > I do no think that any "clarification" is needed for RFC 2560 to > this respect. The text is crystal clear and does not need to be > changed. With the risk or reiterating myself, I must insist that the wording of RFC2560 is not clear. There are two problems. One is that the ternary certificate status (good, revoked, unknown) is not orthogonal, i.e. good is not equivalent to !revoked. To dissect it: 'The "good" state indicates a positive response to the status inquiry.' -- so if the status inquiry was "is this certificate not revoked and issued" and the certificate was not revoked and not issued, "good" would not be correct. But clearly, "revoked" would not either. Note that it does not say "to the revocation inquiry". 'At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval.' -- yes, but the "minimum" answer is only reasonable if you don't ask (by request extensions or by convention) for any further assertions. To put it in other words, the responder is required by the protocol to make an assertion on the revocation status. 'Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate such as positive statement about issuance, validity, etc.' -- what about negative assertions on the same properties? Lack of the same extension in the response? How would you suggest to signal "this certificate is not revoked, but it has never been issued"? The other is the unclear wording of unknown. "doesn't know about the certificate requested" is in ISIS an assertion that the responder knows the certificate was never issued. Clearly, there seems to be differences in this group about this. And the different interpretation of "unknown" makes difference for the behaviour of the OCSP client. If "unknown" means that some property of the certificate is bad (like in ISIS the issuance) processing stops there. But if it means that this responder is unable or unwilling to answer your question about this specific certificate (for whatever reason) maybe you can try another responder, or the same responder later. I am not primarily after defining any extensions for extra assertions in the base protocol. I want to push out any assertions about other properties than revocation status from CertStatus into extensions. CertStatus should, in my mind, take one of "not revoked", "revoked" and "don't know". However, it does seem to me that many things you'd want to ask an OCSP responder have the same response structure as revocation ("good", "bad", "don't know"), so it could be beneficiary to define a common type for representing that kind of assertions. Simon. Simon Tardell, Software Architect, iD2 Technologies voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 simon.tardell@iD2tech.com, http://www.iD2tech.com Securing the Internet economy Received: from irwell.zetnet.co.uk (root@irwell.zetnet.co.uk [194.247.47.48]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA09118 for ; Wed, 9 Aug 2000 05:06:26 -0700 (PDT) Received: from jeffdavis (man-a081.dialup.zetnet.co.uk [194.247.44.81]) by irwell.zetnet.co.uk (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA31966; Wed, 9 Aug 2000 13:09:53 +0100 X-Authentication-Warning: irwell.zetnet.co.uk: Host man-a081.dialup.zetnet.co.uk [194.247.44.81] claimed to be jeffdavis Message-ID: <00f001c001fa$91b3b7e0$512cf7c2@zetnet.co.uk> From: "Jeff Davis" To: "Heimberg, Jim" , "PKIX-List" References: <2575327B6755D211A0E100805F9FF954050805C4@ndhmex02.ndhm.gsc.gte.com> Subject: Re: Digital Signatures - Legal Advice Wanted Date: Wed, 9 Aug 2000 11:52:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Jim, I agree with your point here. If a person is given a certificate and set of keys which can then be used to sign for and on behalf of the company then that should be binding against the company and not the individual. The DN should reflect the position of authority within the company, including the individuals name for accountability etc. When the person leaves the company the certificate gets revoked, probably better than chopping off the hands of the person leaving! some people continue to recognise hand written signatures long after their authority has expired ). Cheers Jeff Davis ----- Original Message ----- From: Heimberg, Jim To: 'Tony Bartoletti' ; Adrian McCullagh ; 'Anders Rundgren' ; PKIX-List Sent: Monday, August 07, 2000 7:43 PM Subject: RE: Digital Signatures - Legal Advice Wanted > Just to add to the confusion, is there no allowance for designating the > personality as the role that person fills? For instance, if you wanted as a > CA to grant a signature and encryption key and the requisite authority to > the Chief Financial Officer of a small company (e.g., Acme Electrical > Supply) for purchasing as required, why can you not issue a certificate to > cfo@acmeelectric.com (and if you need to personalize it, you could add the > person's name or initials after the CFO designation)? > > -----Original Message----- > From: Tony Bartoletti [mailto:azb@llnl.gov] > Sent: Monday, August 07, 2000 2:21 PM > To: Adrian McCullagh; 'Anders Rundgren'; PKIX-List > Subject: RE: Digital Signatures - Legal Advice Wanted > > > At 07:00 AM 8/7/00 +1000, Adrian McCullagh wrote: > > >In Common law countries like the USA, Australia, UK and Canada, there > >is a doctrine known as ostensible authority. This provides that if a > >person signs a document on behalf of another legal entity (the > >principal) and the signer has some external reasonably perceived > >authority such that a reasonable person looking at the transaction > >objectively would believe that such person through his/her position > >had such authority to bind the principal then the principal is bound > >by the signers action. > > > >So as I see it, a director could digitally sign the digital document > >using the directors own personal private key and as part of the text > >of the document state the following word "signed for and on behalf of > >Company XXXX". This would indicate to the world that the signer is > >NOT signing the digital document so as to be personally bound but is > >signing as an agent and as such is attempting to bind the principal > >(company). > > (Please correct me, Anders, if I am mistaken, but) I believe the > issue is a little different than Adrian supposes. > > Rather than have a (company) individual sign on behalf of > "the company", I believe that the issue is whether a company > (ok, an individual acting on behalf of the company if you must) > can hold "customer's keys" and apply "customer's signatures", > given some trail of evidence that the customer, on a case-by- > case basis, has authorized that their signature be affixed to > a given transaction. > > The primary goal being to keep the customer's "secret keys" > in an environment more secure than the customer may be expected > to maintain. > > (The legal precedent for this might be "power of attorney"?) > > If I'm wrong ... nevermind :) > > ___tony___ > > >The recipient would on receipt verify the digital signature using the > >signer's personal certificate that has the public key embodied in it. > >If the recipient is concerned about the authority then the recipient > >can check the company records to determine if the signer has the > >necessary implied/ostensible authority. To accelerate the process of > >verification of authority there may be some solution in the use of > >role based certificates or attribute certificates but I have not > >really give this issue sufficient thought. > > > >If there is still some doubt then the recipient can always check with > >the Company secretary or the Managing director as to such authority. > > > >The Uniform Electronic Transactions Act that is forming part of the > >Uniform Commercial Code of various US States does anticipate software > >agents and thus server based organisation digital signatures. > > > >But there are no cases that specifically deal with your issue. > > > >The simple solution is for a company officer to digitally sign the > >digital document and affix the words noted above in the text prior to > >digitally signing. > > > >I hope this is helpful. > > > > > >Adrian McCullagh > >Director of Electronic CommerceTel: 617 3231 1522 > >Gadens Lawyers Fax: 617 3229 5850 > >level 39 > >Central Plaza 1 > >345 Queen Street > >Brisbane Australia 4000 > > > >Ph. D. Candidate > >Thesis "The Incorporation of Trust Strategies in Digital Signature > >Regimes for Elec. Comm." > >Information Security Research Centre > >Queensland University of Technology > > > > > > > >- -----Original Message----- > >From: Anders Rundgren [ mailto:anders.rundgren@telia.com] > >Sent: Monday, August 07, 2000 6:58 AM > >To: PKIX-List > >Subject: Digital Signatures - Legal Advice Wanted > > > > > >Hi, > >I am working with an e-commerce standard that features server-based, > >organization-signed orders. > > > >However, server-based, organization-oriented digital signatures do > >currently not, to the my knowledge, > >have explicit support in any legal system. How to solve this? One > >way (the current one) is to state > >in separate agreements between the trading partners, that you will > >stand by these signatures in court. > > > >I wonder if there could be a more general solution like: A company > >officer digitally signs (using a personal > >certificate), a document where he/she states that signatures > >associated with a certain trading partner > >certificate are to be considered as legally binding from the company's > >point of view. > >Such a document is preferably published on the company's home-page for > >easy reference. > > > >How does this sound in the ears of lawyers? > > > >regards > >Anders Rundgren > > > > > > > >-----BEGIN PGP SIGNATURE----- > >Version: PGP Personal Edition 6.0.2 > > > >iQA/AwUBOY1FTJWt1NGjt4vzEQLdmACeJiR1FMKZ//6Mtfq+v5DfAGGo/q4AoJoM > >bWjrz+F/Xll2zwotTzuligVm > >=sEx7 > >-----END PGP SIGNATURE----- > > Tony Bartoletti 925-422-3881 > Information Operations, Warfare and Assurance Center > Lawrence Livermore National Laboratory > Livermore, CA 94551-9900 > Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA28649 for ; Wed, 9 Aug 2000 02:34:39 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA13486; Wed, 9 Aug 2000 11:43:04 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA37880; Wed, 9 Aug 2000 11:38:21 +0200 Message-ID: <3991268E.7AEA413D@bull.net> Date: Wed, 09 Aug 2000 11:38:22 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Simon Tardell CC: ietf-pkix@imc.org Subject: Re: OCSP request References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Simon, > All, > > we have gone quite far from my original question, whether it is possible to > clarify RFC2560 in such a way that ISIS semantics (and others) can be > expressed in a clean way, adding to, not altering, the base semantics. I do no think that any "clarification" is needed for RFC 2560 to this respect. The text is crystal clear and does not need to be changed. The text says for the "good status": " The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval. Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate such as positive statement about issuance, validity, etc. It is thus clear that extensions may carry any additional semantics or fields. Such extensions may be defined using: requestExtensions [2] EXPLICIT Extensions OPTIONAL in an OCSPRequest, or using: responseExtensions [1] EXPLICIT Extensions OPTIONAL in an OCSPResponse (more exactly in ResponseData). If someone has some interest for some extension, it should be defined in a *separate* document and then proposed to the PKIX working group either to be on the standard track, being informational or being experimental. Denis > The > purpose being that OCSP clients should be able to be clients to both > "ordinary" PKIs and ISIS model PKIs. > > The discussion about whether there are other ways of meeting the design > goals of the ISIS model is of course interesting, but I'm not sure how much > that can be done about the model at this stage. Much of this model is set > already in the underlying laws and regulations, and I suppose those are not > going to change much in this respect. > > Simon. > > Simon Tardell, Software Architect, iD2 Technologies > voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 > simon.tardell@iD2tech.com, http://www.iD2tech.com > Securing the Internet economy Received: from getafix.fcpl.co.in (getafix.fcpl.co.in [196.1.104.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA26184 for ; Wed, 9 Aug 2000 02:07:57 -0700 (PDT) Received: from SHANTANU ([196.1.104.102]) by getafix.fcpl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QGR5LC7Y; Wed, 9 Aug 2000 14:44:33 +0530 Message-ID: <01e001c001e3$3e7f2da0$666801c4@fcpl.co.in> From: "Shantanu Bhattacharya" To: References: Subject: Keeping track of the history of secure operations Date: Wed, 9 Aug 2000 14:51:46 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 I was wondering if there is any way one can keep track of the history of secure operations done on a document in such a way as to be auditable at a later point in time. If anybody has any solution to this, please let me know. Regards Shantanu Bhattacharya Project Manager E-Lock Technologies Pvt. Ltd. Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA22206 for ; Wed, 9 Aug 2000 01:15:24 -0700 (PDT) Received: FROM aunt15.ausys.se BY naigwy ; Wed Aug 09 10:17:20 2000 +0200 Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 10:19:00 +0200 Message-ID: From: Simon Tardell To: "'Juergen Brauckmann'" , Ambarish Malpani Cc: ietf-pkix@imc.org Subject: RE: OCSP request Date: Wed, 9 Aug 2000 10:18:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" > >P.S. What is the status of the ISIS solution? Is it already a > >"rule/law"? Is it open to review/comments/suggestions? > > ISIS is an interop specification by 9 German CAs (no, we > currently don't > make laws;-). All, we have gone quite far from my original question, whether it is possible to clarify RFC2560 in such a way that ISIS semantics (and others) can be expressed in a clean way, adding to, not altering, the base semantics. The purpose being that OCSP clients should be able to be clients to both "ordinary" PKIs and ISIS model PKIs. The discussion about whether there are other ways of meeting the design goals of the ISIS model is of course interesting, but I'm not sure how much that can be done about the model at this stage. Much of this model is set already in the underlying laws and regulations, and I suppose those are not going to change much in this respect. Simon. Simon Tardell, Software Architect, iD2 Technologies voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 simon.tardell@iD2tech.com, http://www.iD2tech.com Securing the Internet economy Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA04463 for ; Tue, 8 Aug 2000 20:09:07 -0700 (PDT) Received: from m3.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0006-Fujitsu Gateway) id MAA06225 for ; Wed, 9 Aug 2000 12:12:41 +0900 (JST) (envelope-from takiguti@fjh.se.fujitsu.co.jp) Received: from nic10.fjh.se.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.9.3/3.7W-0008-Fujitsu Domain Master) id MAA02775; Wed, 9 Aug 2000 12:12:40 +0900 (JST) Received: from anakin (anakin.fjh.se.fujitsu.co.jp [10.131.201.130]) by nic10.fjh.se.fujitsu.co.jp (8.9.3+3.2W/3.7W) with ESMTP id MAA15687 for ; Wed, 9 Aug 2000 12:12:38 +0900 (JST) Date: Wed, 09 Aug 2000 12:12:38 +0900 From: TAKIGUCHI Naruhito To: ietf-pkix@imc.org Subject: CRL number in CRL and ARL Message-Id: <20000809113001.6155.TAKIGUTI@fjh.se.fujitsu.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00 (beta 25) Hi, all. I have a question about the cRLNumber extension. For example, a CA issues CRL(end-entity certificate revocation list) and ARL(CA certificate revocation list). Which is correct (a) or (b) ? (a) In first CRL and ARL, the CRL number is 0. In next CRL and ARL, the CRL number is 1. In other words, CRL and ARL have same value of the CRL number. The CRL number is a monotonically increasing sequence number for each CRL scope. (b) In first CRL, the CRL Number is 0. In first ARL, the CRL Number is 1. In next CRL, the CRL number is 2. In next ARL, the CRL number is 3. In other words, the CRL number is monotonically increasing sequence number for each CA. Could anyone advice me? Thanks in advance. ----- Naruhito TAKIGUCHI FUJITSU HOKURIKU SYSTEMS LTD. Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA04873 for ; Tue, 8 Aug 2000 08:15:51 -0700 (PDT) Received: by mystic1.trustcenter.de; id RAA19583; Tue, 8 Aug 2000 17:17:37 +0200 Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma019581; Tue, 8 Aug 00 17:17:10 +0200 Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id RAA09410; Tue, 8 Aug 2000 17:18:53 +0200 (MET DST) Message-Id: <3.0.5.32.20000808171854.04523b20@localhost> X-Sender: jbr@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 08 Aug 2000 17:18:54 +0200 To: Ambarish Malpani From: Juergen Brauckmann Subject: RE: OCSP request Cc: ietf-pkix@imc.org In-Reply-To: <27FF4FAEA8CDD211B97E00902745CBE2B4175A@seine.valicert.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sorry for the late reply... . At 07:44 27.07.00 -0700, Ambarish Malpani wrote: >Hi Juergen, > Originally, OCSP had the following states (I do this from >memory, so I might be a little off): Thank you. >P.S. What is the status of the ISIS solution? Is it already a >"rule/law"? Is it open to review/comments/suggestions? ISIS is an interop specification by 9 German CAs (no, we currently don't make laws;-). I can send you a .pdf... . Regards, Juergen Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA00116 for ; Tue, 8 Aug 2000 07:30:55 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Tue, 8 Aug 2000 07:25:49 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2B417E4@seine.valicert.com> From: Ambarish Malpani To: "'Denis Pinkas'" , Irene Gassko Cc: ietf-pkix@imc.org Subject: The real topic has nothing to do with: Re: OCSP request Date: Tue, 8 Aug 2000 07:25:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Denis, It isn't to one's "best" knowledge, but to one's "actual" knowledge, if I remember Radia's presentation at the SACRED/SAAG groups correctly :-) Ambarish P.S. I wonder what people think about having a lawyer come and address us at IETF to explain "true English" to us! --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: Tuesday, August 08, 2000 5:48 AM > To: Irene Gassko > Cc: ietf-pkix@imc.org > Subject: Re: OCSP request > > > Irene, > > > Steve, > > > > Thanks a lot for this clarification. > > > > In fact, making signatures optional is not needed for our scheme > > to work, I only mentioned it for efficiency reason. Like Richard > > and Tony suggested it may work independently without disturbing > > current implementations. It can provide a fallback support for CA > > key change, for example, especially if this change is a result of > > a private key compromise. Actually, I mentioned our solution in > > Simple non-technical question. Is -to your own best knowledge- this > scheme patented ? > > Thanks, > > Denis Received: from dvnet8.dvnet.com ([209.121.31.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24547 for ; Tue, 8 Aug 2000 06:11:40 -0700 (PDT) Received: from CC787228-A (cc787228-a.hwrd1.md.home.com [24.180.131.6]) by dvnet8.dvnet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QK5F0JA5; Tue, 8 Aug 2000 09:18:36 -0400 Received: by localhost with Microsoft MAPI; Tue, 8 Aug 2000 09:16:35 -0400 Message-ID: <01C00119.59D0CC00.aarsenault@dvnet.com> From: Al Arsenault To: "'Irene Gassko'" Cc: "ietf-pkix@imc.org" Subject: RE: OCSP request Date: Tue, 8 Aug 2000 09:16:34 -0400 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 207 TEXT Irene Gassko wrote: So, it looks like efficiency really depends on how those certificates are used. This part I'll agree with completely! As experience has shown repeatedly, there's no "one best way" that always gives best performance from a PKI implementation. It's a function of what application(s) you're trying to support, what risks you're willing to take, what your constraints are in terms of time, money, and technology, and a lot of other things, besides. I guess I started this by using the term "normal processing mode", so I'll attempt to clarify - in some environments - e.g., where certificates are being used to sign, encrypt, and verify e-mail messages - the approach suggested by Irene seems to me to be less efficient than the approaches currently defined in PKIX today, and in more-or-less common use. In other environments, the approach she suggested MAY be more efficient, depending on a lot of the factors identified above. Some specific comments in-line: -----Original Message----- From: Irene Gassko [SMTP:gassko@lucent.com] Sent: Tuesday, August 08, 2000 8:19 AM To: Al Arsenault Cc: ietf-pkix@imc.org Subject: RE: OCSP request At 10:45 AM 08/07/2000 -0400, Al Arsenault wrote: >The problem with this scheme is that, even if it does help with archiving >and recovery in the case of CA key compromise, it doesn't help in the >normal certificate processing operations. > >With a certificate signed by a CA, I know that "the CA has vouched for the >correctness of each of the data items in this certificate", subject to the >normal discussions on how thoroughly the CA has verified them, yada, yada, >yada. > >With a certificate not being signed, or being signed by the originator, I >just know that I have a data structure, and I'm not sure about the CA's >willingness to vouch for those items, until such time as I go fetch the >signed Merkle tree that pertains and verify it, recursively to where I get >to a trusted root. That is, I don't know if I have a complete spoof >attempt, a corrupted cert, or anything else, until such time as I do the >"revocation check". > >So it seems to me that in the normal processing mode, this proposal is >actually somewhat *less* efficient than the current scheme, where I can do >some checks on the cert BEFORE I fetch the CRL or ping the OCSP responder, >and thus not even bother with revocation checking on things that have >already failed. > This is absolutely correct if you only want to check one individual certificate, do not care about the possibility of revocation much and are not worried about potential CA key compromise. Yes, and also if you trust directories to tell you truthfully whether they have a particular certificate you are looking for. AWA: I disagree to a greater or lesser extent with every clause in this paragraph. The number of certificates does not have to be one; "small" for appropriate values of that word will suffice. "Do not care about the possibility of revocation much" - huh? Where did that come from? I pointed out that sometimes you're going to reject a putative cert even BEFORE you check revocation status; e.g., because it got garbled in transit and thus the signature fails. Why does "reject because the signature failed before I ever bothered to check revocation" equal "don't care about revocation"? "Are not worried about potential CA key compromise" - bear in mind that there are a lot of factors that come into play if a CA key has been compromised. Thus, making a decision to accept a certificate originally signed with a key known to have been compromised requires a lot of consideration. If you are checking a number of certificates from the same CA (say, Visa cards) then you only need to check one signature and a few hashes, which is much more efficient then checking a signature from every certificate. You can even check that signature in advance, for example a vendor can do it outside of rush hours and then only a few hashes need to be computed: this is more efficient than verifying a signature each time. If your certificate is your credit card and today is your shopping day, you can prefetch verification path to speed up approval for your purchases (in this case I assume it to be a smartcard, as is common in Europe). AWA: yes, for this environment, the approach you suggest may be more efficient than the traditional one. Besides efficiency issues there are other properties that a current scheme does not possess. For example, if a CA key gets silently compromised, and a certificate is forged quietly, with the current technology there is no way to discover that a certificate is fake. However, in our scheme, in order to fabricate a certificate, the root value of the Merkle tree has to be altered, which will be too conspicuous to miss. AWA: forgive me if I get the technology wrong - I have some familiarity with Merkle trees, but I'm certainly no expert on them. However, as I understand the technology proposed, every time the CA issues a new legitimate certificate, the root value has to be altered. In any kind of dynamic environment - e.g., certificates issued every few (seconds, minutes, hours,...), new certs are issued and thus the root value has to change regularly. Thus, the event "root value altered because of a fake cert signed by a compromised key" is very difficult to distinguish from "root value altered because of legitimate cert signed by the real CA", EXCEPT to the CA itself. Yes, if the CA is "eternally vigilant", you might catch this happening, but then again you might not. And another property. Even though directories are supposed to be untrusted (or we would not need a CA signature at all), if we are looking for a certificate, we are willing to believe that a particular certificate is not in the directory, on the directory's say so. Our approach allows you get a get a proof that this directory really does not possess a cert you are looking for. No more trust needed for untrusted directories. AWA: If the directory tries to say "I have some certs, but not the one for which you're looking", your approach works. If the directory says "I have no certs at all", your approach provides the same results as the previous approach. About which "attack" do you care? So, it looks like efficiency really depends on how those certificates are used. Irene > Al Arsenault > Chief Security Architect > Diversinet Corp. > > >-----Original Message----- >From: Irene Gassko [SMTP:gassko@lucent.com] >Sent: Monday, August 07, 2000 10:20 AM >To: Stephen Kent >Cc: ietf-pkix@imc.org >Subject: RE: OCSP request > >Steve, > >You are right and I know that currently signatures are mandatory. >But making changes in order to solve serious problems is a part >of the standards process, isn't it? A lot of discussion in this >group is devoted to suggested improvements in the standard. If >making signatures optional can help with CA key change and cert >archiving, would not it be a good idea to allow such usage (as in >MAY)? > >Irene > >At 05:55 PM 08/06/2000 -0400, Stephen Kent wrote: >>Irene, >> >> >> >> >>>The main idea is to eliminate signatures in certificates and have CA >>>sign a Merkle tree of certificates instead. Then CA key compromise >>>requires the change in that signature (which can be downloaded >separately) >>>but leaves cards and certificates unperturbed. You can use multiple >>>signatures with different signature algorithms and keep keys on different >>>continents if you wish. This scheme also helps with archiving. And you do >not >>>need a CRL. It can be used with X.509 certificates, making the signature >>>on a certificate optional, rather than mandatory. Or you can make it >>>an owner's signature instead of a CA's signature. >> >>Irrespective of the merit of the approach to which you allude, the >>result would not be an X.509 cert. Signatures are mandatory, not >>optional, in the format that is the basis of this WG's activity. >> >>Steve > >------------------------------------------------------------------------ >---- >------------------------------------------------------- >Irene Gassko Bell Laboratories http://www.lucent.com >Lucent Technologies Secure Technologies Dept. >1600 Osgood Street phone: (978) 960-5767 >Room 30-2-A31 e-mail: gassko@lucent.com >N. Andover, MA 01845 fax: (978) 960-3240 ------------------------------------------------------------------------ ---- ------------------------------------------------------- Irene Gassko Bell Laboratories http://www.lucent.com Lucent Technologies Secure Technologies Dept. 1600 Osgood Street phone: (978) 960-5767 Room 30-2-A31 e-mail: gassko@lucent.com N. Andover, MA 01845 fax: (978) 960-3240 Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA23464 for ; Tue, 8 Aug 2000 05:44:16 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA15706; Tue, 8 Aug 2000 14:52:34 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA16070; Tue, 8 Aug 2000 14:47:53 +0200 Message-ID: <3990017A.8C0A578A@bull.net> Date: Tue, 08 Aug 2000 14:47:54 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Irene Gassko CC: ietf-pkix@imc.org Subject: Re: OCSP request References: <4.1.20000807101230.03173400@anuxc.mv.lucent.com> <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> <4.1.20000807101230.03173400@anuxc.mv.lucent.com> <4.1.20000808082030.03559e48@anuxc.mv.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Irene, > Steve, > > Thanks a lot for this clarification. > > In fact, making signatures optional is not needed for our scheme > to work, I only mentioned it for efficiency reason. Like Richard > and Tony suggested it may work independently without disturbing > current implementations. It can provide a fallback support for CA > key change, for example, especially if this change is a result of > a private key compromise. Actually, I mentioned our solution in Simple non-technical question. Is -to your own best knowledge- this scheme patented ? Thanks, Denis > the course of an archiving discussion, as a way to protect against > keys being discovered and signature schemes being broken in > the future. > > Irene > > At 09:07 PM 08/07/2000 -0400, Stephen Kent wrote: > >Irene, > > > >>Steve, > >> > >>You are right and I know that currently signatures are mandatory. > >>But making changes in order to solve serious problems is a part > >>of the standards process, isn't it? A lot of discussion in this > >>group is devoted to suggested improvements in the standard. If > >>making signatures optional can help with CA key change and cert > >>archiving, would not it be a good idea to allow such usage (as in > >>MAY)? > > > >The charter of this WG is to profile X.509, which includes the > >syntax, processing, and underlying models for PKI. Interoperability > >is a primary thrust of the work. The change you suggest would not be > >backward compatible with X.509, or with any of the previous PKIX > >syntax, so it's hard to imagine making such a change. Even a MAY > >would break existing implementations. > > > >Steve > > ---------------------------------------------------------------------------- > ------------------------------------------------------- > Irene Gassko Bell Laboratories http://www.lucent.com > Lucent Technologies Secure Technologies Dept. > 1600 Osgood Street phone: (978) 960-5767 > Room 30-2-A31 e-mail: gassko@lucent.com > N. Andover, MA 01845 fax: (978) 960-3240 Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA22217 for ; Tue, 8 Aug 2000 05:28:00 -0700 (PDT) Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA00192 for ; Tue, 8 Aug 2000 08:32:12 -0400 (EDT) Received: from anuxc.mv.lucent.com (h135-13-160-12.lucent.com [135.13.160.12]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA00176; Tue, 8 Aug 2000 08:32:11 -0400 (EDT) Received: from irene by anuxc.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA00777; Tue, 8 Aug 2000 08:29:30 -0400 (EDT) Message-Id: <4.1.20000808082030.03559e48@anuxc.mv.lucent.com> X-Sender: irg@anuxc.mv.lucent.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 08 Aug 2000 08:32:29 -0400 To: Stephen Kent From: Irene Gassko Subject: RE: OCSP request Cc: ietf-pkix@imc.org In-Reply-To: References: <4.1.20000807101230.03173400@anuxc.mv.lucent.com> <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> <4.1.20000807101230.03173400@anuxc.mv.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Steve, Thanks a lot for this clarification. In fact, making signatures optional is not needed for our scheme to work, I only mentioned it for efficiency reason. Like Richard and Tony suggested it may work independently without disturbing current implementations. It can provide a fallback support for CA key change, for example, especially if this change is a result of a private key compromise. Actually, I mentioned our solution in the course of an archiving discussion, as a way to protect against keys being discovered and signature schemes being broken in the future. Irene At 09:07 PM 08/07/2000 -0400, Stephen Kent wrote: >Irene, > >>Steve, >> >>You are right and I know that currently signatures are mandatory. >>But making changes in order to solve serious problems is a part >>of the standards process, isn't it? A lot of discussion in this >>group is devoted to suggested improvements in the standard. If >>making signatures optional can help with CA key change and cert >>archiving, would not it be a good idea to allow such usage (as in >>MAY)? > >The charter of this WG is to profile X.509, which includes the >syntax, processing, and underlying models for PKI. Interoperability >is a primary thrust of the work. The change you suggest would not be >backward compatible with X.509, or with any of the previous PKIX >syntax, so it's hard to imagine making such a change. Even a MAY >would break existing implementations. > >Steve ---------------------------------------------------------------------------- ------------------------------------------------------- Irene Gassko Bell Laboratories http://www.lucent.com Lucent Technologies Secure Technologies Dept. 1600 Osgood Street phone: (978) 960-5767 Room 30-2-A31 e-mail: gassko@lucent.com N. Andover, MA 01845 fax: (978) 960-3240 Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA20620 for ; Tue, 8 Aug 2000 05:15:05 -0700 (PDT) Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA20608 for ; Tue, 8 Aug 2000 08:19:17 -0400 (EDT) Received: from anuxc.mv.lucent.com (h135-13-160-12.lucent.com [135.13.160.12]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA20544; Tue, 8 Aug 2000 08:19:13 -0400 (EDT) Received: from irene by anuxc.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA00470; Tue, 8 Aug 2000 08:16:31 -0400 (EDT) Message-Id: <4.1.20000808073706.0365aeb0@anuxc.mv.lucent.com> X-Sender: irg@anuxc.mv.lucent.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 08 Aug 2000 08:19:29 -0400 To: Al Arsenault From: Irene Gassko Subject: RE: OCSP request Cc: "ietf-pkix@imc.org" In-Reply-To: <01C0005C.A43805A0.aarsenault@dvnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 10:45 AM 08/07/2000 -0400, Al Arsenault wrote: >The problem with this scheme is that, even if it does help with archiving >and recovery in the case of CA key compromise, it doesn't help in the >normal certificate processing operations. > >With a certificate signed by a CA, I know that "the CA has vouched for the >correctness of each of the data items in this certificate", subject to the >normal discussions on how thoroughly the CA has verified them, yada, yada, >yada. > >With a certificate not being signed, or being signed by the originator, I >just know that I have a data structure, and I'm not sure about the CA's >willingness to vouch for those items, until such time as I go fetch the >signed Merkle tree that pertains and verify it, recursively to where I get >to a trusted root. That is, I don't know if I have a complete spoof >attempt, a corrupted cert, or anything else, until such time as I do the >"revocation check". > >So it seems to me that in the normal processing mode, this proposal is >actually somewhat *less* efficient than the current scheme, where I can do >some checks on the cert BEFORE I fetch the CRL or ping the OCSP responder, >and thus not even bother with revocation checking on things that have >already failed. > This is absolutely correct if you only want to check one individual certificate, do not care about the possibility of revocation much and are not worried about potential CA key compromise. Yes, and also if you trust directories to tell you truthfully whether they have a particular certificate you are looking for. If you are checking a number of certificates from the same CA (say, Visa cards) then you only need to check one signature and a few hashes, which is much more efficient then checking a signature from every certificate. You can even check that signature in advance, for example a vendor can do it outside of rush hours and then only a few hashes need to be computed: this is more efficient than verifying a signature each time. If your certificate is your credit card and today is your shopping day, you can prefetch verification path to speed up approval for your purchases (in this case I assume it to be a smartcard, as is common in Europe). Besides efficiency issues there are other properties that a current scheme does not possess. For example, if a CA key gets silently compromised, and a certificate is forged quietly, with the current technology there is no way to discover that a certificate is fake. However, in our scheme, in order to fabricate a certificate, the root value of the Merkle tree has to be altered, which will be too conspicuous to miss. And another property. Even though directories are supposed to be untrusted (or we would not need a CA signature at all), if we are looking for a certificate, we are willing to believe that a particular certificate is not in the directory, on the directory's say so. Our approach allows you get a get a proof that this directory really does not possess a cert you are looking for. No more trust needed for untrusted directories. So, it looks like efficiency really depends on how those certificates are used. Irene > Al Arsenault > Chief Security Architect > Diversinet Corp. > > >-----Original Message----- >From: Irene Gassko [SMTP:gassko@lucent.com] >Sent: Monday, August 07, 2000 10:20 AM >To: Stephen Kent >Cc: ietf-pkix@imc.org >Subject: RE: OCSP request > >Steve, > >You are right and I know that currently signatures are mandatory. >But making changes in order to solve serious problems is a part >of the standards process, isn't it? A lot of discussion in this >group is devoted to suggested improvements in the standard. If >making signatures optional can help with CA key change and cert >archiving, would not it be a good idea to allow such usage (as in >MAY)? > >Irene > >At 05:55 PM 08/06/2000 -0400, Stephen Kent wrote: >>Irene, >> >> >> >> >>>The main idea is to eliminate signatures in certificates and have CA >>>sign a Merkle tree of certificates instead. Then CA key compromise >>>requires the change in that signature (which can be downloaded >separately) >>>but leaves cards and certificates unperturbed. You can use multiple >>>signatures with different signature algorithms and keep keys on different >>>continents if you wish. This scheme also helps with archiving. And you do >not >>>need a CRL. It can be used with X.509 certificates, making the signature >>>on a certificate optional, rather than mandatory. Or you can make it >>>an owner's signature instead of a CA's signature. >> >>Irrespective of the merit of the approach to which you allude, the >>result would not be an X.509 cert. Signatures are mandatory, not >>optional, in the format that is the basis of this WG's activity. >> >>Steve > >------------------------------------------------------------------------ >---- >------------------------------------------------------- >Irene Gassko Bell Laboratories http://www.lucent.com >Lucent Technologies Secure Technologies Dept. >1600 Osgood Street phone: (978) 960-5767 >Room 30-2-A31 e-mail: gassko@lucent.com >N. Andover, MA 01845 fax: (978) 960-3240 ---------------------------------------------------------------------------- ------------------------------------------------------- Irene Gassko Bell Laboratories http://www.lucent.com Lucent Technologies Secure Technologies Dept. 1600 Osgood Street phone: (978) 960-5767 Room 30-2-A31 e-mail: gassko@lucent.com N. Andover, MA 01845 fax: (978) 960-3240 Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA09884 for ; Mon, 7 Aug 2000 18:06:31 -0700 (PDT) Received: from [128.33.238.46] (TC046.BBN.COM [128.33.238.46]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id VAA21255; Mon, 7 Aug 2000 21:10:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4.1.20000807101230.03173400@anuxc.mv.lucent.com> References: <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> <4.1.20000807101230.03173400@anuxc.mv.lucent.com> Date: Mon, 7 Aug 2000 21:07:19 -0400 To: Irene Gassko From: Stephen Kent Subject: RE: OCSP request Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Irene, >Steve, > >You are right and I know that currently signatures are mandatory. >But making changes in order to solve serious problems is a part >of the standards process, isn't it? A lot of discussion in this >group is devoted to suggested improvements in the standard. If >making signatures optional can help with CA key change and cert >archiving, would not it be a good idea to allow such usage (as in >MAY)? The charter of this WG is to profile X.509, which includes the syntax, processing, and underlying models for PKI. Interoperability is a primary thrust of the work. The change you suggest would not be backward compatible with X.509, or with any of the previous PKIX syntax, so it's hard to imagine making such a change. Even a MAY would break existing implementations. Steve Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA05479 for ; Mon, 7 Aug 2000 14:12:43 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 07 Aug 2000 15:16:17 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 07 Aug 2000 15:16:12 -0600 From: "Bob Jueneman" To: , , Subject: RE: Digital Signatures - Legal Advice Wanted Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA05483 And I completely agree with Adrian's comments, at least from the perspective of what I would do if I wanted to be sure that a given transaction WOULD be binding. But as an attorney once told me when I proposed using PKI some 7 or 8 years ago, "I only have two concerns with respect to this new technology. The first is that it won't be binding when I want it to be. And the second is that it will be binding when I don't want it to be!" So if you want to be sure that a signed transaction will almost surely be binding, do what Adrian suggests. On the other hand, if you are concerned that one of your employees might set up a server, create or go get a certificate, and start signing code or who knows what, and that his actions MIGHT be held to be binding against your company without your CFO or General Counsel even being aware of an obligation, then you might well have reason to worry, and you might want take positive steps to bring that situation under control. Murphy's law hasn't been repealed, and the one time that something will be found to be binding is when you least want it to be! Bob >>> Adrian McCullagh 08/07/00 02:24PM >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear All I agree with Bob's analysis. For a non lawyer Bob usually hits the legal target with accurate precision. My previous comments were generally conservative but as I am lawyer practising in this area I view things with from the position of: - "what can go wrong in a legal sense". I agree with Bob that through a course of trade such communications will certainly have a strong evidential bearing upon any case and thus the issues may be "downhill" from there. But one transaction without complaint may not be sufficient. It may take a number of transactions without complaint before a course of trade can be established. If the transaction is not insubstantial then my conservative approach is from a risk management point of view probably the safest position to take. Adrian McCullagh Director of Electronic CommerceTel: 617 3231 1522 Gadens Lawyers Fax: 617 3229 5850 level 39 Central Plaza 1 345 Queen Street Brisbane Australia 4000 Ph. D. Candidate Thesis "The Incorporation of Trust Strategies in Digital Signature Regimes for Elec. Comm." Information Security Research Centre Queensland University of Technology - -----Original Message----- From: Bob Jueneman [mailto:bjueneman@novell.com] Sent: Tuesday, August 08, 2000 1:29 AM To: AMcCullagh@exchange.gadens.com.au; ietf-pkix@imc.org; anders.rundgren@telia.com Subject: RE: Digital Signatures - Legal Advice Wanted Anders, I am not an attorney (IANA), but I would suggest that Adrian has expressed a generally conservative view that would constitute good defensive legal practice, but may leave the impression that without going through all of these steps, the transaction would presumably not be valid. But there is a different danger, and that is that transactions that are digitally signed using a key that is apparently under the control of the corporation or organization, might very well be held to be binding even without an explicit confirmation. In other words, I would suggest that Adrian's recommendations would almost certainly be sufficient, but they may not be necessary. Even though both the US and Australia are Common Law countries, there may be differences in the degree to which what Adrian refers to as ostensible authority is accepted. My understanding is that in the US, the concept is fairly widely applied, in order to facilitate commerce. The closest analog I can think of to the corporate digital signature is the mechanical signature plate that is used to sign corporate checks. Yes, because of the paper world precedents, the signature is a facsimile of the treasurer's manual signature, and the words on the paper indicate that he is causing his signature to be affixed to that check as a agent of the corporation. But do you think that any recipient of such a check actually bothers to verify that the signature really is that of the treasurer, or that the treasurer has been authorized to sign checks by the Board of Directors? No way! In simple language, apply the duck test: If something looks like a duck, walks like a duck, and quacks like a duck, it probably is a duck. In the case of a check, it was preprinted with the name of the corporation, it was presumably tendered as a result of some consideration, debt, or other obligation (it didn't just fall out of the sky), and to all intents and purposes it appears to be in order. Reliance on that treasurer's ostensible authority would certainly be quite reasonable. (Note that there is no claim being made that the check was a forgery, which would be a different matter.) So if I launch my browser to www.amazon.com, I see all sorts of stuff appear on my screen that would be consistent with the fact that I was connected to amazon, and the lock icon confirms that an SSL session has been established with a server, on which a private key has apparently been installed that corresponds to a public key certificate issued by a reputable CA (one whose root I have accepted), then I have every right to believe that I am communicating with a server that is controlled by amazon. Granted, an SSL connection does not provide nonrepudiation for a particular transaction. But supposing that I enter my credit card number or other personal information over that session, and later I can establish that that information was not handled properly. Could I sue amazon for not protecting my information adequately, and be successful? Almost certainly, even without the www.amazon.com certificate. Certainly no judge in the US would dismiss such a suite because I failed to provide satisfactory evidence that the Board of Directors of amazon had in fact properly authorized the IT department to acquire a certificate, set up a server to conduct business, etc. In this case, it sure sounds like a duck. I suspect that your server-based organizational orders would fall into the same situation. And in particular, once the first such transaction has been accepted without complaint, it is all downhill from there, since the commercial practice would then be increasingly well-established. Regards, Bob >>> Adrian McCullagh 08/06/00 03:00PM >>> - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Anders In the paper based environment a company does not have its own signature. Companies are artificial legal entities and as such can only act through human agents. (Now this may change through the use of software agents but that is another issue). Hence for a company to be bound to a commercial transaction the human agent must have some authority either implied or express. A person digitally signing a digital document that attempts to bind a company should use their own private key for such action. The issue then revolves around the concept of authority. If the signer does not have the appropriate authority then the signer may be liable for "Breach of Warranty of Authority". If the signer has express authority to sign the document and thus bind the principal then the issue is simple. In Common law countries like the USA, Australia, UK and Canada, there is a doctrine known as ostensible authority. This provides that if a person signs a document on behalf of another legal entity (the principal) and the signer has some external reasonably perceived authority such that a reasonable person looking at the transaction objectively would believe that such person through his/her position had such authority to bind the principal then the principal is bound by the signers action. So as I see it, a director could digitally sign the digital document using the directors own personal private key and as part of the text of the document state the following word "signed for and on behalf of Company XXXX". This would indicate to the world that the signer is NOT signing the digital document so as to be personally bound but is signing as an agent and as such is attempting to bind the principal (company). The recipient would on receipt verify the digital signature using the signer's personal certificate that has the public key embodied in it. If the recipient is concerned about the authority then the recipient can check the company records to determine if the signer has the necessary implied/ostensible authority. To accelerate the process of verification of authority there may be some solution in the use of role based certificates or attribute certificates but I have not really give this issue sufficient thought. If there is still some doubt then the recipient can always check with the Company secretary or the Managing director as to such authority. The Uniform Electronic Transactions Act that is forming part of the Uniform Commercial Code of various US States does anticipate software agents and thus server based organisation digital signatures. But there are no cases that specifically deal with your issue. The simple solution is for a company officer to digitally sign the digital document and affix the words noted above in the text prior to digitally signing. I hope this is helpful. Adrian McCullagh Director of Electronic CommerceTel: 617 3231 1522 Gadens Lawyers Fax: 617 3229 5850 level 39 Central Plaza 1 345 Queen Street Brisbane Australia 4000 Ph. D. Candidate Thesis "The Incorporation of Trust Strategies in Digital Signature Regimes for Elec. Comm." Information Security Research Centre Queensland University of Technology - - -----Original Message----- From: Anders Rundgren [ mailto:anders.rundgren@telia.com] Sent: Monday, August 07, 2000 6:58 AM To: PKIX-List Subject: Digital Signatures - Legal Advice Wanted Hi, I am working with an e-commerce standard that features server-based, organization-signed orders. However, server-based, organization-oriented digital signatures do currently not, to the my knowledge, have explicit support in any legal system. How to solve this? One way (the current one) is to state in separate agreements between the trading partners, that you will stand by these signatures in court. I wonder if there could be a more general solution like: A company officer digitally signs (using a personal certificate), a document where he/she states that signatures associated with a certain trading partner certificate are to be considered as legally binding from the company's point of view. Such a document is preferably published on the company's home-page for easy reference. How does this sound in the ears of lawyers? regards Anders Rundgren - -----BEGIN PGP SIGNATURE----- Version: PGP Personal Edition 6.0.2 iQA/AwUBOY1FTJWt1NGjt4vzEQLdmACeJiR1FMKZ//6Mtfq+v5DfAGGo/q4AoJoM bWjrz+F/Xll2zwotTzuligVm =sEx7 - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: PGP Personal Edition 6.0.2 iQA/AwUBOY6Oc5Wt1NGjt4vzEQIjpgCfZQpuuUxCJZwQbXJ0qxTBiV78qBkAoLpy ZH9cgCYkemF3Ca4D4nYjLNMF =XCG7 -----END PGP SIGNATURE----- Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA04659 for ; Mon, 7 Aug 2000 13:33:03 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id NAA07790; Mon, 7 Aug 2000 13:36:35 -0700 (PDT) Message-Id: <4.2.2.20000807134117.00aea580@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 07 Aug 2000 13:45:01 -0700 To: "Anders Rundgren" , "Bob Jueneman" , From: Tony Bartoletti Subject: Re: Digital Signatures - Legal Advice Wanted In-Reply-To: <002801c000b0$13f8a400$0201a8c0@mega.vincent.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:43 PM 8/7/00 +0200, you wrote: >Bob, > > > >I suspect that your server-based organizational orders would fall into > the same situation. > >And in particular, once the first such transaction has been accepted > without complaint, > >it is all downhill from there, since the commercial practice would then > be increasingly > >well-established. > >To me this is not downhill, this is just great and I believe that you are >completely correct in your >pragmatic view on how things actually work! In spite of signature laws... :) I think Bob used "downhill" in the sense of "easy" rather than "retrograde". The term can be used in both positive and negative ways... ___tony___ Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 Received: from hamster.gadens.com.au (root@dns.gadens.com.au [203.32.220.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03803 for ; Mon, 7 Aug 2000 13:16:44 -0700 (PDT) Received: from exchange.gadens.com.au ([10.1.8.3]) by hamster.gadens.com.au (8.9.3/8.9.3) with ESMTP id GAA21075; Tue, 8 Aug 2000 06:20:40 +1000 (EST) (envelope-from AMcCullagh@exchange.gadens.com.au) Received: by exchange.gadens.com.au with Internet Mail Service (5.5.2650.21) id <3YWS6818>; Tue, 8 Aug 2000 06:24:54 +1000 Message-ID: From: Adrian McCullagh To: "'Bob Jueneman'" , ietf-pkix@imc.org, anders.rundgren@telia.com Subject: RE: Digital Signatures - Legal Advice Wanted Date: Tue, 8 Aug 2000 06:24:50 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear All I agree with Bob's analysis. For a non lawyer Bob usually hits the legal target with accurate precision. My previous comments were generally conservative but as I am lawyer practising in this area I view things with from the position of: - "what can go wrong in a legal sense". I agree with Bob that through a course of trade such communications will certainly have a strong evidential bearing upon any case and thus the issues may be "downhill" from there. But one transaction without complaint may not be sufficient. It may take a number of transactions without complaint before a course of trade can be established. If the transaction is not insubstantial then my conservative approach is from a risk management point of view probably the safest position to take. Adrian McCullagh Director of Electronic CommerceTel: 617 3231 1522 Gadens Lawyers Fax: 617 3229 5850 level 39 Central Plaza 1 345 Queen Street Brisbane Australia 4000 Ph. D. Candidate Thesis "The Incorporation of Trust Strategies in Digital Signature Regimes for Elec. Comm." Information Security Research Centre Queensland University of Technology - -----Original Message----- From: Bob Jueneman [mailto:bjueneman@novell.com] Sent: Tuesday, August 08, 2000 1:29 AM To: AMcCullagh@exchange.gadens.com.au; ietf-pkix@imc.org; anders.rundgren@telia.com Subject: RE: Digital Signatures - Legal Advice Wanted Anders, I am not an attorney (IANA), but I would suggest that Adrian has expressed a generally conservative view that would constitute good defensive legal practice, but may leave the impression that without going through all of these steps, the transaction would presumably not be valid. But there is a different danger, and that is that transactions that are digitally signed using a key that is apparently under the control of the corporation or organization, might very well be held to be binding even without an explicit confirmation. In other words, I would suggest that Adrian's recommendations would almost certainly be sufficient, but they may not be necessary. Even though both the US and Australia are Common Law countries, there may be differences in the degree to which what Adrian refers to as ostensible authority is accepted. My understanding is that in the US, the concept is fairly widely applied, in order to facilitate commerce. The closest analog I can think of to the corporate digital signature is the mechanical signature plate that is used to sign corporate checks. Yes, because of the paper world precedents, the signature is a facsimile of the treasurer's manual signature, and the words on the paper indicate that he is causing his signature to be affixed to that check as a agent of the corporation. But do you think that any recipient of such a check actually bothers to verify that the signature really is that of the treasurer, or that the treasurer has been authorized to sign checks by the Board of Directors? No way! In simple language, apply the duck test: If something looks like a duck, walks like a duck, and quacks like a duck, it probably is a duck. In the case of a check, it was preprinted with the name of the corporation, it was presumably tendered as a result of some consideration, debt, or other obligation (it didn't just fall out of the sky), and to all intents and purposes it appears to be in order. Reliance on that treasurer's ostensible authority would certainly be quite reasonable. (Note that there is no claim being made that the check was a forgery, which would be a different matter.) So if I launch my browser to www.amazon.com, I see all sorts of stuff appear on my screen that would be consistent with the fact that I was connected to amazon, and the lock icon confirms that an SSL session has been established with a server, on which a private key has apparently been installed that corresponds to a public key certificate issued by a reputable CA (one whose root I have accepted), then I have every right to believe that I am communicating with a server that is controlled by amazon. Granted, an SSL connection does not provide nonrepudiation for a particular transaction. But supposing that I enter my credit card number or other personal information over that session, and later I can establish that that information was not handled properly. Could I sue amazon for not protecting my information adequately, and be successful? Almost certainly, even without the www.amazon.com certificate. Certainly no judge in the US would dismiss such a suite because I failed to provide satisfactory evidence that the Board of Directors of amazon had in fact properly authorized the IT department to acquire a certificate, set up a server to conduct business, etc. In this case, it sure sounds like a duck. I suspect that your server-based organizational orders would fall into the same situation. And in particular, once the first such transaction has been accepted without complaint, it is all downhill from there, since the commercial practice would then be increasingly well-established. Regards, Bob >>> Adrian McCullagh 08/06/00 03:00PM >>> - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Anders In the paper based environment a company does not have its own signature. Companies are artificial legal entities and as such can only act through human agents. (Now this may change through the use of software agents but that is another issue). Hence for a company to be bound to a commercial transaction the human agent must have some authority either implied or express. A person digitally signing a digital document that attempts to bind a company should use their own private key for such action. The issue then revolves around the concept of authority. If the signer does not have the appropriate authority then the signer may be liable for "Breach of Warranty of Authority". If the signer has express authority to sign the document and thus bind the principal then the issue is simple. In Common law countries like the USA, Australia, UK and Canada, there is a doctrine known as ostensible authority. This provides that if a person signs a document on behalf of another legal entity (the principal) and the signer has some external reasonably perceived authority such that a reasonable person looking at the transaction objectively would believe that such person through his/her position had such authority to bind the principal then the principal is bound by the signers action. So as I see it, a director could digitally sign the digital document using the directors own personal private key and as part of the text of the document state the following word "signed for and on behalf of Company XXXX". This would indicate to the world that the signer is NOT signing the digital document so as to be personally bound but is signing as an agent and as such is attempting to bind the principal (company). The recipient would on receipt verify the digital signature using the signer's personal certificate that has the public key embodied in it. If the recipient is concerned about the authority then the recipient can check the company records to determine if the signer has the necessary implied/ostensible authority. To accelerate the process of verification of authority there may be some solution in the use of role based certificates or attribute certificates but I have not really give this issue sufficient thought. If there is still some doubt then the recipient can always check with the Company secretary or the Managing director as to such authority. The Uniform Electronic Transactions Act that is forming part of the Uniform Commercial Code of various US States does anticipate software agents and thus server based organisation digital signatures. But there are no cases that specifically deal with your issue. The simple solution is for a company officer to digitally sign the digital document and affix the words noted above in the text prior to digitally signing. I hope this is helpful. Adrian McCullagh Director of Electronic CommerceTel: 617 3231 1522 Gadens Lawyers Fax: 617 3229 5850 level 39 Central Plaza 1 345 Queen Street Brisbane Australia 4000 Ph. D. Candidate Thesis "The Incorporation of Trust Strategies in Digital Signature Regimes for Elec. Comm." Information Security Research Centre Queensland University of Technology - - -----Original Message----- From: Anders Rundgren [ mailto:anders.rundgren@telia.com] Sent: Monday, August 07, 2000 6:58 AM To: PKIX-List Subject: Digital Signatures - Legal Advice Wanted Hi, I am working with an e-commerce standard that features server-based, organization-signed orders. However, server-based, organization-oriented digital signatures do currently not, to the my knowledge, have explicit support in any legal system. How to solve this? One way (the current one) is to state in separate agreements between the trading partners, that you will stand by these signatures in court. I wonder if there could be a more general solution like: A company officer digitally signs (using a personal certificate), a document where he/she states that signatures associated with a certain trading partner certificate are to be considered as legally binding from the company's point of view. Such a document is preferably published on the company's home-page for easy reference. How does this sound in the ears of lawyers? regards Anders Rundgren - -----BEGIN PGP SIGNATURE----- Version: PGP Personal Edition 6.0.2 iQA/AwUBOY1FTJWt1NGjt4vzEQLdmACeJiR1FMKZ//6Mtfq+v5DfAGGo/q4AoJoM bWjrz+F/Xll2zwotTzuligVm =sEx7 - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: PGP Personal Edition 6.0.2 iQA/AwUBOY6Oc5Wt1NGjt4vzEQIjpgCfZQpuuUxCJZwQbXJ0qxTBiV78qBkAoLpy ZH9cgCYkemF3Ca4D4nYjLNMF =XCG7 -----END PGP SIGNATURE----- Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02912 for ; Mon, 7 Aug 2000 12:39:53 -0700 (PDT) Received: from mega (t4o69p96.telia.com [62.20.145.216]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id VAA00695; Mon, 7 Aug 2000 21:43:59 +0200 (CEST) Message-ID: <002801c000b0$13f8a400$0201a8c0@mega.vincent.se> From: "Anders Rundgren" To: "Bob Jueneman" , Subject: Re: Digital Signatures - Legal Advice Wanted Date: Mon, 7 Aug 2000 22:43:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA02913 Bob, >I suspect that your server-based organizational orders would fall into the same situation. >And in particular, once the first such transaction has been accepted without complaint, >it is all downhill from there, since the commercial practice would then be increasingly >well-established. To me this is not downhill, this is just great and I believe that you are completely correct in your pragmatic view on how things actually work! In spite of signature laws... Regards Anders Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02603 for ; Mon, 7 Aug 2000 12:34:44 -0700 (PDT) Received: from mega (t2o69p5.telia.com [62.20.144.125]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id VAA26450; Mon, 7 Aug 2000 21:38:47 +0200 (CEST) Message-ID: <001901c000af$5a84e6f0$0201a8c0@mega.vincent.se> From: "Anders Rundgren" To: "'Tony Bartoletti'" , "PKIX-List" Subject: Re: Digital Signatures - Legal Advice Wanted Date: Mon, 7 Aug 2000 22:37:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA02604 Tony, >The primary goal being to keep the customer's "secret keys" >in an environment more secure than the customer may be expected >to maintain. More or less. Actually all authorized intranet users could then indirectly use the "company cert/key" for things like orders and payments. This simplifies CA trust-issues considerably as company certs (unlike "employee/role/attribute" certs) are suitable for TTP issuing which IMO is required for global e-commerce. Anders Received: from Newman.GSC.GTE.Com (SYSTEM@NS0.GDGSC.Com [192.160.62.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01589 for ; Mon, 7 Aug 2000 11:45:23 -0700 (PDT) Received: from gscex01.gsc.gte.com ("port 4418"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #38015) with SMTP id <01JSOXRFXJBI002RP8@Newman.GSC.GTE.Com> for ietf-pkix@imc.org; Mon, 7 Aug 2000 14:49:26 -0400 (EDT) Received: from 127.0.0.1 by gscex01.gsc.gte.com (InterScan E-Mail VirusWall NT) ; Mon, 07 Aug 2000 14:46:05 -0400 (Eastern Daylight Time) Received: by GSCEX01.gsc.gte.com with Internet Mail Service (5.5.2650.21) id ; Mon, 07 Aug 2000 14:43:32 -0400 Date: Mon, 07 Aug 2000 14:43:26 -0400 From: "Heimberg, Jim" Subject: RE: Digital Signatures - Legal Advice Wanted To: "'Tony Bartoletti'" , Adrian McCullagh , "'Anders Rundgren'" , PKIX-List Message-id: <2575327B6755D211A0E100805F9FF954050805C4@ndhmex02.ndhm.gsc.gte.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="ISO-8859-1" Just to add to the confusion, is there no allowance for designating the personality as the role that person fills? For instance, if you wanted as a CA to grant a signature and encryption key and the requisite authority to the Chief Financial Officer of a small company (e.g., Acme Electrical Supply) for purchasing as required, why can you not issue a certificate to cfo@acmeelectric.com (and if you need to personalize it, you could add the person's name or initials after the CFO designation)? -----Original Message----- From: Tony Bartoletti [mailto:azb@llnl.gov] Sent: Monday, August 07, 2000 2:21 PM To: Adrian McCullagh; 'Anders Rundgren'; PKIX-List Subject: RE: Digital Signatures - Legal Advice Wanted At 07:00 AM 8/7/00 +1000, Adrian McCullagh wrote: >In Common law countries like the USA, Australia, UK and Canada, there >is a doctrine known as ostensible authority. This provides that if a >person signs a document on behalf of another legal entity (the >principal) and the signer has some external reasonably perceived >authority such that a reasonable person looking at the transaction >objectively would believe that such person through his/her position >had such authority to bind the principal then the principal is bound >by the signers action. > >So as I see it, a director could digitally sign the digital document >using the directors own personal private key and as part of the text >of the document state the following word "signed for and on behalf of >Company XXXX". This would indicate to the world that the signer is >NOT signing the digital document so as to be personally bound but is >signing as an agent and as such is attempting to bind the principal >(company). (Please correct me, Anders, if I am mistaken, but) I believe the issue is a little different than Adrian supposes. Rather than have a (company) individual sign on behalf of "the company", I believe that the issue is whether a company (ok, an individual acting on behalf of the company if you must) can hold "customer's keys" and apply "customer's signatures", given some trail of evidence that the customer, on a case-by- case basis, has authorized that their signature be affixed to a given transaction. The primary goal being to keep the customer's "secret keys" in an environment more secure than the customer may be expected to maintain. (The legal precedent for this might be "power of attorney"?) If I'm wrong ... nevermind :) ___tony___ >The recipient would on receipt verify the digital signature using the >signer's personal certificate that has the public key embodied in it. >If the recipient is concerned about the authority then the recipient >can check the company records to determine if the signer has the >necessary implied/ostensible authority. To accelerate the process of >verification of authority there may be some solution in the use of >role based certificates or attribute certificates but I have not >really give this issue sufficient thought. > >If there is still some doubt then the recipient can always check with >the Company secretary or the Managing director as to such authority. > >The Uniform Electronic Transactions Act that is forming part of the >Uniform Commercial Code of various US States does anticipate software >agents and thus server based organisation digital signatures. > >But there are no cases that specifically deal with your issue. > >The simple solution is for a company officer to digitally sign the >digital document and affix the words noted above in the text prior to >digitally signing. > >I hope this is helpful. > > >Adrian McCullagh >Director of Electronic CommerceTel: 617 3231 1522 >Gadens Lawyers Fax: 617 3229 5850 >level 39 >Central Plaza 1 >345 Queen Street >Brisbane Australia 4000 > >Ph. D. Candidate >Thesis "The Incorporation of Trust Strategies in Digital Signature >Regimes for Elec. Comm." >Information Security Research Centre >Queensland University of Technology > > > >- -----Original Message----- >From: Anders Rundgren [ mailto:anders.rundgren@telia.com] >Sent: Monday, August 07, 2000 6:58 AM >To: PKIX-List >Subject: Digital Signatures - Legal Advice Wanted > > >Hi, >I am working with an e-commerce standard that features server-based, >organization-signed orders. > >However, server-based, organization-oriented digital signatures do >currently not, to the my knowledge, >have explicit support in any legal system. How to solve this? One >way (the current one) is to state >in separate agreements between the trading partners, that you will >stand by these signatures in court. > >I wonder if there could be a more general solution like: A company >officer digitally signs (using a personal >certificate), a document where he/she states that signatures >associated with a certain trading partner >certificate are to be considered as legally binding from the company's >point of view. >Such a document is preferably published on the company's home-page for >easy reference. > >How does this sound in the ears of lawyers? > >regards >Anders Rundgren > > > >-----BEGIN PGP SIGNATURE----- >Version: PGP Personal Edition 6.0.2 > >iQA/AwUBOY1FTJWt1NGjt4vzEQLdmACeJiR1FMKZ//6Mtfq+v5DfAGGo/q4AoJoM >bWjrz+F/Xll2zwotTzuligVm >=sEx7 >-----END PGP SIGNATURE----- Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00458 for ; Mon, 7 Aug 2000 11:13:02 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA15399; Mon, 7 Aug 2000 11:12:15 -0700 (PDT) Message-Id: <4.2.2.20000807111002.00a8a740@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 07 Aug 2000 11:20:42 -0700 To: Adrian McCullagh , "'Anders Rundgren'" , PKIX-List From: Tony Bartoletti Subject: RE: Digital Signatures - Legal Advice Wanted In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 07:00 AM 8/7/00 +1000, Adrian McCullagh wrote: >In Common law countries like the USA, Australia, UK and Canada, there >is a doctrine known as ostensible authority. This provides that if a >person signs a document on behalf of another legal entity (the >principal) and the signer has some external reasonably perceived >authority such that a reasonable person looking at the transaction >objectively would believe that such person through his/her position >had such authority to bind the principal then the principal is bound >by the signers action. > >So as I see it, a director could digitally sign the digital document >using the directors own personal private key and as part of the text >of the document state the following word "signed for and on behalf of >Company XXXX". This would indicate to the world that the signer is >NOT signing the digital document so as to be personally bound but is >signing as an agent and as such is attempting to bind the principal >(company). (Please correct me, Anders, if I am mistaken, but) I believe the issue is a little different than Adrian supposes. Rather than have a (company) individual sign on behalf of "the company", I believe that the issue is whether a company (ok, an individual acting on behalf of the company if you must) can hold "customer's keys" and apply "customer's signatures", given some trail of evidence that the customer, on a case-by- case basis, has authorized that their signature be affixed to a given transaction. The primary goal being to keep the customer's "secret keys" in an environment more secure than the customer may be expected to maintain. (The legal precedent for this might be "power of attorney"?) If I'm wrong ... nevermind :) ___tony___ >The recipient would on receipt verify the digital signature using the >signer's personal certificate that has the public key embodied in it. >If the recipient is concerned about the authority then the recipient >can check the company records to determine if the signer has the >necessary implied/ostensible authority. To accelerate the process of >verification of authority there may be some solution in the use of >role based certificates or attribute certificates but I have not >really give this issue sufficient thought. > >If there is still some doubt then the recipient can always check with >the Company secretary or the Managing director as to such authority. > >The Uniform Electronic Transactions Act that is forming part of the >Uniform Commercial Code of various US States does anticipate software >agents and thus server based organisation digital signatures. > >But there are no cases that specifically deal with your issue. > >The simple solution is for a company officer to digitally sign the >digital document and affix the words noted above in the text prior to >digitally signing. > >I hope this is helpful. > > >Adrian McCullagh >Director of Electronic CommerceTel: 617 3231 1522 >Gadens Lawyers Fax: 617 3229 5850 >level 39 >Central Plaza 1 >345 Queen Street >Brisbane Australia 4000 > >Ph. D. Candidate >Thesis "The Incorporation of Trust Strategies in Digital Signature >Regimes for Elec. Comm." >Information Security Research Centre >Queensland University of Technology > > > >- -----Original Message----- >From: Anders Rundgren [ mailto:anders.rundgren@telia.com] >Sent: Monday, August 07, 2000 6:58 AM >To: PKIX-List >Subject: Digital Signatures - Legal Advice Wanted > > >Hi, >I am working with an e-commerce standard that features server-based, >organization-signed orders. > >However, server-based, organization-oriented digital signatures do >currently not, to the my knowledge, >have explicit support in any legal system. How to solve this? One >way (the current one) is to state >in separate agreements between the trading partners, that you will >stand by these signatures in court. > >I wonder if there could be a more general solution like: A company >officer digitally signs (using a personal >certificate), a document where he/she states that signatures >associated with a certain trading partner >certificate are to be considered as legally binding from the company's >point of view. >Such a document is preferably published on the company's home-page for >easy reference. > >How does this sound in the ears of lawyers? > >regards >Anders Rundgren > > > >-----BEGIN PGP SIGNATURE----- >Version: PGP Personal Edition 6.0.2 > >iQA/AwUBOY1FTJWt1NGjt4vzEQLdmACeJiR1FMKZ//6Mtfq+v5DfAGGo/q4AoJoM >bWjrz+F/Xll2zwotTzuligVm >=sEx7 >-----END PGP SIGNATURE----- Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA25872 for ; Mon, 7 Aug 2000 08:25:51 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 07 Aug 2000 09:29:14 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 07 Aug 2000 09:29:09 -0600 From: "Bob Jueneman" To: , , Subject: RE: Digital Signatures - Legal Advice Wanted Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_D0886ADA.C6A7CC5D" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_D0886ADA.C6A7CC5D Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Anders, I am not an attorney (IANA), but I would suggest that Adrian has expressed a generally conservative view that would constitute good defensive legal practice, but may leave the impression that=20 without going through all of these steps, the transaction would presumably not be valid. But there is a different danger, and that is that transactions that=20 are digitally signed using a key that is apparently under the control=20 of the corporation or organization, might very well be held to be binding even without an explicit confirmation. In other words, I would suggest that Adrian's recommendations would almost certainly be sufficient, but they may not be necessary. Even though both the US and Australia are Common Law countries, there may be differences in the degree to which what Adrian refers to=20 as ostensible authority is accepted. My understanding is that in the US, the concept is fairly widely applied, in order to facilitate commerce. The closest analog I can think of to the corporate digital signature=20 is the mechanical signature plate that is used to sign corporate checks. Yes, because of the paper world precedents, the signature is a=20 facsimile of the treasurer's manual signature, and the words on the paper indicate that he is causing his signature to be affixed to that check as a agent of the corporation. But do you think that any recipient of such a check actually bothers to=20 verify that the signature really is that of the treasurer, or that the = treasurer has been authorized to sign checks by the Board of Directors? No way! In simple language, apply the duck test: If something looks like a duck, walks like a duck, and quacks like a duck, it probably is a duck. =20 In the case of a check, it was preprinted with the name of the corporation,= it was presumably tendered as a result of some consideration, debt, or other obligation (it didn't just fall out of the sky), and to all intents = and purposes it appears to be in order. Reliance on that treasurer's ostensible = authority would certainly be quite reasonable. (Note that there is no claim being = made that the check was a forgery, which would be a different matter.) So if I launch my browser to www.amazon.com, I see all sorts of stuff = appear=20 on my screen that would be consistent with the fact that I was connected = to=20 amazon, and the lock icon confirms that an SSL session has been established= with a server, on which a private key has apparently been installed that = corresponds to a public key certificate issued by a reputable CA (one whose root I = have accepted), then I have every right to believe that I am communicating with a server = that is=20 controlled by amazon. Granted, an SSL connection does not provide nonrepudiation for a particular= transaction. But supposing that I enter my credit card number or other personal = information over that session, and later I can establish that that information was not handled = properly. Could I sue amazon for not protecting my information adequately, and be = successful? Almost certainly, even without the www.amazon.com certificate. Certainly = no judge in the US would dismiss such a suite because I failed to provide satisfactory = evidence that the Board of Directors of amazon had in fact properly authorized the IT = department to=20 acquire a certificate, set up a server to conduct business, etc. In this case, it sure sounds like a duck. I suspect that your server-based organizational orders would fall into the = same situation. And in particular, once the first such transaction has been accepted = without complaint,=20 it is all downhill from there, since the commercial practice would then be = increasingly=20 well-established. Regards, Bob >>> Adrian McCullagh 08/06/00 03:00PM = >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Anders In the paper based environment a company does not have its own signature. Companies are artificial legal entities and as such can only act through human agents. (Now this may change through the use of software agents but that is another issue). Hence for a company to be bound to a commercial transaction the human agent must have some authority either implied or express.=20 A person digitally signing a digital document that attempts to bind a company should use their own private key for such action. The issue then revolves around the concept of authority. If the signer does not have the appropriate authority then the signer may be liable for "Breach of Warranty of Authority". If the signer has express authority to sign the document and thus bind the principal then the issue is simple. In Common law countries like the USA, Australia, UK and Canada, there is a doctrine known as ostensible authority. This provides that if a person signs a document on behalf of another legal entity (the principal) and the signer has some external reasonably perceived authority such that a reasonable person looking at the transaction objectively would believe that such person through his/her position had such authority to bind the principal then the principal is bound by the signers action. So as I see it, a director could digitally sign the digital document using the directors own personal private key and as part of the text of the document state the following word "signed for and on behalf of Company XXXX". This would indicate to the world that the signer is NOT signing the digital document so as to be personally bound but is signing as an agent and as such is attempting to bind the principal (company). The recipient would on receipt verify the digital signature using the signer's personal certificate that has the public key embodied in it.=20 If the recipient is concerned about the authority then the recipient can check the company records to determine if the signer has the necessary implied/ostensible authority. To accelerate the process of verification of authority there may be some solution in the use of role based certificates or attribute certificates but I have not really give this issue sufficient thought. If there is still some doubt then the recipient can always check with the Company secretary or the Managing director as to such authority. The Uniform Electronic Transactions Act that is forming part of the Uniform Commercial Code of various US States does anticipate software agents and thus server based organisation digital signatures. But there are no cases that specifically deal with your issue. The simple solution is for a company officer to digitally sign the digital document and affix the words noted above in the text prior to digitally signing. I hope this is helpful. Adrian McCullagh Director of Electronic CommerceTel: 617 3231 1522 Gadens Lawyers Fax: 617 3229 5850 =20 level 39 Central Plaza 1 345 Queen Street Brisbane Australia 4000 Ph. D. Candidate Thesis "The Incorporation of Trust Strategies in Digital Signature Regimes for Elec. Comm." Information Security Research Centre Queensland University of Technology - -----Original Message----- From: Anders Rundgren [ mailto:anders.rundgren@telia.com] Sent: Monday, August 07, 2000 6:58 AM To: PKIX-List Subject: Digital Signatures - Legal Advice Wanted Hi, I am working with an e-commerce standard that features server-based, organization-signed orders. However, server-based, organization-oriented digital signatures do currently not, to the my knowledge, have explicit support in any legal system. How to solve this? One way (the current one) is to state in separate agreements between the trading partners, that you will stand by these signatures in court. I wonder if there could be a more general solution like: A company officer digitally signs (using a personal certificate), a document where he/she states that signatures associated with a certain trading partner certificate are to be considered as legally binding from the company's point of view. Such a document is preferably published on the company's home-page for easy reference. How does this sound in the ears of lawyers? regards Anders Rundgren -----BEGIN PGP SIGNATURE----- Version: PGP Personal Edition 6.0.2 iQA/AwUBOY1FTJWt1NGjt4vzEQLdmACeJiR1FMKZ//6Mtfq+v5DfAGGo/q4AoJoM bWjrz+F/Xll2zwotTzuligVm =3DsEx7 -----END PGP SIGNATURE----- --=_D0886ADA.C6A7CC5D Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Anders,
 
I am not an attorney (IANA), but I would suggest = that=20 Adrian
has expressed a generally conservative view that = would=20 constitute
good defensive legal practice, but may leave the = impression=20 that
without going through all of these steps, the = transaction=20 would
presumably  not be=20 valid.
 
But there is a different danger, and that is that = transactions=20 that
are digitally signed using a key that is apparently = under the=20 control
of the corporation or organization, might very well be = held to=20 be binding
even without an explicit confirmation.
 
In other words, I would suggest that Adrian's=20 recommendations
would almost certainly be sufficient, but they may not = be=20 necessary.
 
Even though both the US and Australia are Common = Law=20 countries,
there may be differences in the degree to which what = Adrian=20 refers to
as ostensible authority is accepted.  My = understanding is=20 that in the US,
the concept is fairly widely applied, in order to = facilitate=20 commerce.
 
The closest analog I can think of to the corporate = digital=20 signature
is the mechanical signature plate that is used to = sign=20 corporate checks.
Yes, because of the paper world precedents, the = signature is a=20
facsimile of the treasurer's manual signature, and the = words=20 on the paper
indicate that he is causing his signature to be = affixed to=20 that check
as a agent of the corporation.
 
But do you think that any recipient of such a check = actually=20 bothers to
verify that the signature really is that of the = treasurer, or=20 that the treasurer
has been authorized to sign checks by the Board of=20 Directors?  No way!
 
In simple language, apply the duck test:
 
If something looks like a duck, walks like a duck, and = quacks=20 like a duck,
it probably is a duck. 
 
In the case of a check, it was preprinted with the = name of the=20 corporation,
it was presumably tendered as a result of some = consideration,=20 debt, or
other obligation (it didn't just fall out of the sky), = and to=20 all intents and purposes
it appears to be in order.  Reliance on that = treasurer's=20 ostensible authority
would certainly be quite reasonable.  (Note that = there is=20 no claim being made that
the check was a forgery, which would be a different=20 matter.)
 
So if I launch my browser to www.amazon.com, I see all sorts of = stuff appear=20
on my screen that would be consistent with the fact = that I was=20 connected to
amazon, and the lock icon confirms that an SSL session = has=20 been established
with a server, on which a private key has apparently = been=20 installed that corresponds
to a public key certificate issued by a reputable CA = (one=20 whose root I have accepted),
then I have every right to believe that I am communicat= ing=20 with a server that is
controlled by amazon.
 
Granted, an SSL connection does not provide nonrepudiat= ion for=20 a particular transaction.
But supposing that I enter my credit card number or = other=20 personal information over that
session, and later I can establish that that informatio= n was=20 not handled properly.
 
Could I sue amazon for not protecting my information=20= adequately, and be successful?
Almost certainly, even without the www.amazon.com certificate.  = Certainly no=20 judge in the
US would dismiss such a suite because I failed to = provide=20 satisfactory evidence that
the Board of Directors of am= azon had=20 in fact properly authorized the IT department to
acquire a certificate, set up a server to conduct = business,=20 etc.
 
In this case, it sure sounds like a duck.
 
I suspect that your server-based organizational orders = would=20 fall into the same situation.
And in particular, once the first such transaction has = been=20 accepted without complaint,
it is all downhill from there, since the commercial = practice=20 would then be increasingly
well-established.
 
Regards,
 
Bob
 

>>> Adrian McCullagh <AMcCullagh@exchange.gadens.com.a= u>=20 08/06/00 03:00PM >>>
-----BEGIN PGP SIGNED MESSAGE-----
Hash= :=20 SHA1

Dear Anders

In the paper based environment a company = does not=20 have its own
signature.  Companies are artificial legal entities = and as=20 such can
only act through human agents. (Now this may change through = the use=20 of
software agents but that is another issue).  Hence for a = company to=20 be
bound to a commercial transaction the human agent must have=20 some
authority either implied or express.

A person digitally = signing=20 a digital document that attempts to bind a
company should use their = own=20 private key for such action.  The issue
then revolves around the = concept=20 of authority.  If the signer does not
have the appropriate = authority=20 then the signer may be liable for
"Breach of Warranty of Authority".&nbs= p; If=20 the signer has express
authority to sign the document and thus bind = the=20 principal then the
issue is simple.

In Common law countries like = the=20 USA, Australia, UK and Canada, there
is a doctrine known as ostensible= =20 authority.  This provides that if a
person signs a document on = behalf of=20 another legal entity (the
principal) and the signer has some external=20= reasonably perceived
authority such that a reasonable person looking at = the=20 transaction
objectively would believe that such person through = his/her=20 position
had such authority to bind the principal then the principal = is=20 bound
by the signers action.

So as I see it, a director could=20 digitally sign the digital document
using the directors own personal = private=20 key and as part of the text
of the document state the following word = "signed=20 for and on behalf of
Company XXXX".  This would indicate to the = world=20 that the signer is
NOT signing the digital document so as to be = personally=20 bound but is
signing as an agent and as such is attempting to bind = the=20 principal
(company).

The recipient would on receipt verify the = digital=20 signature using the
signer's personal certificate that has the public = key=20 embodied in it.
If the recipient is concerned about the authority then = the=20 recipient
can check the company records to determine if the signer = has=20 the
necessary implied/ostensible authority.   To accelerate = the=20 process of
verification of authority there may be some solution in the = use=20 of
role based certificates or attribute certificates but I have = not
really=20 give this issue sufficient thought.

If there is still some doubt = then the=20 recipient can always check with
the Company secretary or the Managing=20= director as to such authority.

The Uniform Electronic Transactions = Act=20 that is forming part of the
Uniform Commercial Code of various US = States does=20 anticipate software
agents and thus server based organisation digital=20= signatures.

But there are no cases that specifically deal with = your=20 issue.

The simple solution is for a company officer to digitally = sign=20 the
digital document and affix the words noted above in the text = prior=20 to
digitally signing.

I hope this is helpful.


Adrian= =20 McCullagh
Director of Electronic CommerceTel: 617 3231 1522
Gadens=20= Lawyers           &n= bsp;         =20 Fax: 617 3229 5850    
level 39
Central = Plaza=20 1
345 Queen Street
Brisbane Australia 4000

Ph. D.=20 Candidate
Thesis "The Incorporation of Trust Strategies in Digital=20 Signature
Regimes for Elec. Comm."
Information Security Research=20 Centre
Queensland University of Technology



- -----Origina= l=20 Message-----
From: Anders Rundgren [ mailto:anders.rundgren@telia.com= ]
Sent:=20 Monday, August 07, 2000 6:58 AM
To: PKIX-List
Subject: Digital = Signatures=20 - Legal Advice Wanted


Hi,
I am working with an e-commerce = standard=20 that features server-based,
organization-signed orders.

However,= =20 server-based, organization-oriented digital signatures do
currently = not, to=20 the my knowledge,
have explicit support in any legal system.  How = to=20 solve this?  One
way (the current one) is to state
in = separate=20 agreements between the trading partners, that you will
stand by = these=20 signatures in court.

I wonder if there could be a more general = solution=20 like: A company
officer digitally signs (using a personal
certificate= ), a=20 document where he/she states that signatures
associated with a = certain=20 trading partner
certificate are to be considered as legally binding = from the=20 company's
point of view.
Such a document is preferably published on = the=20 company's home-page for
easy reference.

How does this sound in = the=20 ears of lawyers?

regards
Anders Rundgren



-----BEGI= N PGP=20 SIGNATURE-----
Version: PGP Personal Edition=20 6.0.2

iQA/AwUBOY1FTJWt1NGjt4vzEQLdmACeJiR1FMKZ//6Mtfq+v5DfAGGo/q4AoJ= oM
bWjrz+F/Xll2zwotTzuligVm
=3DsEx7
-----END=20 PGP SIGNATURE-----
--=_D0886ADA.C6A7CC5D-- Received: from dvnet8.dvnet.com ([209.121.31.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20999 for ; Mon, 7 Aug 2000 07:41:06 -0700 (PDT) Received: from CC787228-A (cc787228-a.hwrd1.md.home.com [24.180.131.6]) by dvnet8.dvnet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QK5F02F9; Mon, 7 Aug 2000 10:47:45 -0400 Received: by localhost with Microsoft MAPI; Mon, 7 Aug 2000 10:45:45 -0400 Message-ID: <01C0005C.A43805A0.aarsenault@dvnet.com> From: Al Arsenault To: "'Irene Gassko'" , Stephen Kent Cc: "ietf-pkix@imc.org" Subject: RE: OCSP request Date: Mon, 7 Aug 2000 10:45:45 -0400 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 79 TEXT The problem with this scheme is that, even if it does help with archiving and recovery in the case of CA key compromise, it doesn't help in the normal certificate processing operations. With a certificate signed by a CA, I know that "the CA has vouched for the correctness of each of the data items in this certificate", subject to the normal discussions on how thoroughly the CA has verified them, yada, yada, yada. With a certificate not being signed, or being signed by the originator, I just know that I have a data structure, and I'm not sure about the CA's willingness to vouch for those items, until such time as I go fetch the signed Merkle tree that pertains and verify it, recursively to where I get to a trusted root. That is, I don't know if I have a complete spoof attempt, a corrupted cert, or anything else, until such time as I do the "revocation check". So it seems to me that in the normal processing mode, this proposal is actually somewhat *less* efficient than the current scheme, where I can do some checks on the cert BEFORE I fetch the CRL or ping the OCSP responder, and thus not even bother with revocation checking on things that have already failed. Al Arsenault Chief Security Architect Diversinet Corp. -----Original Message----- From: Irene Gassko [SMTP:gassko@lucent.com] Sent: Monday, August 07, 2000 10:20 AM To: Stephen Kent Cc: ietf-pkix@imc.org Subject: RE: OCSP request Steve, You are right and I know that currently signatures are mandatory. But making changes in order to solve serious problems is a part of the standards process, isn't it? A lot of discussion in this group is devoted to suggested improvements in the standard. If making signatures optional can help with CA key change and cert archiving, would not it be a good idea to allow such usage (as in MAY)? Irene At 05:55 PM 08/06/2000 -0400, Stephen Kent wrote: >Irene, > > > > >>The main idea is to eliminate signatures in certificates and have CA >>sign a Merkle tree of certificates instead. Then CA key compromise >>requires the change in that signature (which can be downloaded separately) >>but leaves cards and certificates unperturbed. You can use multiple >>signatures with different signature algorithms and keep keys on different >>continents if you wish. This scheme also helps with archiving. And you do not >>need a CRL. It can be used with X.509 certificates, making the signature >>on a certificate optional, rather than mandatory. Or you can make it >>an owner's signature instead of a CA's signature. > >Irrespective of the merit of the approach to which you allude, the >result would not be an X.509 cert. Signatures are mandatory, not >optional, in the format that is the basis of this WG's activity. > >Steve ------------------------------------------------------------------------ ---- ------------------------------------------------------- Irene Gassko Bell Laboratories http://www.lucent.com Lucent Technologies Secure Technologies Dept. 1600 Osgood Street phone: (978) 960-5767 Room 30-2-A31 e-mail: gassko@lucent.com N. Andover, MA 01845 fax: (978) 960-3240 Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20483 for ; Mon, 7 Aug 2000 07:32:03 -0700 (PDT) Received: by ns.celocom.se; id QAA18164; Mon, 7 Aug 2000 16:36:09 +0200 (CEST) Received: from seexchange.celocom.se(10.10.10.11) by ns.celocom.se via smap (4.1) id xma018146; Mon, 7 Aug 00 16:35:14 +0200 Received: from celocom.se (levitte.celocom.se [10.10.10.124]) by seexchange.celocom.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QBR2MXTA; Mon, 7 Aug 2000 16:38:48 +0200 Sender: levitte@celocom.se Message-ID: <398EC915.1A06FE1@celocom.se> Date: Mon, 07 Aug 2000 16:35:01 +0200 From: Richard Levitte Organization: Celo Communications, Ltd. X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Irene Gassko CC: Stephen Kent , ietf-pkix@imc.org Subject: Re: OCSP request References: <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> <4.1.20000807101230.03173400@anuxc.mv.lucent.com> Content-Type: multipart/mixed; boundary="------------8E2B775E0071C9A35395E006" This is a multi-part message in MIME format. --------------8E2B775E0071C9A35395E006 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think we're into a little bit of nit-picking here. On this list, it's probably not possible to suggest a change of an ITU (do I remember correctly?) standard, such as X.509. Talking about changes to an RFC would probably prove a bit more fruitful. In this case, you probably mean RFC2459 or whatever draft that updates it. However, if I understand correctly, the meaning of RFC2459 is to be as close as possible to X.509, which makes the RFC bound to X.509, therefore making incompatible changes a bad thing. Furthermore, if making the signature OPTIONAL (which I assume would be the result), I'm sure there would be changes in the ASN.1 coding (be it BER, DER, or whatever) that doesn't allow correct interpretation of older certificates. Don't take my word for it though, I haven't studied the possible effects enough to actually know. This is just a hunch (sp?)... Irene Gassko wrote: > > You are right and I know that currently signatures are mandatory. > But making changes in order to solve serious problems is a part > of the standards process, isn't it? A lot of discussion in this > group is devoted to suggested improvements in the standard. If > making signatures optional can help with CA key change and cert > archiving, would not it be a good idea to allow such usage (as in > MAY)? -- Richard Levitte !!! New cell phone number !!! richard.levitte@celocom.se /* You might enjoy viewing the complete vCard */ --------------8E2B775E0071C9A35395E006 Content-Type: text/x-vcard; charset=us-ascii; name="richard.levitte.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Richard Levitte Content-Disposition: attachment; filename="richard.levitte.vcf" begin:vcard n:Levitte;Richard tel;cell:+46-733-72 8811 tel;work:+46-8-58 72 8811 x-mozilla-html:FALSE org:Celo Communications version:2.1 email;internet:richard.levitte@celocom.se title:Software Artist adr;quoted-printable:;;Sveav=E4gen 145, 5tr=0D=0AStockholm;;;;SWEDEN note;quoted-printable:
=0D=0A=0D=0A=0D=0A =0D=0A=0D=0A
c=EAlo, =E2vi, =E2tum, (latin) 1,v.a.=0D=0A to hide something from one, to keep secret, to conceal.=0D=0A
=0D=0A
=0D=0A=0D=0A=0D=0A =0D=0A=0D=0A
=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A
o/~Coding, coding, coding
=0D=0A Keep'em hackers coding
=0D=0A And When They're Done Coding
=0D=0A COMPIIIIIIILE!!
=0D=0A
fn:Richard Levitte end:vcard --------------8E2B775E0071C9A35395E006-- Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19897 for ; Mon, 7 Aug 2000 07:15:38 -0700 (PDT) Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA23631 for ; Mon, 7 Aug 2000 10:19:45 -0400 (EDT) Received: from anuxc.mv.lucent.com (h135-13-160-12.lucent.com [135.13.160.12]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA23615; Mon, 7 Aug 2000 10:19:44 -0400 (EDT) Received: from irene by anuxc.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA20757; Mon, 7 Aug 2000 10:17:03 -0400 (EDT) Message-Id: <4.1.20000807101230.03173400@anuxc.mv.lucent.com> X-Sender: irg@anuxc.mv.lucent.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 07 Aug 2000 10:19:54 -0400 To: Stephen Kent From: Irene Gassko Subject: RE: OCSP request Cc: ietf-pkix@imc.org In-Reply-To: References: <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Steve, You are right and I know that currently signatures are mandatory. But making changes in order to solve serious problems is a part of the standards process, isn't it? A lot of discussion in this group is devoted to suggested improvements in the standard. If making signatures optional can help with CA key change and cert archiving, would not it be a good idea to allow such usage (as in MAY)? Irene At 05:55 PM 08/06/2000 -0400, Stephen Kent wrote: >Irene, > > > > >>The main idea is to eliminate signatures in certificates and have CA >>sign a Merkle tree of certificates instead. Then CA key compromise >>requires the change in that signature (which can be downloaded separately) >>but leaves cards and certificates unperturbed. You can use multiple >>signatures with different signature algorithms and keep keys on different >>continents if you wish. This scheme also helps with archiving. And you do not >>need a CRL. It can be used with X.509 certificates, making the signature >>on a certificate optional, rather than mandatory. Or you can make it >>an owner's signature instead of a CA's signature. > >Irrespective of the merit of the approach to which you allude, the >result would not be an X.509 cert. Signatures are mandatory, not >optional, in the format that is the basis of this WG's activity. > >Steve ---------------------------------------------------------------------------- ------------------------------------------------------- Irene Gassko Bell Laboratories http://www.lucent.com Lucent Technologies Secure Technologies Dept. 1600 Osgood Street phone: (978) 960-5767 Room 30-2-A31 e-mail: gassko@lucent.com N. Andover, MA 01845 fax: (978) 960-3240 Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA19318 for ; Mon, 7 Aug 2000 06:54:28 -0700 (PDT) Received: from [128.33.238.66] (TC066.BBN.COM [128.33.238.66]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id JAA29865; Mon, 7 Aug 2000 09:58:32 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> References: <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> Date: Sun, 6 Aug 2000 17:55:17 -0400 To: Irene Gassko From: Stephen Kent Subject: RE: OCSP request Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Irene, >The main idea is to eliminate signatures in certificates and have CA >sign a Merkle tree of certificates instead. Then CA key compromise >requires the change in that signature (which can be downloaded separately) >but leaves cards and certificates unperturbed. You can use multiple >signatures with different signature algorithms and keep keys on different >continents if you wish. This scheme also helps with archiving. And you do not >need a CRL. It can be used with X.509 certificates, making the signature >on a certificate optional, rather than mandatory. Or you can make it >an owner's signature instead of a CA's signature. Irrespective of the merit of the approach to which you allude, the result would not be an X.509 cert. Signatures are mandatory, not optional, in the format that is the basis of this WG's activity. Steve Received: from hamster.gadens.com.au (root@dns.gadens.com.au [203.32.220.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24732 for ; Sun, 6 Aug 2000 13:52:33 -0700 (PDT) Received: from exchange.gadens.com.au ([10.1.8.3]) by hamster.gadens.com.au (8.9.3/8.9.3) with ESMTP id GAA85003; Mon, 7 Aug 2000 06:56:20 +1000 (EST) (envelope-from AMcCullagh@exchange.gadens.com.au) Received: by exchange.gadens.com.au with Internet Mail Service (5.5.2650.21) id <3YWS666Y>; Mon, 7 Aug 2000 07:00:32 +1000 Message-ID: From: Adrian McCullagh To: "'Anders Rundgren'" , PKIX-List Subject: RE: Digital Signatures - Legal Advice Wanted Date: Mon, 7 Aug 2000 07:00:27 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Anders In the paper based environment a company does not have its own signature. Companies are artificial legal entities and as such can only act through human agents. (Now this may change through the use of software agents but that is another issue). Hence for a company to be bound to a commercial transaction the human agent must have some authority either implied or express. A person digitally signing a digital document that attempts to bind a company should use their own private key for such action. The issue then revolves around the concept of authority. If the signer does not have the appropriate authority then the signer may be liable for "Breach of Warranty of Authority". If the signer has express authority to sign the document and thus bind the principal then the issue is simple. In Common law countries like the USA, Australia, UK and Canada, there is a doctrine known as ostensible authority. This provides that if a person signs a document on behalf of another legal entity (the principal) and the signer has some external reasonably perceived authority such that a reasonable person looking at the transaction objectively would believe that such person through his/her position had such authority to bind the principal then the principal is bound by the signers action. So as I see it, a director could digitally sign the digital document using the directors own personal private key and as part of the text of the document state the following word "signed for and on behalf of Company XXXX". This would indicate to the world that the signer is NOT signing the digital document so as to be personally bound but is signing as an agent and as such is attempting to bind the principal (company). The recipient would on receipt verify the digital signature using the signer's personal certificate that has the public key embodied in it. If the recipient is concerned about the authority then the recipient can check the company records to determine if the signer has the necessary implied/ostensible authority. To accelerate the process of verification of authority there may be some solution in the use of role based certificates or attribute certificates but I have not really give this issue sufficient thought. If there is still some doubt then the recipient can always check with the Company secretary or the Managing director as to such authority. The Uniform Electronic Transactions Act that is forming part of the Uniform Commercial Code of various US States does anticipate software agents and thus server based organisation digital signatures. But there are no cases that specifically deal with your issue. The simple solution is for a company officer to digitally sign the digital document and affix the words noted above in the text prior to digitally signing. I hope this is helpful. Adrian McCullagh Director of Electronic CommerceTel: 617 3231 1522 Gadens Lawyers Fax: 617 3229 5850 level 39 Central Plaza 1 345 Queen Street Brisbane Australia 4000 Ph. D. Candidate Thesis "The Incorporation of Trust Strategies in Digital Signature Regimes for Elec. Comm." Information Security Research Centre Queensland University of Technology - -----Original Message----- From: Anders Rundgren [ mailto:anders.rundgren@telia.com] Sent: Monday, August 07, 2000 6:58 AM To: PKIX-List Subject: Digital Signatures - Legal Advice Wanted Hi, I am working with an e-commerce standard that features server-based, organization-signed orders. However, server-based, organization-oriented digital signatures do currently not, to the my knowledge, have explicit support in any legal system. How to solve this? One way (the current one) is to state in separate agreements between the trading partners, that you will stand by these signatures in court. I wonder if there could be a more general solution like: A company officer digitally signs (using a personal certificate), a document where he/she states that signatures associated with a certain trading partner certificate are to be considered as legally binding from the company's point of view. Such a document is preferably published on the company's home-page for easy reference. How does this sound in the ears of lawyers? regards Anders Rundgren -----BEGIN PGP SIGNATURE----- Version: PGP Personal Edition 6.0.2 iQA/AwUBOY1FTJWt1NGjt4vzEQLdmACeJiR1FMKZ//6Mtfq+v5DfAGGo/q4AoJoM bWjrz+F/Xll2zwotTzuligVm =sEx7 -----END PGP SIGNATURE----- Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24045 for ; Sun, 6 Aug 2000 12:54:50 -0700 (PDT) Received: from mega (t5o69p22.telia.com [213.64.110.22]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id VAA24588; Sun, 6 Aug 2000 21:58:48 +0200 (CEST) Message-ID: <001201bfffe8$fc2ff480$0201a8c0@mega.vincent.se> From: "Anders Rundgren" To: "PKIX-List" Subject: Digital Signatures - Legal Advice Wanted Date: Sun, 6 Aug 2000 22:57:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA24046 Hi, I am working with an e-commerce standard that features server-based, organization-signed orders. However, server-based, organization-oriented digital signatures do currently not, to the my knowledge, have explicit support in any legal system. How to solve this? One way (the current one) is to state in separate agreements between the trading partners, that you will stand by these signatures in court. I wonder if there could be a more general solution like: A company officer digitally signs (using a personal certificate), a document where he/she states that signatures associated with a certain trading partner certificate are to be considered as legally binding from the company’s point of view. Such a document is preferably published on the company’s home-page for easy reference. How does this sound in the ears of lawyers? regards Anders Rundgren Received: from dmz0101.rrl.co.uk (mail.rrl.co.uk [195.166.68.179]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA27200 for ; Fri, 4 Aug 2000 04:31:37 -0700 (PDT) Received: from nts006.rrl.co.uk (unverified) by dmz0101.rrl.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 04 Aug 2000 12:35:36 +0100 Received: from nts006.rrl.co.uk (unverified) by nts006.rrl.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 04 Aug 2000 12:34:32 +0100 Received: by nts006.rrl.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 4 Aug 2000 12:34:32 +0100 Message-Id: From: "Brian.Clarke" To: ietf-pkix@imc.org Subject: How should an OCSP responder cope with policy IDs Date: Fri, 4 Aug 2000 12:34:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" While implementing an OCSP responder we have been considering how to process extensions in requestors' certificates, i.e. if an OCSP request is signed, we should handle any extensions present in the signer's certificate correctly. Do people have a view on how a critically marked policy ID extension (id-ce-certificatePolicies) should be handled? For example, would the OCSP responder be expected to check the policy IDs against a list of known IDs. If the IDs were found the responder would then accept the request, but if a policy ID which was unknown to the responder was given, the responder would reject the request. Alternatively the responder could just ignore the policy Id information and process the OCSP request regardless. Any suggestions gratefully received. Brian. ---------------------------------------------------------------------- This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and may not be divulged to any third party without the express permission of the originator. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Racal Research Ltd. ---------------------------------------------------------------------- Received: from fox.netfront.com.cn ([202.106.144.158]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA20937 for ; Fri, 4 Aug 2000 02:45:12 -0700 (PDT) Received: from wshu ([192.168.10.5]) by fox.netfront.com.cn (8.8.7/8.8.7) with SMTP id RAA20539 for ; Fri, 4 Aug 2000 17:41:41 +0800 From: "Star Wang" To: Subject: RE: Difference IN Enterprise CA And Trade CA Date: Fri, 4 Aug 2000 17:50:28 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20000804022815.27623.qmail@sina.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Hi, WXH: I am a system designer of PKI products. I don't know what you mean. You want to buy a product and set up a CA, or just develope and set up your organization's CA. I think the conceptions are not so imporant as you think, what you should know is investigating the real requirements, and set up a CA what can meet the requirements of your organization. So just forget "Enterprise CA" and "Trade CA", I think the basic functions of them are same, a user should apply his/her certificate (or the administrator apply the certificate for the user), and an administrator will look through the application, and ... ... . The import thing is what your organization's needs are, and you should make the policy according to the actual conditions, so you can do the following things. I think I can't write down all of the details in one mail, and my email is star_wang@sina.com, you can contract with me directly. So we can communication. Star Wang > -----Original Message----- > From: wxhietf [mailto:wxhietf@sina.com] > Sent: Friday, August 04, 2000 2:28 AM > To: ietf-pkix@imc.org > Subject: Difference IN Enterprise CA And Trade CA > > > Hello Everyone, > we are planning to set up a Enterprise CA ,But the conception between > Enterprise CA And Trade Ca( such as a financial Ca or a Post CA ) is not > so clear to us. > Anyone with the experence please help me. > > My Email: wxhietf@sina.com > > > thanks > wxh.ietf > ______________________________________ > > =================================================================== > ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn > ²Î¼ÓÐÂÀË°ÂÔËÇéÂÂÌØʹÆÀÑ¡»î¶¯£¬Ç×ÁÙϤÄáǧìû°ÂÔËÊ¢»á¡£¿ìÀ´²Î¼Ó¡£ > http://ad2.sina.com.cn/ads/olympics/ > Received: from sina.com ([202.106.187.166]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA15426 for ; Thu, 3 Aug 2000 19:23:25 -0700 (PDT) Received: (qmail 27624 invoked by uid 99); 4 Aug 2000 02:28:15 -0000 Message-ID: <20000804022815.27623.qmail@sina.com> From: wxhietf To: ietf-pkix@imc.org Subject: Difference IN Enterprise CA And Trade CA Date: Fri Aug 4 02:28:15 2000 X-Mailer: SinaMail 3.0Beta (FireToad) X-Priority: 3 Hello Everyone, we are planning to set up a Enterprise CA ,But the conception between Enterprise CA And Trade Ca( such as a financial Ca or a Post CA ) is not so clear to us. Anyone with the experence please help me. My Email: wxhietf@sina.com thanks wxh.ietf ______________________________________ =================================================================== ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn ²Î¼ÓÐÂÀË°ÂÔËÇéÂÂÌØʹÆÀÑ¡»î¶¯£¬Ç×ÁÙϤÄáǧìû°ÂÔËÊ¢»á¡£¿ìÀ´²Î¼Ó¡£ http://ad2.sina.com.cn/ads/olympics/ Received: from sina.com ([202.106.187.164]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA15298 for ; Thu, 3 Aug 2000 19:22:21 -0700 (PDT) Received: (qmail 9017 invoked by uid 99); 4 Aug 2000 02:26:25 -0000 Message-ID: <20000804022625.9012.qmail@sina.com> From: wxhietf To: ietf-pkix@imc.org Subject: Difference IN Enterprise CA And Trade CA Date: Fri Aug 4 02:26:25 2000 X-Mailer: SinaMail 3.0Beta (FireToad) X-Priority: 3 Hello Everyone, we are planning to set up a Enterprise CA ,But the conception between Enterprise CA And Trade Ca( such as a financial Ca or a Post CA ) is not so clear to us. Anyone with the experence please help me. thanks wxh.ietf ______________________________________ =================================================================== ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn ²Î¼ÓÐÂÀË°ÂÔËÇéÂÂÌØʹÆÀÑ¡»î¶¯£¬Ç×ÁÙϤÄáǧìû°ÂÔËÊ¢»á¡£¿ìÀ´²Î¼Ó¡£ http://ad2.sina.com.cn/ads/olympics/ Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19676 for ; Thu, 3 Aug 2000 10:03:47 -0700 (PDT) Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA19186 for ; Thu, 3 Aug 2000 13:07:35 -0400 (EDT) Received: from anuxc.mv.lucent.com (h135-13-160-12.lucent.com [135.13.160.12]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA19138; Thu, 3 Aug 2000 13:07:33 -0400 (EDT) Received: from irene by anuxc.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA03015; Thu, 3 Aug 2000 13:04:53 -0400 (EDT) Message-Id: <4.1.20000803124833.034d6458@anuxc.mv.lucent.com> X-Sender: irg@anuxc.mv.lucent.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 03 Aug 2000 13:08:14 -0400 To: Simon Tardell From: Irene Gassko Subject: RE: OCSP request Cc: "'Denis Pinkas'" , Juergen Brauckmann , ietf-pkix@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_525358525==_.ALT" --=====================_525358525==_.ALT Content-Type: text/plain; charset="us-ascii" At 11:46 AM 07/27/2000 +0200, Simon Tardell wrote: >Denis, > >> > This is not sufficient for systems that must be robust/tolerant against >CA >> > key compromise or such things. >> >> Key compromise is an exceptional event (that should not happen, but >> might happen) that must be addressed under a disaster recovery plan >> (i.e. revoke the CA whose key has been compromised in all the >> certificates that has been issued for that CA by other CAs). > >I see the disaster, but I don't see the recovery in this. > >As I see it, the problem the German model tries to tackle is that a CA which >has issued lots of certificates to the public (say millions) gets it keys >compromised somehow. Time-stamping services secure documents signed before >this moment, but there is another problem. Millions of germans are now >unable to go about their daily business. Potentially the German economy >grinds to a halt while the CA reissues millions of smart cards. Obviously >this would be a very bad thing. I'd hate to know that this scenario has not >been prepared in advance. Since the end-user keys did not get compromised >they can still be trusted. What is a problem is the linkage between the >holder and his keys, embodied in the certificates. Actually, such a scenario can be avoided. We suggest a possible solution in our paper which my coauthor put on his web site http:// www.bell-labs.com/user/philmac/research/cert-pkcfinal.ps.gz The main idea is to eliminate signatures in certificates and have CA sign a Merkle tree of certificates instead. Then CA key compromise requires the change in that signature (which can be downloaded separately) but leaves cards and certificates unperturbed. You can use multiple signatures with different signature algorithms and keep keys on different continents if you wish. This scheme also helps with archiving. And you do not need a CRL. It can be used with X.509 certificates, making the signature on a certificate optional, rather than mandatory. Or you can make it an owner's signature instead of a CA's signature. Irene ---------------------------------------------------------------------------- ------------------------------------------------------- Irene Gassko Bell Laboratories http://www.lucent.com Lucent Technologies Secure Technologies Dept. 1600 Osgood Street phone: (978) 960-5767 Room 30-2-A31 e-mail: gassko@lucent.com N. Andover, MA 01845 fax: (978) 960-3240 --=====================_525358525==_.ALT Content-Type: text/html; charset="us-ascii" At 11:46 AM 07/27/2000 +0200, Simon Tardell wrote:
>Denis,
>
>> > This is not sufficient for systems that must be  robust/tolerant against
>CA
>> > key compromise or such things.
>>
>> Key compromise is an exceptional event (that should not happen, but
>> might happen) that must be addressed under a disaster recovery plan
>> (i.e. revoke the CA whose key has been compromised in all the
>> certificates that has been issued for that CA by other CAs).
>
>I see the disaster, but I don't see the recovery in this.
>
>As I see it, the problem the German model tries to tackle is that a CA which
>has issued lots of certificates to the public (say millions) gets it keys
>compromised somehow. Time-stamping services secure documents signed before
>this moment, but there is another problem. Millions of germans are now
>unable to go about their daily business. Potentially the German economy
>grinds to a halt while the CA reissues millions of smart cards. Obviously
>this would be a very bad thing. I'd hate to know that this scenario has not
>been prepared in advance. Since the end-user keys did not get compromised
>they can still be trusted. What is a problem is the linkage between the
>holder and his keys, embodied in the certificates.

Actually, such a scenario can be avoided. We suggest a possible solution
in our paper which my coauthor put on his web site

http://www.bell-labs.com/user/philmac/research/cert-pkcfinal.ps.gz

The main idea is to eliminate signatures in certificates and have CA
sign a Merkle tree of certificates instead. Then CA key compromise
requires the change in that signature (which can be downloaded separately)
but leaves cards and certificates unperturbed. You can use multiple
signatures with different signature algorithms and keep keys on different
continents if you wish. This scheme also helps with archiving. And you do not
need a CRL. It can be used with X.509 certificates, making the signature
on a certificate optional, rather than mandatory. Or you can make it
an owner's signature instead of a CA's signature.

Irene


-----------------------------------------------------------------------------------------------------------------------------------
Irene Gassko                     Bell Laboratories              http://www.lucent.com
Lucent Technologies             Secure Technologies Dept.
1600 Osgood Street                       phone: (978) 960-5767
Room 30-2-A31                    e-mail:        gassko@lucent.com
N. Andover, MA 01845             fax:   (978) 960-3240 --=====================_525358525==_.ALT-- Received: from burusomail.buruso.com ([211.58.242.8]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA26896 for ; Thu, 3 Aug 2000 02:45:50 -0700 (PDT) Received: (from tomato [211.60.238.61]) by burusomail.buruso.com (Mail-Gear 1.1.0) with SMTP id M2000080318512600634 for ; Thu, 03 Aug 2000 18:51:26 +0900 From: "catseye" To: Subject: Date: Thu, 3 Aug 2000 18:51:55 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ns.secondary.com id CAA26897 unsubscribe Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA06127 for ; Wed, 2 Aug 2000 06:22:05 -0700 (PDT) Received: from [128.33.238.71] (TC071.BBN.COM [128.33.238.71]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id JAA09560; Wed, 2 Aug 2000 09:25:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <8525692A.0080C532.00@D51MTA04.pok.ibm.com> References: <8525692A.0080C532.00@D51MTA04.pok.ibm.com> Date: Wed, 2 Aug 2000 08:49:02 -0400 To: tgindin@us.ibm.com From: Stephen Kent Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt Cc: "PKIX-List" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Tom, > My point is that in very many cases, an employee serial number or >something like that is just as good for the RP's as a department. Its >greater stability compensates for its lack of user-friendliness. As you >rightly pointed out to Anders, if manual selection of one user from a list >of choices is the primary scenario in which an extra attribute is used, >serial numbers aren't the best way to make such a selection. However, they >may well be more useful for access control lists or for non-repudiation. I think the employee serial number serves a different function from the organizational fine structure attributes. the former is appropriate when stability over time is critical, for the reasons that Denis has introduced his permanent identifier attribute. However, when one wants to make an access control decision based on organizational affiliation, the later form of ID is more helpful. Also, as I noted earlier, from a human cognitive perspective, serial numbers are not a useful way to disambiguate individuals. Steve Received: from texcel.net (w092.z208037077.nyc-ny.dsl.cnc.net [208.37.77.92]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA10465; Tue, 1 Aug 2000 21:44:17 -0700 (PDT) From: Subject: FREE Computer Support & Consulting for your Business - to remove Send a Blank Reply Date: Wed, 2 Aug 2000 00:47:30 Message-Id: <466.887800.842154@texcel.net> Reply-To: remove@texcel.net Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Networking and Computer Solutions - TEXCEL provides Computer Solutions and Networking Services for small to mid-sized businesses. Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA02230 for ; Tue, 1 Aug 2000 19:37:33 -0700 (PDT) Received: from [128.33.238.18] (TC018.BBN.COM [128.33.238.18]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id WAA20225 for ; Tue, 1 Aug 2000 22:41:09 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: Date: Tue, 1 Aug 2000 22:24:44 -0400 To: ietf-pkix@imc.org From: Stephen Kent Subject: draft WG meeting minutes Content-Type: multipart/alternative; boundary="============_-1246938322==_ma============" --============_-1246938322==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" The draft minutes for today's WG meeting are reproduced below. I'll accept corrections until 8/11. Steve ------- PKIX WG Meeting 8/1/00 Edited by Steve Kent (WG co-chair) The PKIX WG met once during the 48th IETF and a total of approximately 180 individuals participated in this meeting. The meeting began with the announcement that Tim Polk of NIST will take over from Warwick Ford as a co-chair of the WG. Warwick received a round of applause from the audience, for his service to the Wg since its inception. Tim began the meeting with a review of the status of all of the WG documents. The following text summarizes the status of the documents: PKIX COMPLETED DOCUMENTS (RFCs) PKIX Cert/CRL Profile (RFC 2459) HTTP/FTP Operations (RFC 2585) LDAP V2 Operational Protocols (RFC 2559) LDAP V2 Schema (RFC 2587) OCSP (RFC 2560) CMP (RFC 2510) CRMF (RFC 2511) CMC (RFC 2797) Diffie-Hellman POP (RFC 2875) Certificate Policy/Practices Guideline (RFC 2527) KEA Algorithms for Profile (RFC 2528) PKIX WORK IN PROGRESS (Internet Drafts) Revised Profile (draft-ietf-pkix-new-part1-02.txt) Algorithms for Profile (draft-ietf-pkix-ipki-pkalgs-00.txt) Qualified Certificates (draft-ietf-pkix-qc-05.txt) Time Stamp (draft-ietf-pkix-time-stamp-09.txt) PKIX Roadmap (draft-ietf-pkix-roadmap-05.txt) Revised CMP (draft-ietf-pkix-rfc2510bis.01) CMP Transports (draft-ietf-pkix-cmp-transport-protocols-01.txt) Operational Protocols - LDAPv3 (draft-ietf-pkix-ldap-v3-02.txt) Additional LDAP Schema (draft-ietf-pkix-ldap-schema-00.txt) Attribute Certificate Profile for Authorization (draft-ietf-pkix-ac509prof-04.txt) Limited Attribute Cert Acquisition Prot (draft-ietf-pkix-laap-01.txt) DCS (draft-ietf-pkix-dcs-05.txt) Simple Certificate Validation Protocol (SCVP) (draft-ietf-pkix-scvp-03.txt) Permanent Identifier (draft-ietf-pkix-pi-00.txt) Repository Locator Service (draft-ietf-pkix-pkixrep-00.txt) Tech. Rqmts. For Non-Repudiation (draft-ietf-pkix-technr-01.txt) ACTIVE PROJECTS: LDAP v3 Profile (D. Chadwick-U. of Salford) Split profile into two pieces: protocol vs. schema. The protocol parts should be completed in the next 6-8 weeks and be ready for WG last call. (Suggestion that the LDAP WG also be included in this last call.) The schema work will take longer, as it is a new topic. A major change for the schema is to allow searching on certificate fields, rather than searching on the directory attributes extracted from the certificate. For now, plan to keep the schema work related to certificates in PKIX, not in an LDAP WG, with David acting as principal liaison between the two groups. RFC 2459 evolution (T. Polk-NIST) 2459 has been split into algorithm profiles vs. certificate & CRL syntax and processing. This allows the algorithms document to be revised as algorithms change, without affecting the syntax and processing standard. There is little new material here, mostly clarifications, editorial revisions, etc. We will hold a straw poll on the list on naming mandatory algorithms, e.g., RSA and SHA-1. With the end of the RSA patent period, many other security WGs are taking similar steps. Also, if the WG decides to identify mandatory algorithms, we need to decide whether they are specified in the certificate and CRL processing document, or in the algorithms document. (See slides for more details.) We should be able to go to WG last call very soon on these documents. Qualified Certificates (S. Santesson-AddTrust) Discussions at this IETF meeting have resolved the few remaining points of contention with regard to this draft. Minor changes in wording will result in a new draft by the end of this week and this draft will be forwarded to the security area directors to proceed with the IESG last call. Permanent Identifiers (D, Pinkas-Bull) To be used only in certificates issued to individuals. Designed to track real world identity in the face of name changes, e.g., marriage or job changes within an organization. The ID is expressed as a new name type, with two components; an assigner authority and a name. The first component may be omitted, in which case the certificate Issuer is presumed to be the assigner authority. Note that a registered ID (from general name form) has the necessary property that it is globally unique, and permanent (although not directly meaningful). Thus, depending on which general name form is employed, one can compare names either within a CA domain, or globally, across all CAs. Plan for now is to proceed with it as a separate document, not merged with the QC or son-of-RFC-2459 documents. (See slides for more details.) Time Stamping Protocol (D. Pinkas-Bull) Now on version 9. Several changes made after last call completed. Changes include definition of the serial number consistent with 2459 (can even be a hash of up to 160 bits!), change to SIA from AIA, etc. A number of minor wording changes were made, but the restriction on exclusive use of the TSA private key for signing responses has been preserved. Ready for forwarding to the IESG. Preface to OCSPX and SCVP discussions: As proposed at the Adelaide meeting, a small group was formed and generated a requirements document to characterize the motivations for remote validation services, to define the requirements for such services. The group did not compare the candidate protocols relative to these requirements. OCSP Extensions (M. Myers-VeriSign) Previous ID has expired, expunged from IETF web site. Mike argues that OCSP is the right choice for remote path processing (RPP), via the addition of extensions. Proposal is to revise RFC 2560, to fix minor problems, clarify OCPS role as a framework for remote validation services. Then, create separate documents to define extensions for remote path validation, remote path discovery, etc. So, there would not be an OCSPX document, but rather definitions for syntax and processing for standard extensions. (See slides for more details.) D. Pinkas provided some slides addressing the parameters of remote path processing, e.g., how the requestor constrains the path processing or path construction operation. So, the format needs to be able to indicate whether the requestor wants CRLs or OCSP responses, what security policy to use in evaluating a certificate path, other constraints, etc. Denis argues that the requirements document needs to cover more of these details. However, Paul Hoffman noted that the group was not able to agree to a larger set of "requirements." (See slides for more details.) SCVP (A. Malpani-ValiCert) The speaker reviewed RPP requirements and what OCSP does to support part of the process. Ambarish argues that changes to OCSP to meet these extended requirements may break existing OCSP implementations, and that the code base for OCSP is small, so there is not much to leverage in building an RPP protocol. SCVP will support both ASN.1 and XML, consistent with perceived client requirements to retain data in this format. (See slides for more details.) Attribute Certificates (S. Farrell-Baltimore) Profile has been updated, synchronized with latest X.509 version, and has completed WG last call. It is suggested that this document reference the successor to 2459, which clears up the residual reference issues. CMP (C. Adams-Entrust) CMP RFC is being revised to reflect minor changes. Plan is to wait until completion of interoperability testing (in the PKI forum) to finalize changes to this document, to reflect any further clarifications that arise from this testing. Repository Locator (P. Hallem-Baker-Verisign) Goal of this document is to specify a means by which one can map an RFC822 name for a user to the LDAP server where the user's certificates are stored. The proposed approach is to use the SRV record in the DNS to provide the necessary pointer. The SRV record is analogous to an MX record, but more general, supporting a list of services and matching addresses. Open questions include the internationalization of DNS (which the DNS WG will address), plus communicating conventions for access protocols (LDAP, HTTP, ...). The base document is a very small work item, because it is merely profiling the existing SRV record. Separate documents will be generated to describe each access protocol convention, e.g., LDAP, OCSP, and HTTP. Need to coordinate with LDAP WG and maybe DNS WGs on their plans for using SRV records for LDAP directory location. (See slides for more details.) CMP Interoperability testing (B. Moskowitz-ICSA) ICSA is working with PKI Forum to coordinate these interoperability tests. Three workshops have been conducted to date, with more scheduled for August and September. Various algorithms, transport protocols, POP mechanisms have been tested. A number vendors have participated. Planned public demo at NISSC in October. Experience shows that variants in CA-side implementations do cause interoperability problems, and further clarifications are needed in RFC 2510 to help resolve ambiguities. CMC interoperability testing may also be pursued in the future. --============_-1246938322==_ma============ Content-Type: text/enriched; charset="us-ascii" The draft minutes for today's WG meeting are reproduced below. I'll accept corrections until 8/11. Steve ------- Courier_NewPKIX WG Meeting 8/1/00 Edited by Steve Kent (WG co-chair) The PKIX WG met once during the 48th IETF and a total of approximately 180 individuals participated in this meeting. The meeting began with the announcement that Tim Polk of NIST will take over from Warwick Ford as a co-chair of the WG. Warwick received a round of applause from the audience, for his service to the Wg since its inception. Tim began the meeting with a review of the status of all of the WG documents. The following text summarizes the status of the documents: PKIX COMPLETED DOCUMENTS (RFCs) PKIX Cert/CRL Profile (RFC 2459) HTTP/FTP Operations (RFC 2585) LDAP V2 Operational Protocols (RFC 2559) LDAP V2 Schema (RFC 2587) OCSP (RFC 2560) CMP (RFC 2510) CRMF (RFC 2511) CMC (RFC 2797) Diffie-Hellman POP (RFC 2875) Certificate Policy/Practices Guideline (RFC 2527) KEA Algorithms for Profile (RFC 2528) PKIX WORK IN PROGRESS (Internet Drafts) Revised Profile (draft-ietf-pkix-new-part1-02.txt) Algorithms for Profile (draft-ietf-pkix-ipki-pkalgs-00.txt) Qualified Certificates (draft-ietf-pkix-qc-05.txt) Time Stamp (draft-ietf-pkix-time-stamp-09.txt) PKIX Roadmap (draft-ietf-pkix-roadmap-05.txt) Revised CMP (draft-ietf-pkix-rfc2510bis.01) CMP Transports (draft-ietf-pkix-cmp-transport-protocols-01.txt) Operational Protocols - LDAPv3 (draft-ietf-pkix-ldap-v3-02.txt) Additional LDAP Schema (draft-ietf-pkix-ldap-schema-00.txt) Attribute Certificate Profile for Authorization (draft-ietf-pkix-ac509prof-04.txt) Limited Attribute Cert Acquisition Prot (draft-ietf-pkix-laap-01.txt) DCS (draft-ietf-pkix-dcs-05.txt) Simple Certificate Validation Protocol (SCVP) (draft-ietf-pkix-scvp-03.txt) Permanent Identifier (draft-ietf-pkix-pi-00.txt) Repository Locator Service (draft-ietf-pkix-pkixrep-00.txt) Tech. Rqmts. For Non-Repudiation (draft-ietf-pkix-technr-01.txt) ACTIVE PROJECTS: LDAP v3 Profile (D. Chadwick-U. of Salford) Split profile into two pieces: protocol vs. schema. The protocol parts should be completed in the next 6-8 weeks and be ready for WG last call. (Suggestion that the LDAP WG also be included in this last call.) The schema work will take longer, as it is a new topic. A major change for the schema is to allow searching on certificate fields, rather than searching on the directory attributes extracted from the certificate. For now, plan to keep the schema work related to certificates in PKIX, not in an LDAP WG, with David acting as principal liaison between the two groups. RFC 2459 evolution (T. Polk-NIST) 2459 has been split into algorithm profiles vs. certificate & CRL syntax and processing. This allows the algorithms document to be revised as algorithms change, without affecting the syntax and processing standard. There is little new material here, mostly clarifications, editorial revisions, etc. We will hold a straw poll on the list on naming mandatory algorithms, e.g., RSA and SHA-1. With the end of the RSA patent period, many other security WGs are taking similar steps. Also, if the WG decides to identify mandatory algorithms, we need to decide whether they are specified in the certificate and CRL processing document, or in the algorithms document. (See slides for more details.) We should be able to go to WG last call very soon on these documents. Qualified Certificates (S. Santesson-AddTrust) Discussions at this IETF meeting have resolved the few remaining points of contention with regard to this draft. Minor changes in wording will result in a new draft by the end of this week and this draft will be forwarded to the security area directors to proceed with the IESG last call. Permanent Identifiers (D, Pinkas-Bull) To be used only in certificates issued to individuals. Designed to track real world identity in the face of name changes, e.g., marriage or job changes within an organization. The ID is expressed as a new name type, with two components; an assigner authority and a name. The first component may be omitted, in which case the certificate Issuer is presumed to be the assigner authority. Note that a registered ID (from general name form) has the necessary property that it is globally unique, and permanent (although not directly meaningful). Thus, depending on which general name form is employed, one can compare names either within a CA domain, or globally, across all CAs. Plan for now is to proceed with it as a separate document, not merged with the QC or son-of-RFC-2459 documents. (See slides for more details.) Time Stamping Protocol (D. Pinkas-Bull) Now on version 9. Several changes made after last call completed. Changes include definition of the serial number consistent with 2459 (can even be a hash of up to 160 bits!), change to SIA from AIA, etc. A number of minor wording changes were made, but the restriction on exclusive use of the TSA private key for signing responses has been preserved. Ready for forwarding to the IESG. Preface to OCSPX and SCVP discussions: As proposed at the Adelaide meeting, a small group was formed and generated a requirements document to characterize the motivations for remote validation services, to define the requirements for such services. The group did not compare the candidate protocols relative to these requirements. OCSP Extensions (M. Myers-VeriSign) Previous ID has expired, expunged from IETF web site. Mike argues that OCSP is the right choice for remote path processing (RPP), via the addition of extensions. Proposal is to revise RFC 2560, to fix minor problems, clarify OCPS role as a framework for remote validation services. Then, create separate documents to define extensions for remote path validation, remote path discovery, etc. So, there would not be an OCSPX document, but rather definitions for syntax and processing for standard extensions. (See slides for more details.) D. Pinkas provided some slides addressing the parameters of remote path processing, e.g., how the requestor constrains the path processing or path construction operation. So, the format needs to be able to indicate whether the requestor wants CRLs or OCSP responses, what security policy to use in evaluating a certificate path, other constraints, etc. Denis argues that the requirements document needs to cover more of these details. However, Paul Hoffman noted that the group was not able to agree to a larger set of "requirements." (See slides for more details.) SCVP (A. Malpani-ValiCert) The speaker reviewed RPP requirements and what OCSP does to support part of the process. Ambarish argues that changes to OCSP to meet these extended requirements may break existing OCSP implementations, and that the code base for OCSP is small, so there is not much to leverage in building an RPP protocol. SCVP will support both ASN.1 and XML, consistent with perceived client requirements to retain data in this format. (See slides for more details.) Attribute Certificates (S. Farrell-Baltimore) Profile has been updated, synchronized with latest X.509 version, and has completed WG last call. It is suggested that this document reference the successor to 2459, which clears up the residual reference issues. CMP (C. Adams-Entrust) CMP RFC is being revised to reflect minor changes. Plan is to wait until completion of interoperability testing (in the PKI forum) to finalize changes to this document, to reflect any further clarifications that arise from this testing. Repository Locator (P. Hallem-Baker-Verisign) Goal of this document is to specify a means by which one can map an RFC822 name for a user to the LDAP server where the user's certificates are stored. The proposed approach is to use the SRV record in the DNS to provide the necessary pointer. The SRV record is analogous to an MX record, but more general, supporting a list of services and matching addresses. Open questions include the internationalization of DNS (which the DNS WG will address), plus communicating conventions for access protocols (LDAP, HTTP, ...). The base document is a very small work item, because it is merely profiling the existing SRV record. Separate documents will be generated to describe each access protocol convention, e.g., LDAP, OCSP, and HTTP. Need to coordinate with LDAP WG and maybe DNS WGs on their plans for using SRV records for LDAP directory location. (See slides for more details.) CMP Interoperability testing (B. Moskowitz-ICSA) ICSA is working with PKI Forum to coordinate these interoperability tests. Three workshops have been conducted to date, with more scheduled for August and September. Various algorithms, transport protocols, POP mechanisms have been tested. A number vendors have participated. Planned public demo at NISSC in October. Experience shows that variants in CA-side implementations do cause interoperability problems, and further clarifications are needed in RFC 2510 to help resolve ambiguities. CMC interoperability testing may also be pursued in the future. --============_-1246938322==_ma============-- Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA29692 for ; Tue, 1 Aug 2000 19:07:24 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Aug 2000 22:11:49 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF22DCEE@panda.chrysalis-its.com> To: tim.polk@nist.gov Cc: ietf-pkix@imc.org Subject: RE: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-00.txt Date: Tue, 1 Aug 2000 22:11:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFFC27.044D9782" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFFC27.044D9782 Content-Type: text/plain; charset="iso-8859-1" Hi Tim, Here are some minor comments on this draft: a. Section 3.3, the description and presentation of what key usage extensions may optionally appear in a CA and/or an end entity certificate should be made consistent between the different algorithms. For example, the draft does not distinguish between a CA and an end entity certificate for ECDSA. The draft only mentions for ECDSA that if the keyCertSign and cRLSign values may only be asserted if the basicConstraints extension is present and cA is TRUE, but not for other algorithms. The draft mentions for KEA that the encipherOnly and decipherOnly values may only be asserted if the keyAgreement value is also asserted, but not Diffie-Hellman. b. Section 3.3.4, you refer to sections 3.1.1 and 3.1.2 in many instances, however these two sections have nothing to do with KEA. Regards, Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 ------_=_NextPart_001_01BFFC27.044D9782 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-00.txt

Hi Tim,

Here are some minor comments on this draft:

a.  Section 3.3, the description and = presentation of what key usage extensions may optionally appear in a CA = and/or an end entity certificate should be made consistent between the = different algorithms. For example, the draft does not distinguish = between a CA and an end entity certificate for ECDSA. The draft only = mentions for ECDSA that if the keyCertSign and cRLSign values may only = be asserted if the basicConstraints extension is present and cA is = TRUE, but not for other algorithms. The draft mentions for KEA that the = encipherOnly and decipherOnly values may only be asserted if the = keyAgreement value is also asserted, but not Diffie-Hellman.

b.  Section 3.3.4, you refer to sections 3.1.1 = and 3.1.2 in many instances, however these two sections have nothing to = do with KEA.

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078

------_=_NextPart_001_01BFFC27.044D9782-- Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA21399 for ; Tue, 1 Aug 2000 17:27:54 -0700 (PDT) Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46555) id <0FYN004012S0MT@ext-mail.valicert.com> for ietf-pkix@imc.org; Tue, 01 Aug 2000 17:31:24 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46555) with ESMTP id <0FYN0037X1VOTD@ext-mail.valicert.com> for ietf-pkix@imc.org; Tue, 01 Aug 2000 17:11:48 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Tue, 01 Aug 2000 17:02:56 -0700 Content-return: allowed Date: Tue, 01 Aug 2000 17:02:55 -0700 From: Stefan Richards Subject: RE: OCSP, SCVP vendors To: "'ietf-pkix@imc.org'" Message-id: <27FF4FAEA8CDD211B97E00902745CBE20140AAF0@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 ValiCert Inc. actively tests ValiCert partner products for interoperability with OCSP. ValiCert and RSA Data Security Inc. will soon be hosting an OCSP interoperability testing site to provide a testbed for OCSP-enabled applications to achieve interoperability (http://www.rsasecurity.com/standards/ocsp/). ValiCert would like to premote the same sort of intiatives for SCVP and is interested in working with a partner or partners on such efforts. For more information on the subject, please feel free to contact me directly. --Stefan ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Stefan Richards (650)567-5604 ValiCert Inc. stefanr@valicert.com Securing e-Transactions(tm) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --- Mohamed A. Elissa wrote: Hi all, I need to know if there are any vendors doing interoperability tests for OCSP and SCVP, and where to get more information about the products passed the tests. Mohamed A. Eissa Intel of Canada, Ltd. (416) 622-7175 2 Eva Road, Suite 220 Toronto, Ontario, M9C 2A8 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14535 for ; Tue, 1 Aug 2000 12:00:50 -0700 (PDT) From: tgindin@us.ibm.com Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA24996; Tue, 1 Aug 2000 15:04:25 -0400 Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id PAA24976; Tue, 1 Aug 2000 15:04:27 -0400 Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525692E.0068C3C5 ; Tue, 1 Aug 2000 15:04:18 -0400 X-Lotus-FromDomain: IBMUS To: "David P. Kemp" , denis.pinkas@bull.net cc: ietf-pkix@imc.org Message-ID: <8525692E.0068C144.00@D51MTA04.pok.ibm.com> Date: Tue, 1 Aug 2000 15:04:10 -0400 Subject: Re: Company OIDs for free for PIs? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline IANA even publishes their OID assignments at that location, which neutralizes the major advantage of using a URI of the approximate format http://domain/EmployeeAssignments?DateOfFirstUse. In view of that, that alternative is no longer necessary, although I'm sorry to have missed the meeting in Pittsburgh. The application form for new assignments in IANA's OID list is at IANA proper: http://www.iana.org/cgi-bin/enterprise.pl. My only remaining question is whether IANA will continue to provide a free service if every company with > 100 employees asks for this. I suppose they could charge a SMALL fee instead. Tom Gindin "David P. Kemp" on 08/01/2000 12:33:32 PM Please respond to "David P. Kemp" To: ietf-pkix@imc.org cc: Subject: Re: Company OIDs for free for PIs? Bob, Have you considered using Private Enterprise codes (http://www.isi.edu/in-notes/iana/assignments/enterprise-numbers)? True, the arc 2.6.7.11 is a little shorter than the IETF's 1.3.6.1.4.1, but that shouldn't be a big deal. They're both free. Dave > Date: Tue, 01 Aug 2000 10:13:57 -0400 > To: ietf-pkix@imc.org > From: Robert Moskowitz > Subject: Company OIDs for free for PIs? > > I have often thought about how little companies can get OIDs for > free. After all, a few thousand bills for a small company can be a lot of > money... > > What I have seen is every company can have an EDI identifier. X.435 > (EDIFACT) has defined over 300 EDI identifier namespaces (DUNS being the > most common, supposedly). > > I **THINK** this is the EDIFACT UNB IdentificationCode > > X.435 has its own arc: 2.6.7.11 > > If we can get the EDI arc registered this way (probably is and only > documented in X.435), the PRESTO! Any company that has an EDI identifier > has an OID arc. > > Can anyone fill in the missing parts of this and then perhaps Denis can add > this as a recommendation for company PIs. > > Robert Moskowitz > ICSA > Security Interest EMail: rgm-sec@htt-consult.com > > > > ***************************************************************************** > This confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ****************************************************************************** Received: from htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA14416 for ; Tue, 1 Aug 2000 11:58:06 -0700 (PDT) Received: from rgm.htt-consult.com ([147.73.134.30]) by htt-consult.com ; Tue, 01 Aug 2000 13:01:31 -0400 Message-Id: <4.3.2.7.2.20000801125102.03c96890@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 Aug 2000 13:00:31 -0400 To: "David P. Kemp" , ietf-pkix@imc.org From: Robert Moskowitz Subject: Re: Company OIDs for free for PIs? In-Reply-To: <200008011624.MAA11133@roadblock.missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:33 PM 8/1/2000 -0400, David P. Kemp wrote: >Have you considered using Private Enterprise codes >(http://www.isi.edu/in-notes/iana/assignments/enterprise-numbers)? Actually, I have. I got one for the AIAG (Automotive Industry Action Group) a couple of years ago :) >True, the arc 2.6.7.11 is a little shorter than the IETF's 1.3.6.1.4.1, >but that shouldn't be a big deal. They're both free. We would need to educate small businesses and IANA would have to get ready for a flood of 10Ks of company requests. My little DBA, HTT Consulting, already has a DUNs #. Once I know how this arc would work (eg 2.6.7.11.4.5), I would then have a defacto arc. In Europe, WIPO assigns company #s, they have over 25000 such companies registered already. Again, instant arc. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11422 for ; Tue, 1 Aug 2000 09:34:07 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id MAA11137 for ; Tue, 1 Aug 2000 12:24:51 -0400 (EDT) Message-Id: <200008011624.MAA11133@roadblock.missi.ncsc.mil> Date: Tue, 1 Aug 2000 12:33:32 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Company OIDs for free for PIs? To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4j+iCgy0lNDZBiGBdU/0zQ== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Bob, Have you considered using Private Enterprise codes (http://www.isi.edu/in-notes/iana/assignments/enterprise-numbers)? True, the arc 2.6.7.11 is a little shorter than the IETF's 1.3.6.1.4.1, but that shouldn't be a big deal. They're both free. Dave > Date: Tue, 01 Aug 2000 10:13:57 -0400 > To: ietf-pkix@imc.org > From: Robert Moskowitz > Subject: Company OIDs for free for PIs? > > I have often thought about how little companies can get OIDs for > free. After all, a few thousand bills for a small company can be a lot of > money... > > What I have seen is every company can have an EDI identifier. X.435 > (EDIFACT) has defined over 300 EDI identifier namespaces (DUNS being the > most common, supposedly). > > I **THINK** this is the EDIFACT UNB IdentificationCode > > X.435 has its own arc: 2.6.7.11 > > If we can get the EDI arc registered this way (probably is and only > documented in X.435), the PRESTO! Any company that has an EDI identifier > has an OID arc. > > Can anyone fill in the missing parts of this and then perhaps Denis can add > this as a recommendation for company PIs. > > Robert Moskowitz > ICSA > Security Interest EMail: rgm-sec@htt-consult.com > > > > ***************************************************************************** > This confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ****************************************************************************** Received: from htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA10383 for ; Tue, 1 Aug 2000 09:11:33 -0700 (PDT) Received: from rgm.htt-consult.com ([147.73.134.30]) by htt-consult.com ; Tue, 01 Aug 2000 10:15:00 -0400 Message-Id: <4.3.2.7.2.20000801095804.03c955c0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 Aug 2000 10:13:57 -0400 To: ietf-pkix@imc.org From: Robert Moskowitz Subject: Company OIDs for free for PIs? In-Reply-To: <398159AB.C98D9F3A@bull.net> References: <000c01bff87f$dd26b620$0201a8c0@mega.vincent.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I have often thought about how little companies can get OIDs for free. After all, a few thousand bills for a small company can be a lot of money... What I have seen is every company can have an EDI identifier. X.435 (EDIFACT) has defined over 300 EDI identifier namespaces (DUNS being the most common, supposedly). I **THINK** this is the EDIFACT UNB IdentificationCode X.435 has its own arc: 2.6.7.11 If we can get the EDI arc registered this way (probably is and only documented in X.435), the PRESTO! Any company that has an EDI identifier has an OID arc. Can anyone fill in the missing parts of this and then perhaps Denis can add this as a recommendation for company PIs. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com